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

From: Hans Forbrich <fuzzy.graybeard_at_gmail.com>
Date: Wed, 16 Jul 2014 07:09:47 -0600
Message-ID: <53C6799B.5070709_at_gmail.com>



The majority of organizations I have encountered who use multiple listeners end up just having different named listeners in the one code base, from the one home.

If that is the case, we still end up with a single point of 'failure & maintenance'.

I had long advocated a completely separate ORACLE_HOME for the networking listener, especially in environments that have multiple ORACLE_HOMEs for databases. This way a regular ORACLE_HOME can be used to take over the listener function during listener maintenance, and the primary listener can be kept a a patch level compatible with the databases and the clients (see the Support note on Server, Client Compatibility Matrix).

However, with ASM as part of GI in separate ORACLE_HOME, since 11G the concept of a 'listener home' is really overkill.

/Hans

On 16/07/2014 2:16 AM, Jure Bratina wrote:
> Hi,
>
> 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
> <mailto: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>
> [mailto: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 <mailto: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
Received on Wed Jul 16 2014 - 15:09:47 CEST

Original text of this message