Memory Structure

The basic memory structures associated with Oracle Database include:

System global area (SGA)

The SGA is a group of shared memory structures, known as SGA components that contain data and control information for one Oracle Database instance. The SGA is shared by all server and background processes. Examples of data stored in the SGA include cached data blocks and shared SQL areas.

Program global area (PGA)

A PGA is a non-shared memory region that contains data and control information exclusively for use by an Oracle process. The PGA is created by Oracle Database when an Oracle process is started. One PGA exists for each server process and background process. The collection of individual PGAs is the total instance PGA, or instance PGA. Database initialization parameters set the size of the instance PGA, not individual PGAs.

User Global Area (UGA)

The UGA is memory associated with a user session.

Software code areas

Software code areas are portions of memory used to store code that is being run or can be run. Oracle Database code is stored in a software area that is typically at a different location from user programsa more exclusive or protected location.

SGA (System Global Area)

The SGA is a chunk of memory that is allocated by an Oracle Instance (during the nomount stage) and is shared among Oracle processes. It contains all sorts of information about the instance and the database that is needed to operate. The SGA's size and function are controlled by initialization (INIT.ORA or SPFILE) parameters. Few properties of SGA:

1. SGA always resides in system RAM, as per recommendation SGA+PGA size should not be more than 60 to 65% of RAM. 2. This is shared among multiple users at same time. So called Shared Global area as well. 3. An SGA and Oracle processes constitute an Oracle instance. Oracle automatically allocates memory for an SGA when you start an instance, and the operating system reclaims the memory when you shut down the instance. 4. Multiple instances can be associated with a database in a RAC system, and each instance has its own SGA. 5. The SGA is read/write. Any change in database is first of all is done into SGA then into database. 6. The SGA contains five main areas.

The fixed area. The variable area. The database buffer cache. The log buffer. The resource directory for a RAC system.

The fixed area of the SGA contains several thousand atomic variables. These are small data structures, such as latches and pointers, which refer to other areas of the SGA. The size of the fixed area is static. It also contains general information about the state of the database and the instance which the background processes need to access. Or The fixed SGA is a component of the SGA that varies in size from platform to platform and release to release. It is compiled into the database. The fixed SGA contains a set of variables that point to the other components of the SGA and variables that contain the values of various parameters like db_block_size and so on (constants basically for the currently mounted database).The size of the fixed SGA have no control and it is generally very small. Think of this area as a bootstrap section of the SGA, something Oracle uses internally to find the other bits and pieces of the SGA. The size of the fixed portion is constant for a release and a platform of Oracle, that is, it cannot be changed through any means such as altering the initialization parameters. The fixed size component is out of our control. It varies from release to release and platform to platform. Thus it contains a collection of objects that point to other areas inside the rest of the SGA -- think of it as the "road map" to the rest of the SGA. So, in general -- the fixed size is computed for you when Oracle is compiled. You can do nothing to affect it.

The variable area of the SGA is made up of a shared pool, large poo, java pool and stream pool. The variable portion is called variable because its size (measured in bytes) can be changed. The variable size is MOST affected by java_pool_size + large_pool_size + stream_pool_size + shared_pool_size but other parameters will contribute to it (eg: every control_file will consume 256 bytes of variable size memory. If you have 4 control files, the SGA will have 1024 bytes set aside for them) in a small way.

For consideration of the variable size SQL>compute sum of bytes on pool SQL>break on pool skip 1 SQL>set pages 200 SQL>set pause on SQL>select pool, name, bytes fromv$sgastat pool, name;

order by

LARGE POOL - The large pool is an optional area. It is configured by the LARGE_POOL_SIZE init.ora parameter. Large pool is configured as a separate heap within a variable area of the SGA. The large pool is not a part of the shared pool. It is used for allocation of "big" chunks of memory such as used by MTS, Parallel Query, and RMAN. In shared server the large pool hold the UGA. JAVA POOL - The Java pool is configured by the JAVA_POOL_SIZE init.ora parameter. The Java pool is a fixed amount of memory allocated for the JVM running in the database. STREAM POOL - The Stream pool is a portion of memory in the System Global Area (SGA) that is used by Streams. It is configured by STREAM_POOL_SIZE. SHARED POOL It is a component of SGA. The purpose of the shared pool is to cache the executable versions of SQL and PL/SQL statements. This allows multiple executions of the same SQL or PL/SQL code to be performed without the resources required for a hard parse, which results in significant reductions in CPU, memory, and latch usage. The total size of the shared pool is determined by the initialization parameter SHARED_POOL_SIZE. The default value of this parameter is 8MB on 32-bit platforms and 64MB on 64-bit platforms. Increasing the value of this parameter increases the amount of memory reserved for the shared pool. The shared pool contains the library cache, the dictionary cache, session information, and buffers for parallel execution messages. The main components of the shared pool are the library cache and the dictionary cache.

