Tuning the Shared Pool:

=======================
We will see the memory structures in the Shared Pool and how we can tune it by
keeping PL/SQL blocks in it.

The following steps will demonstrate tuning of the Shared Pool:

1. Connect to the database as SYSDBA:
CONNECT / AS SYSDBA

2. Inspect which objects can be shared by querying the V$DB_OBJECT_CACHE dynamic

performance view:
We query the V$DB_OBJECT_CACHE dynamic performance view, in order to inspect what
database objects are actually cached in the Shared Pool.

COL OWNER FOR A20

COL NAME FOR A30
COL TYPE FOR A20
SELECT OWNER, NAME, TYPE, SHARABLE_MEM
FROM V$DB_OBJECT_CACHE
WHERE TYPE IN ('PACKAGE', 'PACKAGE BODY', 'PROCEDURE',
'FUNCTION', 'TRIGGER')
AND KEPT = 'NO'
ORDER BY SHARABLE_MEM;

This query can help us decide what objects to keep in memory, based on the memory
requirement (the SHARABLE_MEM column). We can also query the EXECUTIONS column to
see objects that are used most often.

3. Force a package to be kept in the shared pool:

EXEC SYS.DBMS_SHARED_POOL.KEEP('SYS.DBMS_SCHEDULER');

we use the DBMS_SHARED_POOL package to keep the SYS.DBMS_SCHEDULER package in the

Shared Pool. There is no public synonym to this package, so you have to reference
it with the SYS schema. The pinned package has to be fully qualified—as in our
example SYS.DBMS_SCHEDULER.

Note: If the DBMS_SHARED_POOL was not created during the installation, the
$ORACLE_HOME/rdbms/admin/dbmspool. sql script—executed as SYSDBA—will create it.

4. Show the objects in the shared pool with a certain size:

SET SERVEROUTPUT ON
EXEC SYS.DBMS_SHARED_POOL.SIZES(500);

We have used the SIZES procedure of DBMS_SHARED_POOL to show objects that are
larger than the size given in the shared pool.

5. Inspect the shared pool reserved memory:

SELECT * FROM V$SHARED_POOL_RESERVED;

Querying the V$SHARED_POOL_RESERVED dynamic performance view, we inspect the

statistics about the use of reserved space in the Shared Pool. Our goal is to
minimize the REQUEST_MISSES and REQUEST_FAILURES, similar to the Library Cache. If
the number of failed requests is increasing, we need to expand the Reserved Pool
(and probably also the Shared Pool).
Note: To size the Reserved Pool, we use the SHARED_POOL_RESERVED_SIZE
initialization parameter. The value of this parameter cannot exceed 50 percent of
the SHARED_POOL_SIZE parameter.

6. Inspect data dictionary cache statistics:

COL PARAMETER FOR A20
SELECT PARAMETER, GETS, GETMISSES,
(GETS-GETMISSES)*100/GETS AS "Hit Ratio",
MODIFICATIONS, FLUSHES
FROM V$ROWCACHE WHERE GETS > 0;

We query the V$ROWCACHE dynamic performance view to obtain Dictionary Cache

statistics, also calculating the Hit Ratio.

7. Keep PL/SQL anonymous blocks in the shared pool:

We execute a (simple) anonymous PL/SQL block and then query V$SQLAREA to identify
the ADDRESS and HASH_VALUE of the statement. We then use these values as parameters
for the KEEP procedure of DBMS_SHARED_POOL package to pin the anonymous block in
the Shared Pool.

DECLARE I NUMBER;
BEGIN
/* BLOCK_TO_KEEP */
I := 26;
END;
/

SELECT ADDRESS, HASH_VALUE

FROM V$SQLAREA
WHERE SQL_TEXT LIKE '%BLOCK_TO_KEEP%'
AND COMMAND_TYPE = 47;
EXEC SYS.DBMS_SHARED_POOL.KEEP ('3F0A8A14,1609869453);

In the Shared Pool, it is possible to have fragmentation, because loading large

objects requires more free space, so we need to unload many small objects to free
the required space. The freed space may be not contiguous, leading to
fragmentation. To avoid this situation, we can reserve some space for large objects
and keep them in this reserved space.

Note: We can also "pin" some objects in the Shared Pool using the
DBMS_SHARED_POOL.KEEP procedure. The pinned objects are removed from the Least
Recently Used list, so they are never aged out and removed from the Shared Pool.

You can experience ORA-4031 error (unable to allocate "x" bytes of shared memory)
if there is no free block with the
required memory in the shared pool, due to fragmentation. You can find a good place
to start investigating ORA-4031 error on Oracle Blogs at the following site:
http://blogs.oracle.com/db/entry/ora-4031_ troubleshooting

Due to the LRU algorithm, blocks of code can be aged out of the shared pool. When a
large block is aged out to make room for a small piece of code, and is needed
again, then the large block is reloaded. There can be fragmentation in the Shared
Pool, which causes
performance degradation.
To avoid fragmentation, we can separate the memory required to store frequently
used large blocks of code from other blocks, using the Shared Pool Reserved Space.
We need to set the SHARED_POOL_RESERVED_SIZE initialization parameter. Querying the
V$SHARED_POOL_RESERVED dynamic performance view, we can inspect the Reserved Pool
statistics.

In this view, we need to lower the value for REQUEST_MISSES and REQUEST_FAILURES.
Using the V$DB_OBJECT_CACHE, we can inquire for large objects that are not kept in
the Shared Pool and decide to keep them in the reserved pool using the KEEP
procedure of the
DBMS_SHARED_POOL package. Doing so also prevents flushing of the pinned object when
executing the ALTER SYSTEM FLUSH SHARED_POOL command.

The SIZES procedure of the same package allows us to identify the objects that
exceed the defined size in the Shared Pool.

A problem may arise when there are large PL/SQL anonymous blocks. In these
situations, we have two alternatives—the first, as explained in the recipe, is to
keep the anonymous block in the Reserved Pool, using the ADDRESS and HASH_VALUE to
identify the statement to keep;

these values are obtained from the V$SQLAREA dynamic performance view. The second
alternative, to improve performance when we have large PL/SQL anonymous blocks, is
to divide large blocks into smaller blocks that execute stored procedures.

Note: We can use the V$SHARED_POOL_ADVICE dynamic performance view to obtain

information about estimated parse time in the shared pool for different shared pool
sizes, with a range from 10 percent to 200 percent of the current shared pool size,
in equal intervals.

The column ESTD_LC_TIME_SAVED indicate the estimated elapsed parse time saved in
seconds, while the ESTD_LC_LOAD_TIME column contains estimated elapsed time in
seconds for parsing.