Library Cache Contention
Here are the correct solutions:
execute dbms_shared_pool.keep: Pin an SQL package in the library cache.
ALTER SYSTEM FLUSH SHARED_POOL: Clear all non-pinned SQL from the library cache.
- Increase shared_pool init.ora parameter: Add more memory blocks to the library cache.
- Adding host variables: Make SQL re-usable by using multiple tasks.
Keeping Large Objects to Prevent Aging
After an entry has been loaded into the shared pool, it cannot be moved. Sometimes, as entries are loaded and aged, the free memory can become fragmented.
Use the PL/SQL package DBMS_SHARED_POOL to manage the shared pool. Shared SQL and PL/SQL areas age out of the shared pool according to a least recently used LRU algorithm,
similar to database buffers. To improve performance and prevent reparsing, you might want to prevent large SQL or PL/SQL areas from aging out of the shared pool.
The DBMS_SHARED_POOL package enables you to keep objects in shared memory, so that they do not age out with the normal LRU mechanism. By using the DBMS_SHARED_POOL package and by loading the SQL and PL/SQL areas before memory fragmentation occurs, the database can keep objects in memory.
This technique ensures that memory is available, and it prevents the sudden, inexplicable slowdowns in user response time that occur when SQL and PL/SQL areas are accessed after aging out.
The DBMS_SHARED_POOL package is useful for the following:
- When loading large PL/SQL objects, such as the STANDARD and DIUTIL packages
When large PL/SQL objects are loaded, user response time may be affected if smaller objects that must age out of the shared pool to make room.
In some cases, there might be insufficient memory to load the large objects.
- Frequently executed triggers: You might want to keep compiled triggers on frequently used tables in the shared pool.
- Sequences: Sequence numbers are lost when a sequence ages out of the shared pool. DBMS_SHARED_POOL keeps sequences in the shared pool, thus preventing the loss of sequence numbers.
To use the DBMS_SHARED_POOL package to pin a SQL or PL/SQL area, complete the following steps:
- Decide which packages or cursors to pin in memory.
- Start up the database.
- Make the call to DBMS_SHARED_POOL.KEEP to pin your objects.
This procedure ensures that your system does not run out of shared memory before the kept objects are loaded.
By pinning the objects early in the life of the instance, you prevent memory fragmentation that could result from pinning a large portion of memory in the middle of the shared pool.