Library Cache - The library cache stores the executable (parsed or compiled) form of recently referenced SQL and PL/SQL code.The library cache includes the shared SQL areas for storing the most recently executed SQL statements, private SQL areas (in shared server), shared PL/SQL areas for storing the most recently executed PL/SQL statements, and control structures such as library cache handles, locks, synonym translations, and dependency tracking information. Library Cache contains parse trees and execution plans for shareable SQL statements, as well as pseudo code for PL/SQL program units. All users access the shared SQL areas and shared PL/SQL areas. Library Cache is managed by a LRU (Least Recently Used) algorithm Dictionary Cache Dictionary Cache is used for storing recently accessed information from the oracle data dictionary, Includes the usernames, passwords, privileges, segment information, profile data, tablespace information, and the sequence numbers. The dictionary cache also contains descriptive information or metadata about the schema objects. Oracle uses this metadata when parsing SQL cursors or during the compilation of PL/SQL programs. The dictionary cache is also known as the row cache because it holds the data in rows instead of buffers. It also holds entire blocks of data. This helps to reduce physical access to the data dictionary tables from the system tablespace, and also enables fine-grained locking of individual data dictionary rows. Library Cache vs. Data Dictionary Cache We see that Library Cache is used to store the recently executed SQL and PL/SQL statements, which eliminates the need for parsing and compiling the statements again if used subsequently and hence improves performance. Whereas, the Data Dictionary Cache is used to store the information which improves the validation phase of the execution of those SQL and PL/SQL statements. So, both the memory structures can be visualized as being complimentary to each other. Library Cache Concepts The library cache holds executable forms of SQL cursors, PL/SQL programs, and Java classes. This section focuses on tuning as it relates to cursors, PL/SQL programs, and Java classes. These are collectively referred to as application code. When application code is run, Oracle attempts to reuse existing code if it has been executed previously and can be shared. If the parsed representation of the statement does exist in the library cache and it can be shared, then Oracle reuses the existing code. This is known as a soft parse, or a library cache hit. If Oracle is unable to use existing code, then a new executable version of the application code must be built. This is known as a hard parse, or a library cache miss. Library cache misses can occur on either the parse step or the execute step when processing a SQL statement. When an application makes a parse call for a SQL

statement, if the parsed representation of the statement does not already exist in the library cache, then Oracle parses the statement and stores the parsed form in the shared pool. This is a hard parse. You might be able to reduce library cache misses on parse calls by ensuring that all shareable SQL statements are in the shared pool whenever possible. If an application makes an execute call for a SQL statement, and if the executable portion of the previously built SQL statement has been aged out (that is, deallocated) from the library cache to make room for another statement, then Oracle implicitly reparses the statement, creating a new shared SQL area for it, and executes it. This also results in a hard parse. Usually, you can reduce library cache misses on execution calls by allocating more memory to the library cache. In order to perform a hard parse, Oracle uses more resources than during a soft parse. Resources used for a soft parse include CPU and library cache latch gets. Resources required for a hard parse include additional CPU, library cache latch gets, and shared pool latch gets. All memory in the large pool is dynamically allocated, whereas the shared pool contains both dynamically managed memory and a permanent memory.

Database buffer cache The database buffer cache, also called the buffer cache, is the component of SGA that stores copies of data blocks read from data files. With a few exceptions, any data coming in or going out of the database will pass through the buffer cache.In the other word we can say that, the database buffer cache consists of the memory buffers that Oracle uses to hold the data read bythe server process from data files on disk in response to user requests. Buffer cache access is much faster than reading the data from disk storage. We can group the memory buffers in the database buffer cache into three components: Free buffers: These are buffers that do not contain any useful data, and, thus, the database can reuse them to hold new data it reads from disk. Dirty buffers: These contain data that was read from disk and then modified, but hasnt yet been written to the data files on disk. Pinned buffers: These are data buffers that are currently in active use by user sessions.

