Re: Formula for number of DB Listeners on server

  • From: Woody McKay <woody.mckay@xxxxxxxxx>
  • To: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
  • Date: Tue, 13 Oct 2015 13:08:40 -0400

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@xxxxxxxxxxxxxx> 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@xxxxxxxxx>
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

Other related posts: