Re: How to determine the sessions parameter in the pfile

Walt,

Are you using dedicated or shared servers on the Oracle instance?

From the sounds of it, your problem seems to a be a case of using dedicated servers for the connections from your webserver farm. This is indicated by your CPU load being not stressed when you have a high number of connections to the database. Each dedicated server consumes one process per connection even though there is now work going on. With the shared servers option active, each shared server process is shared between multiple connections depending on the workload.

If that is the case, I would suggest implementing shared servers on your Oracle instance.

I would investigate shared servers before trying to estimate number of processes to run on an instance. I have found the Oracle default to a good value.

Douglas Hawthorne

"Walt" <walt_at_boatnerd.com.invalid> wrote in message news:4016F475.FD20601D_at_boatnerd.com.invalid...
>
> We just put an instance of Oracle 9.2 on W23k on line. So far, so
> good. It's connected to a webserver farm which uses connection pooling
> to increase or decrease the number of connections based on load.
> Unfortunately, at some peak load times the maximum number of sessions is
> reached and users get the "ORA-00020 : Maximum processes exceeeded" .
> During those periods, the oracle server doesn't seem to be stressed (low
> CPU usage, etc.) so I think the problem is just that the processes
> parameter is artificially low.
>
> So, how does one determine a good value for the processes parameter?
> I'd like to set it as high as the server will handle, but I'd rather not
> do this by trial and error.
>
> I've read elsewhere that you should budget 7Meg of memory per process.
> Is this still true in 9.2?
>
> And if it is, presumably I'd calculate a value for the processes
> parameter by dividing 7 into the total memory available. What should I
> use for total memory?
> o the total SGA
> o the max SGA
> o the total RAM of the server
> o something else?
>
> Thanks.
>
>
> --
> //-Walt
> //
> //
Received on Tue Jan 27 2004 - 19:36:12 CST