The buffers in the cache are organized in two lists: the write list and the least recently used (LRU) list. The write list holds dirty buffers, which contain data that has been modified but has not yet been written to disk. The LRU list holds free buffers, pinned buffers, and dirty buffers that have not yet been moved to the write list. Free buffers do not contain any useful data and are available for use. Pinned buffers are currently being accessed.

When an Oracle Database process accesses a buffer, the process moves the buffer to the most recently used (MRU) end of the LRU list. As more buffers are continually accessed and moved to the MRU end of the LRU list, dirty buffers will age out toward the LRU end of the LRU list. A dirty buffer is a buffer whose contents have been modified. Dirty buffers are freed for reuse when DBWR has written the blocks to disk. When an Oracle Database user process requires a particular piece of data, Oracle server process will first searches for the data in the database buffer cache. If the process finds the data already in the cache, (a cache hit), it can read the data directly from memory and send it to the user, this event is known as Cache Hit. If the process cannot find the data in the cache (a cache miss), it must copy the data block from a datafile on disk into a buffer in the cache before accessing the data, this event is called Cache Miss. Accessing data through a cache hit is faster than data access through a cache miss. If the required data block is not found in Buffer cache then process needs a free buffer in buffer cache to read data from disk. The process searches the LRU list, starting at the least recently used end of the list. The process searches either until it finds a free buffer or until it has searched the threshold limit of buffers. If the user process finds a dirty buffer as it searches the LRU list, it moves that buffer to the write list and continues to search. When the process finds a free buffer, it reads the data block from disk into the buffer and moves the buffer to the MRU end of the LRU list. If an Oracle Database user process searches the threshold limit of buffers without finding a free buffer, the process stops searching the LRU list and signals the DBW0 background process to write some of the dirty buffers to disk. Or When oracle server process requires a specific data block, it first searches it in Buffer cache. If it finds required block, it is directly accessed and this event is known as Cache Hit. If searching in Buffer cache fails then it is read from datafile on the disk and the event is called Cache Miss. If the required block is not found in Buffer cache then process needs a free buffer to read data from disk.It starts search for free buffer from least recently used end of LRU list. In process of searching, if user process finds dirty block in LRU list it shifts them to Write List. If the process cannot find free buffers until certain amount of time then process signals DBWn process to write dirty buffers to disks. Multiple Database Buffer Cache Pools Data required by oracle user process is loaded into buffer cache, if it is not already present in cache. Proper memory tuning is required to avoid repeated disk access for the same data. This means that there should be enough space in buffer cache to hold

required data for long time. If same data is required in very short intervals then such data should be permanently pinned into memory. Oracle allows us to configure the databasebuffer cache into multiple buffer pools. A buffer pool in this context is simply a part of the totalbuffer cache that is subject to different retention criteria for database objects like tables.You can then assign specific schema objects to the appropriate buffer pool to control how blocks age out of the cache. The database buffer cache is divided into one or more buffer pools.The possible buffer pools are as follows: Keep Buffer Pool This pool is intended for blocks that were accessed frequently, but which aged out of the default pool because of lack of space. The goal of the keep buffer pool is to retain objects in memory, thus avoiding I/O operations. Data which is frequently accessed should be kept in Keep buffer pool. Keep buffer pool retains data in the memory. So that next request for same data can be entertained from memory. This avoids disk read and increases performance. Usually small objects should be kept in Keep buffer. DB_KEEP_CACHE_SIZE initialization parameter is used to create Keep buffer Pool. If DB_KEEP_CACHE_SIZE is not used then no Keep buffer is created. Use following syntax to create a Keep buffer pool of 40 MB. DB_KEEP_CACHE_SIZE=40M To pin an object in Keep buffer pool use DBMS_SHARED_POOL.KEEP method. Recycle Buffer Pool Blocks loaded in Recycle Buffer pool are immediate removed when they are not being used. It is useful for those objects which are accessed rarely. As there is no more need of these blocks so memory occupied by such blocks is made available for others data. For example if ASM is enabled then available memory can be assigned to other SGA components . Use following syntax to create a Recycle Buffer Pool DB_RECYCLE_CACHE_SIZE=20M Default Pool If an object is not assigned a specific buffer pool then its blocks are loaded in default pool DB_CACHE_SIZE initialization parameter is used to create Default Pool. BUFFER_POOL value in storage clause of schema objects lets you to assign an object to a specific Buffer pool. Value of BUFFER_POOL can be KEEP,RECYCLE or DEFAULT.

