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
