Enev though flushing the shared pool does NOT defragment the shared pool, it
did clean up all the stuff in shared pool, the effect is the same as pin the
objects at the database startup. This is especially useful for 24 by 7
database where you can not afford to bounce the database.
"Sean Fitzgerald" <sfitzgerald_at_centurytel.net> wrote in message
news:yio38.20571$Xs4.4303977_at_feed.centurytel.net...
> You should pin the objects at database startup (you can use a database
> trigger on startup to accomplish this). The parameter to adjust the
minimum
> allocation for the reserved area is still available (at least up to
8.1.7),
> but it is a hidden parameter. Flushing the shared pool does NOT
defragment
> the shared pool.
>
> "Mike F" <u518615722_at_spawnkill.ip-mobilphone.net> wrote in message
> news:l.1011733100.1234893798@[64.94.198.252]...
> > On 8.1.7.2
> >
> > Some body suggested me to run the following scripts to pin the object
> > in memory.
> >
> > SELECT A.* FROM
> > (SELECT owner,name, sharable_mem
> > FROM v$db_object_cache
> > WHERE type In( 'FUNCTION', 'PROCEDURE', 'PACKAGE', 'PACKAGE
> > BODY', 'TRIGGER')
> > ORDER BY sharable_mem DESC) A
> > WHERE rownum < 20;
> >
> > And then use dbms_shared_pool.keep to keep them into memory.
> >
> > Another person said, this way will cause more dbms_shared_pool
> > fragmentation because all those objects are scattered in shared_pool,
> > pin them will make those fragmentation permanent. I should bounce the
> > database and then pin them while the shared_pool is empty or at least
> > flush shared pool. Is that right?
> >
> > Another question, where are those objects pinned? In
> > shared_pool_reserved area ? Now that we do not have
> > shared_pool_reserved_min_alloc parameter, I guess any size of the
> > object will go there, am i right?
> >
> > Thanks for your help.
> >
> >
> >
> >
> >
> >
> >
> > --
> > Sent by dbadba62 from hotmail piece from com
> > This is a spam protected message. Please answer with reference header.
> > Posted via http://www.usenet-replayer.com/cgi/content/new
>
>
Received on Tue Jan 22 2002 - 19:53:35 CST
