Re: shared_pool_size=800M ???

Marc Blum <blumNOSPAM_at_marcblum.de> wrote in message news:<nah730d7metm3ce03ua1rh21l3m2hgp55p_at_4ax.com>...
> 9.2.0.4 EE, SUN Solaris
>
> At a customer's site I installed a database/instance for a new app. All I knew
> was, that there wouldn't be much code running in the db,
> perhaps some plsql and a bit of java.
> The vast majority of work would be done by the clients, written
> in java by some OO-fellows. I gave the instance 100m shared pool
> which is pretty much, but to be on the safe side.
>
> Now the developers start complaining, the shared pool ought to have 800m !!!
> I myself doesn't have any clue why any app needs so much shared pool.
> So please enlighten me with some serious reasons for that.
>
> thanks in advance

the inmantes are running the asylum.
your instincts are good, trust them.
the developers don't get it.
too bad the market sux so bad, cuz you should find some other place.

if there are no binds, you'd be far better off with a smaller shared pool (say 128M) and flush less than wonderful code out of the shared_pool every 30 minutes or so.

been there, done that.

check out Tom Kyte's site and his books for his recommendations. check out Connor McDonald's new book, or a large number of papers regarind shared pool usage, like http://www.miracleas.dk/ - cursor_sharing by Bjørn Engsig.

if literals are used in a high concurrency app, you're hosed (stuffed, out of luck, buggered, fscked, filing TARs, etc). 9.2 has a few more options as compared with 8.1.7 that can help you deal with the raging inflow of non-reusable code, but you're still going to have to fix the fundemental code issues.

maybe if you can introduce some bottlenecks so that (hard) parsing is no longer the rate-limiting-factor, you'll be better off.

what to do, when you can't touch the code? direct the blame to where it belongs.

Pd Received on Wed Feb 18 2004 - 23:40:29 CST