Memory Structure

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.


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:


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.


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.


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


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.


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/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.


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


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


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.


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


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.


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)


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


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


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


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


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.


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.


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.

Memory Structure

Documents

Transcript of Memory Structure