Automatic Memory Management
Oracle Database 11g can routinely manage both the SGA and PGA.
Using this method, the database automatically tunes the sizes
of the individual SGA components and the sizes of the individual PGAs.
New in 11g, Automatic Memory Management (AMM)
enables the Oracle Database to automatically manage the instance
algorithms are used to adjust SGA and PGA memory settings as needs
change. Oracle strongly
recommends using AMM.
parameter has been set, then, in theory, one can forget about it.
AMM is the simplest way to manage memory.
AMM is available for Linux, Solaris, Windows, HP-UX, and AIX.
The main difference between ASMM and AMM is that AMM can manage SGA
and PGA settings. ASMM can only manage the SGA.
During installation, AMM is enabled if the basic install
options are used.
The additional RAC SGA areas are the Global Cache Service
(GCS) and Global Enqueue Service
(GES) and are collections of background processes.
Both of these processes cover and manage the total cache fusion
process, resource transfers, and resource escalations among the
GES and GCS together maintain a Global Resource Directory
(GRD) to record the status of each cached block.
GRD remains in memory and is stored on all the instances. Each
instance manages a portion of the directory. This distributed nature
is a key point for fault tolerance of the RAC.
Global Resource Directory
(GRD) is the internal database that records and stores the status of
the data blocks. Whenever a block is transferred out of a local cache
to another instance's cache, the GRD is updated. The following
resource information is available in the GRD:
Data Block Identifiers (DBA)
Location of most current version
Modes of the data blocks: (N) Null, (S) Shared, (X) Exclusive
The roles of the data blocks (local or global) held by each
Buffer caches on multiple nodes in the cluster
The GRD keeps track of the inventory of resources and their status and
The Background Processes
This next section covers the processes.
Background processes are spawned to execute the database
processing. The following
is a description of each of the background processes:
- System Monitor process performs recovery after instance failure
and monitors temporary segments and extents. SMON can also perform
instance recovery for other failed RAC instances.
- Process Monitor recovers failed user process resources.
PMON performs cleanup of user process resources such as
- Database Writer or Dirty Buffer Writer are responsible for
writing dirty buffers from the database block cache to the
database data files. Generally, DBWR only writes blocks back to
the data files on commit, or when the cache is full and space has
to be made for more blocks. The DBWR processes in RAC must be
coordinated through the locking and global cache processes to
ensure efficient processing is accomplished.
Oracle 11g allows for a maximum of 20 DBWR processes.
- Log Writer process is responsible for writing the log buffers
out to the redo logs. In RAC, each RAC instance has its own LGWR
process that maintains that instance's thread of redo logs.
Redo log entries are written sequentially.
- (Optional). When
running in ARCHIVELOG mode, the archive process writes filled redo
logs to the archive log location(s).
The archive log files are critical for RAC and non-RAC
- A database checkpoint is a method where the state of a database
is saved. The
checkpoint process writes checkpoint information to control files
and data file headers.
Remember that the checkpoint process is the manager of the
database checkpoint; the actual writing of blocks to disk is done
- Job queue controller process wakes up periodically and checks
the JOB$ table. If a job is due, it spawns Jnnn processes to
handle jobs. A
failure of this process does not cause an instance failure.
- Job processes used by the job queues to process jobs. The CJQ0
process controls it automatically.
Advanced Queuing process for Oracle Streams.
A failure of this process does not cause an instance
- ASM bridge process.
Process used for RDBMS instance to ASM instance
communication such as data file adding or removing.
- Database resource manager process.
Handles resource manager related tasks.
- Diagnosability process responsible for hang detection and
- Diagnosability process that performs diagnostic dumps and
executes global oradebug commands.
- Event monitor coordinator.
A process used for database event management and
- Flashback data archiver process. Archives rows of tracked tables
to flashback data archive.
Inserts are not archived.
- The database communicates with the mapping libraries provided by
storage vendors through an external non-Oracle database process
that is spawned by a background process called FMON. FMON is
responsible for managing the mapping information. When the
initialization parameter is specified for mapping data files to
physical devices on a storage subsystem, the FMON process is
- Maintains disk membership in ASM disk groups
- Konductor of ASM temporary errands.
Complete proxy I/O to ASM metafile when disk goes offline.
- "Marks" ASM allocation units stale during a failed write to disk
that is offline. An
allocation unit is the smallest contiguous disk space in ASM.
- Used for internal database tasks
- This process performs frequent and lightweight manageability
related tasks such as session history capture and metrics
- This process performs various manageability-related background
tasks, for example:
- Issuing alerts whenever a given metric violates its threshold value
- Taking snapshots
- Capturing statistics values for SQL objects which have been recently
- Spawns Oracle processes
- Manages rebalance activity for ASM disk groups
- ASM Rebalance process.
Completes the actual rebalance work.
- Space management coordinator.
Involves proactive space allocation and reclaiming.
Spawns Wnnn processes to do its work.
- Virtual keeper of time
The RAC database has the same processes as that of a single-instance
Oracle database. However, there are additional RAC specific processes.
Those processes will be examined in the next section.