Re: Formula for number of DB Listeners on server

From: Woody McKay <woody.mckay_at_gmail.com>
Date: Tue, 13 Oct 2015 13:08:40 -0400
Message-ID: <CAAxONsRWsO3A3tmbVLiK6wbBHNpaG-q3Mphew=jbfdzyxjGMwg_at_mail.gmail.com>

Good info Jeremy - I'll be reading. Their app does use Java connection pools and they don't have named transactions, so pieces of a transactions come from various different connections. Should have all the usual ports available, just have to haggle with the people manning the firewall...

Like the idea of static definitions instead of auto register and using one listener per sid. Let me check with them on the port availability.

On Tue, Oct 13, 2015 at 12:19 PM, Jeremy Schneider < jeremy.schneider_at_ardentperf.com> wrote:

> If anyone tells you they have a "best practice" about this then duck
> and run because they are trying to sell you something. :)
>
> I don't think you'll find much in the way of "number of DB listeners".
> The two most common configs are one per SID or one per server, not
> sure I've seen anything outside of that.
>
> It's really only an issue if you have a very high rate of constant
> incoming new connections (sub-optimal app design but sometimes that
> can't be helped). Pretty rare in my experience though; in most cases
> listener issues should be infrequent enough that you're fine with a
> single listener.
>
> You might consider static service definitions if you're frequently
> having to restart your listener. I think that srvctl will cause all
> the instances to re-register themselves immediately but if you
> manually restart a listener then you do have to wait for the pmon
> timeout before each instance re-registers with its local_listener.
> That can be up to 60 seconds in 11gR2 during which no application can
> establish a new connection. Setup some static definitions, and
> everyone can reconnect immediately after the listener restart itself
> which should never be more than a few seconds max.
>
>
> https://docs.oracle.com/cd/E11882_01/network.112/e41945/net_arch.htm#NETAG1080
>
> If you are sure that you need multiple listeners, but a port shortage
> forces you to still have less than the number of instances, then
> you're probably on your own. Most people wouldn't suggest going there
> but if you must then come up with a good system for documenting and
> managing it.
>
> I don't think the main concern is performance but rather complexity
> and manageability. Keep it as simple as possible now and you'll thank
> yourself a few years down the road.
>
> -J
> --
> http://about.me/jeremy_schneider
>
>
> On Tue, Oct 13, 2015 at 10:58 AM, Woody McKay <woody.mckay_at_gmail.com>
> wrote:
> > Hi,
> >
> > Is there a formula for figuring out how many DB Listeners there should
> be on
> > a physical server?
> >
> > I'm part of a new team working on a new production setup for hosting. We
> > currently have 40 SIDs per server with one listener. Occasionally, the
> > listener appears to be unresponsive and the hosting team will bounce it
> > breaking all connections for all SIDs on the box. So, the current
> > configuration is not optimal.
> >
> > The hosting team is working with a vendor and is proposing a server with
> > cpu, ram, storage that will handle upwards of 120+ SIDs. Obviously, each
> > SID has a different workload and number of connections based on the size
> of
> > the customer.
> >
> > Any thoughts or best practices for determining the number of DB
> listeners?
> >
> > Thanks for all wonderful sharing this group does.
> >
> > --
> > Sincerely,
> >
> > WoodyMcKay
>

-- 
Sincerely,

WoodyMcKay

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

Received on Tue Oct 13 2015 - 19:08:40 CEST