The choice of whether to pin a package in memory is a function of the size of the object and the frequency of its use. Very large packages
that are called frequently might benefit from pinning, but any difference might go unnoticed because the frequent calls to the procedure have
kept it loaded into memory anyway. Therefore, because the object never pages out in the first place, pinning has no effect.
Also, the way procedures are grouped into packages can have some influence. Some Oracle DBAs identify high-impact procedures
and group them into a single
package, and then pin this package in the shared pool library cache.
I highly recommend that you store all SQL in packages if you have enough shared_pool memory. Storing SQL in packages has several benefits. It
ensures that all SQL is uniform and reusable, and it makes it possible to pin the SQL packages.
UNIX users might want to add code to their database startup script to ensure that the packages are re-pinned after each database startup,
guaranteeing that all packages are re-pinned with each bounce of the box. A script might look like this:
As a database administrator, you also need to remember to run pin.sql whenever restarting a database. This is done by reissuing the PIN
command from inside SQL*DBA immediately after the database has been restarted.
If you have large procedures or large anonymous PL/SQL blocks in your application, you may also want to put these into packages and pin them
in the shared pool. You can determine what large stored objects are in the shared pool by selecting from the V$DB_OBJECT_CACHE fixed view.
This will also tell you which objects have been marked kept. This can be done with the following query:
cursor pkgs is
object_type = 'PACKAGE';
begin open pkgs;
loop fetch pkgs into own, nam;
exit when pkgs%notfound;
dbms_shared_pool.keep(own || '.' || nam, 'P');
In the next lesson, we will look at tuning the shared pool reserved size.