Once you have created separate buffer pools, you can assign a table exclusively to that buffer pool when you create that table. You can also use the ALTER TABLE or ALTER INDEX command to modify the type of buffer pool that a table or index should use. Note that any database objects that you havent assigned to the keep or the recycle buffer pool will be assigned to the default buffer pool, which is sized according to the value you provide for the DB_CACHE_SIZE initialization parameter. The keep and the recycle buffer pools are purely optional, while the default buffer pool is mandatory. Remember that the main goal in assigning objects to multiple buffer pools is to minimize themisses in the data cache and thus minimize your disk I/O. In fact, all buffer caching strategies havethis as their main goal. If you arent sure which objects in your database belong to the differenttypes of buffer caches, just let the database run for a while with some best-guess multiple cachesizes and query the data dictionary view V$DB_CACHE_ADVICE to get some advice from Oracle itself. Multiple Database Block Sizes and the Buffer Cache A database has a standard block size. We can create a tablespace with a block size that differs from the standard size. Each non-default block size has its own pool. Oracle Database manages the blocks in these pools in the same way as in the default pool. The cache contains default, keep, and recycle pools. The default block size is 8 KB. The cache contains separate pools for tablespaces that use the nonstandard block sizes of 2 KB, 4 KB, and 16 KB. For example: We can specify different values for each of the buffer cachessubcaches in your initialization parameter file. In the example, the numbers on the right show thememory allocated to a particular type of buffer cache.
DB_KEEP_CACHE_SIZE = 48MB DB_RECYCLE_CACHE_SIZE = 24MB DB_CACHE_SIZE = 128MB /* standard 4KB block size */ DB_2k_CACHE_SIZE =48MB /* 2KB non-standard block size */ DB_8k_CACHE_SIZE =192MB /* 8KB non-standard block size */ DB_16k_CACHE_SIZE = 384MB /* 16KB non-standard block size */

The total buffer cache size in this example will be the sum of all the above sub-caches, whichcomes to about 824MB.

Database Write, DBWR

DBWR job is to write data from the database buffer cache to the data files. The DBWR writes the data based on the write list in the buffer cache. When does the flushing of dirty buffer occurs? 1. Unable to find free buffer after scanning a threshold number of buggers in the buffer cache. 2. Will periodically writes buffer to advance in checkpoint which will be be in-sync between the redo theads and datafile headers. Database Buffer Cache

Important Concepts! Dirty buffer does NOT mean that it is committed or uncommitted data. It merely means that the data block in the data file is not consistent with the data in buffer cache, it has been modified by the database instance. When the uncommitted data is being flushed by the DBWR to the data file, a checkpoint SCN will be updated in the control file but not to the data file headers. At this point of time, if another process tries to access the same piece of data block, it will read the SCN from the data file header and knows that it does not have the consistent data (control file SCN does not tally with data file SCN) and reads the consistent data from the UNDO segment.

The LRU Algorithm and Full Table Scans When the user process is performing a full table scan, it reads the blocks of the table into buffers and puts them on the LRU end (instead of the MRU end) of the LRU list. This

is because a fully scanned table usually is needed only briefly, so the blocks should be moved out quickly to leave more frequently used blocks in the cache. You can control this default behavior of blocks involved in table scans on a table-bytable basis. To specify that blocks of the table are to be placed at the MRU end of the list during a full table scan, use the CACHE clause when creating or altering a table or cluster. You can specify this behavior for small lookup tables or large static historical tables to avoid I/O on subsequent accesses of the table.

Redo log buffer -The redo log buffer is a circular buffer in the SGA that holds redo entries (redo records)describing changes made to the database. Redo entries contain the information necessary to reconstruct, or redo, changes made to the database by INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP operations. Database recovery applies redo entries to data files to reconstruct lost changes. Redo Entry / Redo Record: - A redo entry, also known as redo record is a collection of change vectors. A change vector describes a change to a single data block made by a transaction in the database. Change vector is created in PGA before the data block buffer is modified. Many change vectors are grouped together to create a redo record. This redo record is created in the PGA of the process, and then copied to log buffer. Redo records transitions the database from one state to another state. All or none of the change vectors from a redo record will be applied. Oracle Database processes copy redo entries from the user memory space to the redo log buffer in the SGA. The redo entries take up continuous, sequential space in the buffer. The background process log writer (LGWR) writes the redo log buffer to the active online redo log group on disk. Log writer process (LGWR) writes redo entries after certain amount of time to ensure that free space is available for new redo entries. LGWR process writes When user performs commit After every three seconds When redo log buffer is 1/3 full. When redo log buffer contains 1MB of cached redo log data. When DBWn process writes data to disk and redo entries of these data hasnt been written yet.

