Shared Pool   «Prev  Next»

Create Tuning Parameters in Oracle

Here are the terms to be reviewed.
  1. shared_pool_size: Causes shared SQL areas to be de-allocated from the library cache after use
  2. cursor_space_for_time: Oracle will cache the cursors for a query
  3. session_cached_cursors: Determines the overall size of the shared pool memory
  4. dbms_shared_pool: An Oracle-supplied package to pin packages in the shared pool


SHARED_POOL_SIZE specifies (in bytes) the size of the shared pool. The shared pool contains shared cursors, stored procedures, control structures, and other structures. If you set PARALLEL_AUTOMATIC_TUNING to false, then Oracle also allocates parallel execution message buffers from the shared pool. Larger values improve performance in multi-user systems. Smaller values use less memory. You can monitor utilization of the shared pool by querying the view V$SGASTAT.


CURSOR_SPACE_FOR_TIME lets you use more space for cursors in order to save time. It affects both the shared SQL area and the client's private SQL area.
  1. TRUE: Shared SQL areas are kept pinned in the shared pool. As a result, shared SQL areas are not aged out of the pool as long as an open cursor references them. Because each active cursor's SQL area is present in memory, execution is faster. However, the shared SQL areas never leave memory while they are in use. Therefore, you should set this parameter to TRUE only when the shared pool is large enough to hold all open cursors simultaneously. In addition, a setting of TRUE retains the private SQL area allocated for each cursor between executions instead of discarding it after cursor execution, saving cursor allocation and initialization time.
  2. FALSE: Shared SQL areas can be deallocated from the library cache to make room for new SQL statements.


Property Description
Parameter type Integer
Default value 50
Range of values 0 to operating system-dependent
Real Application Clusters Multiple instances can have different values.

SESSION_CACHED_CURSORS specifies the number of session cursors to cache. Repeated parse calls of the same SQL statement cause the session cursor for that statement to be moved into the session cursor cache. Subsequent parse calls will find the cursor in the cache and do not need to reopen the cursor. Oracle uses a least recently used algorithm to remove entries in the session cursor cache to make room for new entries when needed. This parameter also constrains the size of the PL/SQL cursor cache which PL/SQL uses to avoid having to reparse as statements are re-executed by a user.