Re: Setup of Multiple Listeners on RAC ?

I'm not certain of disaster, but I think the odds are surely in the house's favor. I doubt that this application has a requirement for 10000 *active* database connections. For whatever reason, the application seems to be written in such manner that it does not leverage connection pooling. I'll discuss under these assertions.

First, I'd think that there would be an extreme amount of overhead for a kernel to manage 10000 open TCP connections. I personally do not have any data, but if anyone does, I'd be interested in hearing about it.

Second, Oracle is a processed based application. Having 10000 (dedicated) db connections means that there is over 10000 db processes running on this host. I'm not a kernel guru, but its probably likely that not too many Unix operating systems are tested with that scale of processes. To me, it seems like a considerable amount of process time slicing to manage. This is why connection pooling is a more scalable option.

Niall Litchfield mentioned memory. Since each db connection has private memory space, the amount of memory consumed by 10000 is probably not insignificant.

There are probably more challenges than just the ones that I've noted.  I'm sure the community would love to hear about them as this exercise take place.

On 9/25/07, David Sharples <davidsharples_at_gmail.com> wrote:
> why a recipe for disaster?
>
> On 25/09/2007, Greg Rahn <greg_at_structureddata.org> wrote:
> > Having 10,000 database connections on a given node (regardless of
> > size) is probably a recipe for failure. Have you considered using a
> > connection pool?
> > http://en.wikipedia.org/wiki/Connection_Pool

-- 
Regards,

Greg Rahn
http://structureddata.org
--
http://www.freelists.org/webpage/oracle-l