Results from V$DB_OBJECT_CACHE - the next move?

Question

Hi.
I have run this query onour production db to show which objects we dont have cached in the shared pool.
select owner, name, type, sharable_mem, executions
from V$DB_OBJECT_CACHE
where sharable_mem > 10000
and type in ('PACKAGE', 'PACKAGE BODY', 'PROCEDURE', 'FUNCTION', 'TRIGGER')
and kept = 'NO'
order by sharable_mem desc
there are a considerable number of packages that are not cached (sharred memory of 130893 and executions of 1001559) and which should be cached.
There is this statement to cache them:
EXEC SYS.DBMS_SHARED_POOL.KEEP ('object name');
Before I get the go ahead to do this, our DBA wants to know what impact this will have on the db.
Will I have to increase the shared pool size to accomodate the objects I pin there, or will it dynamically grow?
Note: I have verified the size of our shared pool and its
384M, and its set to dynamically grow.
The issue I suppose is if I add several objects, we need to be sure the shared pool doesnt grow too much - how much is too much? Should I calculate the extra memory needed for each package I add to the shared pool and discuss that with our DBA?
Thanks.
Oracle 9.2. AIX UNIX
Message was edited by:
Dan A

Answer 1

Don, I am still reading the link you sent. I ran the query you posted and that seems to produce a list of all the packages that we have, and wheather they are stored or not.
I guess the golden question is, as you put it , why should they be cached? No, we dont have standard as I know.
I will continue to read your link on the "recommended" pinned packages.
Actually your link hits the nail on the head when it states:
The choice of whether to "pin" a procedure in memory is a function of the size of the object and the frequency that it is used. Very large procedures that are called frequently might benefit from pinning, but you might never notice any difference because the frequent calls to the procedure have kept it loaded into memory. Therefore, since the object never pages-out, the pinning has no effect.
In an ideal world, the shared_pool parameter of the init.ora should be large enough to accept every package, stored procedure and trigger that may be invoked by the applications. Reality, however, dictates that the shared pool cannot grow indefinitely, and wise choices must be made regarding which objects are fenced
Those "wise choices" remain to be made!
Thanks a lot.
Checking out Metalink, note 1012047.6, explains how to oin the package, adn when we should do it. But if doenst mention any other impact that this could have on the db performance. I need some of you experienced guys out there to give me this advice please!
Perhaps one idea might be to use this query to see the size of the library cache within the shared pool:
select name, bytes/1024/1024 "MB"
from v$sgastat
where pool = 'shared pool'
order by bytes desc;
and do this in test: add the packages that I want to add in Production and see how the size is affected.
Message was edited by:
Dan A