Shared Pool   «Prev 

Shared Pool Components

Components of the shared pool 1) SESSION MEMORY 2) LIBRARY CACHE 3) DICTIONARY CACHE

  1. This stores the plan information for SQL that is currently being executed. This area also holds stored procedures and trigger code. The SQL areas within the library cache hold SQL in the hope that a repeated SQL statement would not need to be re-parsed each time the SQL is processed.
  2. This stores environmental information, including referential integrity, table definitions, indexing information, and other metadata stored within Oracle's internal tables.
  3. This stores session information for systems that are using SQL*Net or Net8 with Oracle's multithreaded server. For systems that do not use the MTS, this area will not use much space.

Main Components of the Shared Pool

The main components of the shared pool are the library cache, the dictionary cache, and, depending on your configuration, the server result cache. The library cache stores the executable (parsed or compiled) form of recently referenced SQL and PL/SQL code. The dictionary cache stores data referenced from the data dictionary. The server result cache stores the results of queries and PL/SQL function results. Many of the caches in the shared pool automatically increase or decrease in size, as needed, including the library cache and the dictionary cache. Old entries are aged out to accommodate new entries when the shared pool does not have free space. A cache miss on the data dictionary cache or library cache is more expensive than a miss on the buffer cache. For this reason, the shared pool should be sized to ensure that frequently used data is cached. Several features make large memory allocations in the shared pool: for example, the shared server, parallel query, or Recovery Manager. Oracle recommends segregating the SGA memory used by these features by configuring a distinct memory area, called the large pool. Allocation of memory from the shared pool is performed in chunks. This chunking enables large objects (over 5 KB) to be loaded into the cache without requiring a single contiguous area. In this way, the database reduces the possibility of running out of enough contiguous memory due to fragmentation. Infrequently, Java, PL/SQL, or SQL cursors may make allocations out of the shared pool that are larger than 5 KB. To allow these allocations to occur most efficiently, Oracle Database segregates a small amount of the shared pool. This memory is used if the shared pool does not have enough space. The segregated area of the shared pool is called the reserved pool.