Oracle Memory Structure

DBA-003
 introduction
• Memory management in 11g can be totally
automatic:
– the DBA need do nothing more than specify an
overall memory allocation for both the SGA and
the PGA and let Oracle manage this memory.
 Basic Memory Structures

• The basic memory structures associated with

Oracle Database include:
• System global area (SGA)
• Program global area (PGA)
• User Global Area (UGA)
• Software code areas
 System global area
• The SGA is a group of shared memory
structures, known as SGA components
– 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 
• A PGA is a nonshared 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.
 User Global Area 
• 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
programs.
• When an instance is started, Oracle Database allocates a
memory area and starts background processes. 
• The memory area stores information such as the following:
– Program code
– Information about each connected session, even if it is not
currently active
– Information needed during program execution, for example, the
current state of a query from which rows are being fetched
– Information such as lock data that is shared and communicated
among processes
– Cached data, such as data blocks and redo records, that also exists
on disk
• the SGA will contain three data structures:
– The database buffer cache
– The log buffer
– The shared pool
• It may, optionally, also contain
– A large pool
– A Java pool
– A Streams pool
 The Database Buffer Cache
• The database buffer cache is typically the largest portion of the
SGA.
• It has data that comes from the files on disk.
– Because accessing data from disk is slower than from memory, the
database buffer cache’s sole purpose is to cache the data in memory
for quicker access.
• The database buffer cache can contain data from all types of
objects:
– ✓ Tables
– ✓ Indexes
– ✓ Materialized views
– ✓ System data
• the term buffer refers to database blocks.
• A database block is the minimum amount of storage that
Oracle reads or writes.
– All storage segments that contain data are made up of blocks.
• When you request data from disk, at minimum Oracle
reads one block.
– Even if you request only one row, many rows in the same table
are likely to be retrieved.
• The same goes if you request one column in one row.
Oracle reads the entire block, which most likely has many
rows, and all columns for that row.
• Oracle’s work area for executing SQL.
• User’s session don’t directly update the data
on disk.
– Data blocks need to be changed first copied to
buffer cache
– Change are applied to copied data blocks into the
buffer cache
– Query data also goes via buffer cache
 The Database Buffer Cache
• Blocks Data files are formatted into fixed-sized
blocks defined by DBA.
– Table rows, and other data objects such as index
keys, are stored in these blocks.
• The database buffer cache is formatted into
memory buffers each sized to hold one block.
• Blocks stores rows of variable lengths
• Row size depends on the number of column and
their design
 The Database Buffer Cache
• consider an end user retrieving an employee record and
updating it, with these statements:
– select last_name, salary, job_id from employees where
employee_id=100;
– update employees set salary=salary * 1.1 where
employee_id=100;
– Commit
• To execute above statements the user’s session will copy
the required blocks from the disk to buffer cache.
• Both data reading and writing will be perform at user’s
memory area
 Example explained
1. The user process will have prompted the user for the employee number
and constructed the SELECT statement.
select last_name, salary, job_id from employees where employee_id=100;
2. The SELECT retrieves some details to be sent to the user process, where
they will be formatted for display.
3. the session’s server process will read the data block containing the relevant
row from a datafile into a buffer.
4. The user process will then initiate a screen dialogue to prompt for some
change to be made and verified; then the UPDATE statement and the COMMIT
statement will be constructed and sent to the server process for execution.
5. Provided that an excessive period of time has not elapsed, the block with
the row will still be available in the cache when the UPDATE statement is
executed.
 The Database Buffer Cache Size
• The buffer cache size must be optimized
• A very large buffer cache may result into a
slow start of instance
• A very small buffer cache may result in a high
disk reads
 Buffer cache state
• The buffer cache controls what blocks get to stay
depending on available space and the block state
• A block in the buffer cache can be in one of three
states:
✓ Free: Not currently being used for anything
✓ Pinned: Currently being accessed
• ✓ Dirty: Block has been modified, but not yet
written to disk
 The Log Buffer
• The log buffer is a small, short-term staging
area for change vectors before they are
written to the redo log on disk.
• A change vector is a modification applied to
something(i.e DML).
The redo log is the database’s guarantee that data will
never be lost: whenever a data block is changed, the
change vectors applied to the block are written out to the
redo log, from where they can be extracted and applied to
datafile backups if it is ever necessary to restore a datafile.
• sessions write redo to the log buffer, in
memory. This is much faster than writing to
disk. The log buffer is then written out to the
redo log files.
• The redo log buffer is flushed when these
things occur:
✓ Every time there’s a commit to data in the
database
✓ Every three seconds
✓ When the redo buffer is 1⁄3 full
✓ Just before each dirty block is written to disk
 Shared pool
