Re: Fighting Words? Shared Pool Size

Ross,

Ross Mohan wrote:

> >cursor_space_for_time will nearly always end up with a large shared
> >pool.
>
> || I guess i was making the point that the pool was fixed, and too large.
> and that CSFT wasn't helping things by forcing additional pool mgmt
>
> As to what defines a large shared pool depends heavily on the
> >number of applications that the instance has to support. After sizing
> >exercises, I've ended up with Shared Pools ranging from about 20Mb's
> >upto about 400Mb's. Both were about the correct size for the job they
> >were being asked to perform.
>
> || Number of apps and users, plus considerations of pinning, reuse,
> bindvars
> versus not. I haven't ever seen the need ( up to, say, about 500
> concurrent, busy
> thin-client users, multiple apps ) to have a pool larger than 150MB. On
> your
> machine with the 400MB pool, how many users did you have, and was it
> something like an AR/AP or GL setup?
>

The large 400Mb pool, was supporting a Tuxedo based 7x24 server, with about 150 -> 200 connections, supporting probably about 400 users. We had about 30 different sub systems accessing the instance. Also, remember that Tuxedo is similar to MTS in the sense that the sessions PGA is stored in the Shared Pool.

>
> >
> >I think the important thing is that you don't see to much stealing of
> >space from one object class (library cache, dictionary cache, sql area)
> >to fund another. Keep an eye on the v$sgastat output over the course of
> >time.
>
> || This is interesting. Have you experimented at all with monitoring space
> swapping between namespaces in the lib cache, and did you see anything
> there? Thinking about this will be useful, i believe....thanks for
> the thoughts Andrew

I can't remember the full logic behind the tuning, but I believe we did have some namespace issues, but I cannot be certain.

Andrew Received on Tue Apr 20 1999 - 03:12:42 CDT