Pinning Tables into SGA ( Performance )

Identify Tables & Indexes need to be pinned onto SGA:

***************************************************************************

  SELECT    'alter table '

         || p.owner

         || '.'

         || p.name

         || ' storage (buffer_pool keep);'

    FROM dba_tables t,

         dba_segments s,

         dba_hist_sqlstat a,

         (SELECT DISTINCT pl.sql_id, pl.object_owner owner, pl.object_name name

            FROM dba_hist_sql_plan pl

           WHERE pl.operation = 'TABLE ACCESS' AND pl.options = 'FULL') p

   WHERE     a.sql_id = p.sql_id

         AND t.owner = s.owner

         AND t.table_name = s.segment_name

         AND t.table_name = p.name

         AND t.owner = p.owner

         AND t.owner NOT IN ('SYS', 'SYSTEM')

         AND t.buffer_pool <> 'KEEP'

  HAVING s.blocks < 50

GROUP BY p.owner,

         p.name,

         t.num_rows,

         s.blocks

UNION

SELECT    'alter index '

       || owner

       || '.'

       || index_name

       || ' storage (buffer_pool keep);'

  FROM dba_indexes

 WHERE owner || '.' || table_name IN

             (  SELECT p.owner || '.' || p.name

                  FROM dba_tables t,

                       dba_segments s,

                       dba_hist_sqlstat a,

                       (SELECT DISTINCT

                               pl.sql_id,

                               pl.object_owner owner,

                               pl.object_name name

                          FROM dba_hist_sql_plan pl

                         WHERE pl.operation = 'TABLE ACCESS'

                               AND pl.options = 'FULL') p

                 WHERE     a.sql_id = p.sql_id

                       AND t.owner = s.owner

                       AND t.table_name = s.segment_name

                       AND t.table_name = p.name

                       AND t.owner = p.owner

                       AND t.owner NOT IN ('SYS', 'SYSTEM')

                       AND t.buffer_pool <> 'KEEP'

                HAVING s.blocks < 50

              GROUP BY p.owner,

                       p.name,

                       t.num_rows,

                       s.blocks);

**********************************************************************

dbms_Shared_pool ( Performance )

dbms_shared_pool

Imagine a large object has to be loaded into the shared pool.

The database has to search for free space for the object.

If it cannot get enough contiguous space, it will free many small objects to satisfy the request.

If several large objects need to be loaded, the database has to throw out many small objects in the shared pool.

Finding candidate objects and freeing memory is very costly.  These tasks will impact CPU resources.

One approach to avoiding performance overhead and memory allocation errors is to keep large PL/SQL objects in the shared pool at startup time.This process is known as pinning.

This loads the objects into the shared pool and ensures that the objects are never aged out of the shared pool. If the objects are never aged out, then that avoids problems with insufficient memory when trying to reload them.


Pinning an object :  exec dbms_shared_pool.keep('owner.object');

View Pinned objects : select owner,name,type,sharable_mem from v$db_object_cache where kept='YES';


How to Identify candidates that should be kept in the shared pool:

Step 1 :
select owner||'.'||name  Name ,
           type,
           sharable_mem,
           loads,
           executions,
           kept
from v$db_object_cache
where type in ('TRIGGER','PROCEDURE','PACKAGE BODY','PACKAGE') and executions >0
order by executions desc,loads desc,sharable_mem desc;

Step 2:

select * from x$ksmlru;

The x$ksmlru table keeps track of the current shared pool objects and the corresponding number of objects flushed out of the shared pool to allocate space for the load. These objects are stored and flushed out based on the Least Recently Used (LRU) algorithm.

KSMLRNUM  shows the number of objects that were flushed to load the large object
KSMLRISZ shows the size of the object that was loaded (contiguous memory allocated).

Analyze the x$ksmlru output to determine if there are any large allocations that are flushing other objects.
If this is the case, analyze the v$db_object_cache to identify the objects with high loads or executions.  These should be kept in the shared pool.