• Most complex structure of SGA
• Shard pool components
– The Library Cache
– The data dictionary cache
– The PL/SQL area
– SQL Query and PL/SQL Function result cache
• The shared pool size is dynamic and can be
automatically managed.
 The Library Cache
• The library cache is a memory area for storing
recently executed code, in its parsed form.
• Parsing is the conversion of code written by
programmers into something executable.
• Parsing SQL code takes time
– SELECT * FROM employees where First_name =
‘Mohammad’;

Before this statement can be executed, the Oracle server

has to work out what it means, and how to execute it.
 The Library Cache
• To begin with,
– what is employees? Is it a table, or a view?
– Does it even exist?
– Then the “*”—what are the columns that make up the
employees table
– Does the user have permission to see the table
– After statement understanding the server has to decide out
how best to execute it
• The purpose of the Library Cache of the shared pool is to
store statements in their parsed.
– Ready for execution
 The Dictionary Cache
• Stores recently used object definition in the
cache
• Object definitions are available for all users
from cache to enhance the performance
• It speeds up the parsing process
• The data dictionary cache stores object definitions so that when
statements do have to be parsed, they can be parsed fast—
without having to query the data dictionary.
• Consider these statements are issued consecutively:
– select sum(salary) from employees;
– select * from employees where last_name='KING';
• Both statements must be parsed because they are different
statements—but parsing the first SELECT statement will have
loaded the definition of the employees table and its columns
into the data dictionary cache, so parsing the second statement
will be faster than it would otherwise have been, because no
data dictionary access be needed.
 The PL/SQL Area
• These are functions, procedures and triggers
stored with source code in Data Dictionary
• When a user call for any of these objects, it
must be read from Data Dictionary
• To avoid repeated reading the objects are
placed in PL/SQL area of the shared pool
The SQL Query and PL/SQL Function Result
Cache
• It is a new feature in 11g
• If same query is executed by one session or
many.
• The results of such query is stored in the
Result cache
• Result cache is intelligent enough to track the
changes in the tables as well
• It always give updated results
 Sizing the Shared Pool
• Sizing the shared pool is critical for performance. It
should be large enough to cache all the frequently
executed code and frequently needed object
• Memory in the shared pool is allocated according to an
LRU (least recently used) algorithm. When the Oracle
server needs space in the shared pool, it will overwrite
the object that has not been used for the longest time.
If the object is later needed again, it will have to be
reloaded—possibly overwriting another object.
• The shared pool is allocated at instance startup time.
 The Large Pool
• The large pool is an optional area that, if created, will be
used automatically by various processes that would
otherwise take memory from the shared pool.
• One major use of the large pool is by shared server
processes(multithreaded server). Parallel execution servers
will also use the large pool, if there is one. In the absence
of a large pool, these processes will use memory on the
shared pool.
• This can cause bad contention for the shared pool: if
shared servers or parallel servers are being used, a large
pool should always be created.
 The Java Pool
• The Java pool is only required if your
application is going to run Java-stored
procedures within the database
 The Streams Pool
• The Streams pool is used by Oracle Streams. This is an
advanced tool that is beyond the scope.
• The mechanism used by Streams is to extract change
vectors from the redo log and from these reconstruct
the statements that were executed—or statements
that would have the same effect.
• These statements are executed at the remote
database. The processes that extract changes from
redo and the processes that apply the changes need
memory: this memory is the Streams pool.
 Activity 1
• What memory structures are a required part of
the SGA? (Choose all correct answers.)
– A. The database buffer cache
– B. The Java pool
– C. The large pool
– D. The log buffer
– E. The program global area
– F. The shared pool
– G. The Streams pool
 Activity 2
• Which SGA memory structure(s) cannot be resized
dynamically after instance startup? (Choose all correct
answers.)
– A. The database buffer cache
– B. The Java pool
– C. The large pool
– D. The log buffer
– E. The shared pool
– F. The Streams pool
– G. All SGA structures can be resized dynamically after instance
startup
 Activity 3
• Which SGA memory structure(s) cannot be resized
automatically after instance startup? (Choose all correct
answers.)
– A. The database buffer cache
– B. The Java pool
– C. The large pool
– D. The log buffer
– E. The shared pool
– F. The Streams pool
– G. All SGA structures can be resized automatically after
instance startup
 Activity 4
• When a session changes data, where does the
change get written? (Choose the best answer.)
– A. To the data block in the cache, and the redo log
buffer
– B. To the data block on disk, and the current online
redo log file
– C. The session writes to the database buffer cache,
and the log writer writes to the current online redo
log file
– D. Nothing is written until the change is committed