RE: how many listeners to run?

From: <>
Date: Thu, 10 Jan 2008 11:42:27 -0700
Message-ID: <005401c853b8$8e0a32a0$6401a8c0@BHAIRAVIPC01>

I would not recommend that since that could end up in a maintenance nightmare in large production environments. I tend to prefer 2-3 listeners per node of the RAC cluster as a failsafe, segregation of duties, and for ease of maintenance and use the services framework to direct or allow/disallow connections to a given instance of a database.  



Krish Hariharan

President/Executive Architect, Quasar Database Technologies, LLC


From: [] On Behalf Of Stephens, Chris
Sent: Thursday, January 10, 2008 11:34 AM To:
Cc: oracle-l
Subject: RE: how many listeners to run?  

You could do that by changing the listener.ora and lsnrctl>reload.      

From: [] On Behalf Of Andrew Kerber
Sent: Thursday, January 10, 2008 12:15 PM To: David Sharples
Cc:; oracle-l
Subject: Re: how many listeners to run?  

For one thing, it allows us to turn off access to one instance at a time for maintenance, for example. It allows us to assign a different port to each instance. There are many advantages.

On Jan 10, 2008 12:12 PM, David Sharples <> wrote:

why do you require a listener per instance?  

On 10/01/2008, Andrew Kerber <> wrote:

One listener per instance is what I use.

On Jan 10, 2008 10:52 AM, Li Li <> wrote:

Hi, List,

I'd like to hear your input on how many listeners to run in a RAC environment that will host 4 RAC databases. It'll be Oracle <>
on RHEL 4 (all 64-bit). I am leaning to run just 1 listener, what is your thoughts on this?


Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email reply.

-- Received on Thu Jan 10 2008 - 12:42:27 CST

Original text of this message