8/13/2019 Memory Structure
1/21
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 processand background process. The collection of individualPGAs 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 areasSoftware 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 fromuser programsa more exclusive or protected location.
8/13/2019 Memory Structure
2/21
SGA (System Global Area)
The SGA is a chunk of memory that is allocated by an Oracle Instance (duringthe 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:
8/13/2019 Memory Structure
3/21
1. SGA always resides in system RAM, as per recommendation SGA+PGA size should not bemore 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 instancehas its own SGA.
5. The SGA is read/write. Any change in database is first of all is done into SGA then intodatabase.
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 toplatform. 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.
8/13/2019 Memory Structure
4/21
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>comput e sum of byt es on poolSQL>break on pool ski p 1SQL>set pages 200SQL>set pause on
SQL>sel ect pool , name, byt es f r omv$sgast at order bypool , name;
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 thedatabase.
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.
8/13/2019 Memory Structure
5/21
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 parsetrees 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 validationphase 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
8/13/2019 Memory Structure
6/21
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 thenmodified, but hasnt yet been written to the data files on disk.
Pinned buffers: These are data buffers that are currently in active use byuser sessions.
The buffers in the cache are organized in two lists: the write listand 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 listholds 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.
8/13/2019 Memory Structure
7/21
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 forreuse 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 bufferin 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 listand 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
8/13/2019 Memory Structure
8/21
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 specificschema 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.
8/13/2019 Memory Structure
9/21
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 thevalue 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 yourinitialization 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
8/13/2019 Memory Structure
10/21
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 thebuffer cache.2. Will periodically writes buffer to advance in checkpoint which will be be in-syncbetween 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
8/13/2019 Memory Structure
11/21
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-by-
table 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 orcluster. 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 theactive 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.
8/13/2019 Memory Structure
12/21
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 B uffer
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 protectsrollback 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
8/13/2019 Memory Structure
13/21
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, thenSGA_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.
8/13/2019 Memory Structure
14/21
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_SI ZEas 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 SGA_MAX_SIZE (or memory_max_target)
9.2 128MB
10.2 1GB
11gR1 64GB
11gR2 (and 11gR1 with patch 8813366 applied *) < 1Gb
1Gb - 8Gb
8Gb - 16Gb
16Gb - 32Gb
32Gb - 64Gb64Gb - 128Gb
> 128Gb
PGA (Program global area)
8/13/2019 Memory Structure
15/21
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 isassociated 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 otherinformation required by a database Session
SQL Work areas: Used for sorting, hash operations etc. Which can be required bySQL keyword like DISTINCT, GROUP BY, ORDER BY,UNION,INTERSECT and
MINUS.
Private SQL area: Contains Open/Closed cursors and cursor state information foropen 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
8/13/2019 Memory Structure
16/21
- 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 ofindividual 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
8/13/2019 Memory Structure
17/21
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 usingdedicated 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
8/13/2019 Memory Structure
18/21
A private SQL area holds information about a parsed SQL statement and other session-
specific 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 areaThis 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 areaThis 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
8/13/2019 Memory Structure
19/21
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 thepersistent 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 asession. It is a subset of a PGA if the dedicated server configuration is used. If the Multi-
Threaded 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.
8/13/2019 Memory Structure
20/21
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 automaticallywhenever 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.
8/13/2019 Memory Structure
21/21
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_TARGETto 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), max(pga_alloc_mem), max(pga_max_mem) from
v$process;
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.
Top Related