When DBWn writes modified data from Database buffer cache to disk, corresponding redo entries must also be written to disk. In fact redo entries are written prior to writing actual entries. DBWn process checks for redo entries, it signal LGWR process if redo entries have not been written.

If database is running in archiving mode then archive log files are created from redo log files. These archive log files are used to in various database recovery techniques. LOG_BUFFER initialization parameter is used to set the size Redo Log buffer. Figure - Redo Log Buffer

Online redo log files are filled with redo records. A redo record, also called a redo entry, is made up of a group of change vectors, each of which is a description of a change made to a single block in the database. For example, if you change a salary value in an employee table, oracle generate a redo record containing change vectors that describe changes to the data segment block for the table, the rollback segment data block, and the transaction table of the rollback segments. Redo entries record data that you can use to reconstruct all changes made to the database, including the rollback segments. Therefore, the online redo log also protects rollback data.When you recover the database using redo data, Oracle reads the change vectors in the redo records and applies the changes to the relevant blocks. When an update statement is fired, 3 change vectors will be created 2. Changes to the data block. 3. Changes to the rollback block. 4. Changes to the transaction table of rollback block. So the redo will have both the old value and also new value. Redo records are buffered in a circular fashion in the redo log buffer of the SGA and are written to one of the online redo log files by the Oracle background process Log Writer (LGWR). Whenever a transaction is committed, LGWR writes the transaction's redo records from the redo log buffer of the SGA to an online redo log file, and a system change number (SCN) is assigned to identify the redo records for each committed transaction. Only when all redo records associated with a given transaction are safely on

disk in the online logs is the user process notified that the transaction has been committed. Redo records can also be written to an online redo log file before the corresponding transaction is committed. If the redo log buffer fills, or another transaction commits, LGWR flushes all of the redo log entries in the redo log buffer to an online redo log file, even though some redo records may not be committed. If necessary, Oracle can roll back these changes.

SGA Components In general, the SGA consists of the following sub-components, as can be verified by querying the V$SGAINFO: SELECT * FROM v$sgainfo; The common components are:

Data buffer cache - cache data and index blocks for faster access. Shared pool - cache parsed SQL and PL/SQL statements. Dictionary Cache - information about data dictionary objects. Redo Log Buffer - committed transactions that are not yet written to the redo log files. JAVA pool - caching parsed Java programs. Streams pool - cache Oracle Streams objects. Large pool - used for backups, UGAs, etc.

Granule size SGA memory is allocated in unit of contiguous memory chunks called granule. The SGA memory components(shared pool,buffer cache, redo log buffer,javapool,streamspool,large pool) are sized as multiples of granules. The granule size is determined based on the amount of memory requested at the instance startup. It is based on the SGA_MAX_SIZE. If MEMORY_MAX_TARGET is specified, then SGA_MAX_SIZE defaults to MEMORY_MAX_TARGET for the purpose of sizing the granule. Once set, the granule size does not change for the life of the instance. However granule maximum size = 16MB on 32-bit platforms. All SGA components allocate and deallocate space in units of granules. Oracle Database tracks SGA memory use in internal numbers of granules for each SGA component.

The memory for dynamic components in the SGA is allocated in the unit of granules. Granule size is determined by total SGA size. Generally speaking, on most platforms, if the total SGA size is equal to or less than 1 GB, then granule size is 4 MB. For SGAs larger than 1 GB, granule size is 16 MB. Some platform dependencies may arise. For example, on 32-bit Windows NT, the granule size is 8 MB for SGAs larger than 1 GB. And granule maximum size = 16MB on 32-bit platforms. NOTE: - If you specify a size for a component that is not a multiple of granule size, then Oracle rounds the specified size up to the nearest multiple. For example, if the granule size is 4 MB and you specify DB_CACHE_SIZE as 10 MB, you will actually be allocated 12 MB. SQL> select bytes/1024/1024 bytes_Mb from v$sgainfo where name like 'Granule Size'; BYTES_MB ---------4 RDBMS 9.2 10.2 11gR1 SGA_MAX_SIZE (or memory_max_target) <= 128MB > 128MB <= 1GB > 1GB <= 1GB 1Gb - 4GB 4Gb - 16GB 16Gb - 64GB > 64GB < 1Gb 1Gb - 8Gb 8Gb - 16Gb 16Gb - 32Gb 32Gb - 64Gb 64Gb - 128Gb > 128Gb

