RE: New database servers...one listener or one for each database.

> I'd be curious as to what 'their' arguments are for either option.
 

For one listener per database, different ports, on the server with many databases.  

• Isolation was mentioned a few times.
• If the listener has a problem then every database is impacted.
• If each database has its own listener and a listener has a problem then only one production database is impacted.

Someone today argued that there are multiple SCAN listeners on a RAC cluster so we should have multiple database listeners. However we are not doing RAC. Personally I would love to do RAC but it’s not in the budget yet. Maybe in a few years…  

I don’t recall a listener having many issues, if any. But I am curious if other sites had experienced problems with a listener.  

Thanks,

Chris  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Hans Forbrich Sent: Monday, July 14, 2014 12:32 PM
To: oracle-l_at_freelists.org
Subject: Re: New database servers...one listener or one for each database.  

On 14/07/2014 9:27 AM, Chris Grabowy wrote:

So were migrating all the production databases to new Red Hat servers.  

The question being debated by the DBAs is…  

• One listener for all the databases (1-10) on the server?
• One listener per database, different ports, on the server?

If they want to have additional busy-work during their administration, then definitely use one listener per database.

Otherwise, consider that the listener is only used during the initial communication, and once a session is established the listener can be taken down without impacting the session.

A much more important decision is who to configure the connection pools used by the middle tier. The is a frequent incorrectly designed "session per lookup" problem that needs to be addressed.

Then again, a listener has only a limited number of connections it can handle per second (because we spawn/fork-exec full processes) and if we exceed that rate, we will get a variety of failures that may be difficult to understand. The exact rate needs to be tested on your specific hardware.

I'd be curious as to what 'their' arguments are for either option.

/Hans

--
http://www.freelists.org/webpage/oracle-l