Re: Sizing SHARED_POOL_SIZE

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:<tJtV9.25258$jM5.66991_at_newsfeeds.bigpond.com>...
> "Rauf Sarwar" <rs_arwar_at_hotmail.com> wrote in message
> > Howard,
> >
> > Hmmm... I thought you were going to use it to size your production
> > shared pool -:)
> >
> > Yes I agree with you that it definitely is not gospel and other
> > factors should be considered, specially when sizing production. I have
> > had this script in my archive for a while and couldn't resist posting
> > it after reading the subject. I do however use it once in while by
> > running it at different times of a day just to get an average shared
> > pool requirement as it relates to fluctuating number of concurrent
> > users.
>
> As I said, I wasn't having a go at you, and I was rather impressed with
> script (was it one you wrote yourself?). It is most definitely a starting
> point when you haven't the faintest idea what to set s_p_s to initially,
> that's for sure.

Since the script is dependent on a system that is already running, I'd say that although it is pretty cool, and apparently useful for a running system as a gross initial look, it is not appropriate as a starting point. Unless by starting point you mean you have a small system and want to guess about a larger one.

On my system, it overstates the necessary shared size by about 3X at most times (probably due to users not actually doing anything most of the time), and may be correct during heavy times (I haven't had a chance to check it then). A keeper, Rauf (since I find scripts that give a gross initial look very useful)!

>
> >
> > I guess it would be a "DBA state of nirvana" if one can perfectly size
> > all init.ora parameters by just running one script!!!

That _was_ the intent of some TFTS scripts that seem to have become excuses for arguing about hit ratios! :-O

jg

--
@home is bogus.
$[78]: 25078 Memory fault(coredump)
Another awk core dump.  Dang!  Well, it's fix that or wait for 60 hour
sqls...