11gR2 (and 11gR1 with patch 8813366 applied *)

PGA (Program global area)

A Program global area (PGA) is a memory region that contains data and control information exclusively for use by an Oracle process. It is created by Oracle Database when an Oracle process is started. The PGA of an Oracle process is not shared by other processes.i.e. The PGA (Process Global Area) is a specific piece of memory that is associated with a single process or thread, it is not accessible by any other process or thread and it is created when an oracle process is started. Oracle creates a program global area (PGA) for each user when the user starts a session. The PGA is a memory heap that contains session-dependent variables required by a dedicated or shared server process. The server process allocates memory structures that it requires in the PGA. Oracle database creates server processes to manage requests of user process. All user process issues SQL statements, it is the responsibility of Server process to execute these statements and return results to user process. Each server process has one PGA. PGA is memory where server process executes statements and stores information. It is mainly used for sorting SQL result and managing special joins called hash joins and storing session information when dedicated server is configured. PGA consists of Stack space, session memory,Private SQL Area and SQL work Areas. There are two components of PGA Stack space and User Global Area (UGA) STACK SPACE: It holds bind variables, arrays (PL/SQL) etc. A bind variable value is supplied to a SQL statement at run time when the statement is executed USER GLOBAL AREA (UGA): It contains

Session Memory:Session information such as logon information, and other information required by a database Session SQL Work areas: Used for sorting, hash operations etc. Which can be required by SQL keyword like DISTINCT, GROUP BY, ORDER BY,UNION,INTERSECT and MINUS. Private SQL area: Contains Open/Closed cursors and cursor state information for open cursors for example, the number of rows retrieved so far in a full table scan.

For complex queries, workareas in UGA are required to perform memory intensive operations. For example, a sort operator uses the sort area to sort a set of rows. Similarly, a hash join operator uses a hash area to build a hash table from its left input, whereas a bitmap merge uses the bitmap merge area to merge data retrieved from scans of multiple bitmap indexes. Memory intensive operations which make use of PGA are

Sort based operators (Order by, group by, rollup, Distinct etc.) Hash join Bitmap related operations Write buffers used by bulk load operations (Direct Path Load)

A PGA always contains a stack space, which is memory allocated to hold a session's variables, arrays, and other information. One PGA exists for each server process and background process. The collection of individual PGAs is the total instance PGA, or instance PGA. Database initialization parameters PGA_AGGREGATE_TARGET or SORT_AREA_SIZE & HASH_AREA_SIZE is used to set the size of the instance PGA, not individual PGAs.

Instance PGA

Each statement in oracle is associated with a Private SQL area. Private SQL area can be divided into persistent area and run-time area. Persistent area contains bind information, i.e. the values for bind variables. Runtime area is used to execute the statements. Private SQL area is created in PGA if the connection is established using dedicated server. In case of shard server connection, Private SQL area is created in SGA. PGA also contains Session Memory if the connection is established using dedicated server, which is used to store session information for example session variables and logon information. Few queries require complex operation like Hash Join or sorting. These operations are performed in the memory. To perform these tasks, SQL work areas are created in runtime area. The size of SQL work areas should be large enough that it can contain data accessed by SQL statements. If size of work area is not large enough then response time

may increase and hurt database performance. Oracle supports automatic memory management of work areas. Automatic management involve to steps, first you decide maximum memory available for PGA. Then use PGA_AGGREGATE_TARGET initialization parameter to set maximum memory available for PGA. This will only work for dedicated server mode. Because in shared servers, SQL work areas are created in SGA. PGA Contents

Private SQL area

A private SQL area holds information about a parsed SQL statement and other sessionspecific information for processing. When a server process executes SQL or PL/SQL code, the process uses the private SQL area to store bind variable values, query execution state information, and query execution work areas. Note: Do not confuse a private SQL area, which is in the UGA, with the shared SQL area, which stores execution plans in the SGA. Multiple private SQL areas in the same or different sessions can point to a single execution plan in the SGA. For example, 20 executions of SELECT * FROM employees in one session and 10 executions of the same query in a different session can share the same plan. The private SQL areas for each execution are not shared and may contain different values and data. A cursor is a name or handle to a specific private SQL area. We can think of a cursor as a pointer on the client side and as a state on the server side. Cursor

