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

if using one listener for all databases (running from different Oracle homes), another point to consider might also be the listener downtime when patching the Oracle home the listener is running from.

Regards,
Jure

On Wed, Jul 16, 2014 at 12:32 AM, Chris Grabowy <cgrabowy_at_gmail.com> wrote:

> Hans,
>
>
>
> > 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