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 - 22:19:51 CST