A private SQL area is divided into the following areas:

The run-time area This area contains query execution state information. For example, the run-time area tracks the number of rows retrieved so far in a full table scan. Oracle Database creates the run-time area as the first step of an execute request. For DML statements, the run-time area is freed when the SQL statement is closed.

The persistent area This area contains bind variable values. A bind variable value is supplied to a SQL statement at run time when the statement is executed. The persistent area is freed only when the cursor is closed.

The client process is responsible for managing private SQL areas. The allocation and deallocation of private SQL areas depends largely on the application, although the

number of private SQL areas that a client process can allocate is limited by the initialization parameter OPEN_CURSORS. Although most users rely on the automatic cursor handling of database utilities, the Oracle Database programmatic interfaces offer developers more control over cursors. In general, applications should close all open cursors that will not be used again to free the persistent area and to minimize the memory required for application users. SQL Work Areas A work area is a private allocation of PGA memory used for memory-intensive operations. For example, a sort operator uses the sort area to sort a set of rows. Similarly, a hash join operator uses a hash area to build a hash table from its left input, whereas a bitmap merge uses the bitmap merge area to merge data retrieved from scans of multiple bitmap indexes. Session Memory PGA also contains Session Memory if the connection is established using dedicated server, which is used to store session information for example session variables and logon information.

UGA (User Global Area) The UGA is session memory, which is memory allocated for session variables, such as logon information, and other information required by a database session. Essentially, the UGA stores the session state. It is allocated when a user connects to create a session. It is a subset of a PGA if the dedicated server configuration is used. If the MultiThreaded server option is used, UGA is stored in SGA. If large pool memory area is allocated in SGA, it will store each user processs UGA in large pool. Otherwise the UGA is stored in shared SQL area in shared pool. UGA contains user session information and cursor state information (Private SQL Area). Sorts for each user occur first in this area (SQL work areas, created in runtime area of Private SQL Area). If the sort exceeds the value set in SORT_AREA_SIZE, it will be moved to disk in the temporary tablesapce. When using dedicated server configuration, the PGA contains stack space, user session information and cursor state information. i.e. stack space + UGA.

If a session loads a PL/SQL package into memory, then the UGA contains the package state, which is the set of values stored in all the package variables at a specific time. The package state changes when a package subprogram changes the variables. By default, the package variables are unique to and persist for the life of the session. The OLAP page pool is also stored in the UGA. This pool manages OLAP data pages, which are equivalent to data blocks. The page pool is allocated at the start of an OLAP session and released at the end of the session. An OLAP session opens automatically whenever a user queries a dimensional object such as a cube.

The UGA must be available to a database session for the life of the session. For this reason, the UGA cannot be stored in the PGA when using a shared server connection because the PGA is specific to a single process. Therefore, the UGA is stored in the SGA when using shared server connections, enabling any shared server process access to it. When using a dedicated server connection, the UGA is stored in the PGA.

PGA areas can be sized manually by setting parameters like hash_area_size, sort_area_size etc. To allow Oracle to auto tune the PGA areas, set the WORKAREA_SIZE_POLICY parameter to AUTO and the PGA_AGGREGATE_TARGET to the size of memory that can be used for PGA. This feature was introduced in Oracle 9i. Oracle 11g allows users to tune both PGA and SGA areas with a single parameter, called MEMORY_TARGET. Monitor PGA usage statistics: select * from v$pgastat; Determine a good setting for pga_aggregate_target: select * from v$pga_target_advice order by pga_target_for_estimate; Show the maximum PGA usage per process: select max(pga_used_mem), v$process; max(pga_alloc_mem), max(pga_max_mem) from

Software Code Areas Software code areas are portions of memory that store code that is being run or can be run. Oracle Database code is stored in a software area that is typically more exclusive and protected than the location of user programs. Software areas are usually static in size, changing only when software is updated or reinstalled. The required size of these areas varies by operating system. Software areas are read-only and can be installed shared or nonshared. Some database tools and utilities, such as Oracle Forms and SQL*Plus, can be installed shared, but some cannot. When possible, database code is shared so that all users can access it without having multiple copies in memory, resulting in reduced main memory and overall improvement in performance. Multiple instances of a database can use the same database code area with different databases if running on the same computer.