Oracle uses memory to store information such as the following:
Program code
Information about a connected session
Information needed during program execution (for example, the current state of a query from which rows are being fetched)
Cached data (for example, data blocks and redo log entries)
The basic memory structures associated with Oracle include:
System Global Area ( SGA ), which is shared by all server and background processes and holds the following:
– Database buffer cache
– Redo log buffer
–
Shared pool
Program Global Areas ( PGA ), which is private to each server and background process; there is one PGA for each process. The PGA holds the following:
– Stack areas
– Data areas

Figure 1 Oracle Memory Structures
A system global area (SGA) is a group of sharedmemory structures that contain data and control information for one Oracle database instance. If multiple users are concurrently connected to the same instance, then the data in the instance’s SGA is shared among the users. Consequently, the SGA is sometimes called the shared global area .
Oracle can allocate memory for SGA up to
SGA_MAX_SIZE
..

The SGA contains the following data structures:
●
Database buffer cache
●
Redo log buffer
●
Shared pool
●
Java pool
●
Large pool (optional)
●
Data dictionary cache
●
Other miscellaneous information
Database Buffer Cache
The database buffer cache is the portion of the SGAthat holds copies of data blocks read from datafiles. All user processes concurrently connected to the instance share access to the database buffer cache.
The buffers in the cache are organized in two lists: the write list and the least recently used (LRU) list. The write list holds dirty buffers , which contain data that has been modified but has not yet been written to disk. The LRU list holds free buffers, pinned buffers, and dirty buffers that have not yet been moved to the write list.
The first time an Oracle user process requires a particular piece of data, it 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. If the process cannot find the data in the cache (a cache miss ). Accessing data through a cache hit is faster than data access through a cache miss.

Redo Log Buffer
The redo log buffer is a circular buffer in the SGA that holds information about changes made to the database. This information is stored in redo entries . Redo entries contain the information necessary to reconstruct, or redo, changes made to the database by
INSERT
,
UPDATE
,
DELETE
,
CREATE
,
ALTER
, or
DROP operations.
Redo entries are used for database recovery, if necessary.
Shared Pool
The shared pool portion of the SGA contains three major areas: library cache, dictionary cache, buffers for parallel execution messages, and control structures.
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.

A program global area (PGA) is a memory region which contains data and control information for a server process. It is a nonshared memory created by Oracle when a server process is started. Access to it is exclusive to that server process and is read and written only by Oracle code acting on behalf of it.
Content:
Private SQL Area
A private SQL area contains data such as bind information and runtimememory structures. Each session that issues a SQL statement has a private SQL area.
SQL Work Areas
For complex queries (for example, decision-support queries), a big portion of the runtime area is dedicated to work areas allocated by memory-intensive operators such as the following:
Sort-based operators (order by, group-by, rollup, window function)
Hash-join
Bitmap merge
Bitmap create
For example, a sort operator uses a work area (sometimes called the sort area) to perform the in-memory sort of a set of rows.
PGA Memory Management for Dedicated Mode
You can automatically and globally manage the size of SQL work areas. The database administrator simply needs to specify the total size dedicated to PGA memory for the Oracle instance by setting the initialization parameter
PGA_
AGGREGATE_TARGET
.

Statistics on allocation and use of work area memory can be viewed in the following dynamic views:
V$SYSSTAT
V$SESSTAT
V$PGASTAT
The following three columns in the
V$PROCESS view report the PGA memory allocated and used by an Oracle process:
PGA_USED_MEM
PGA_ALLOCATED_MEM
PGA_MAX_MEM

Types of Processes
The processes in an Oracle system can be categorized into two major groups:
User processes run the application or Oracle tool code.
Oracle processes run the Oracle server code. They include server processes and background processes.
Server Processes
Oracle creates server processes to handle the requests of user processes connected to the instance.
Server processes (or the server portion of combined user/server processes) created on behalf of each user’s application can perform one or more of the following:
●
Parse and run SQL statements issued through the application
●
Read necessary data blocks from datafiles on disk into the shared database
● buffers of the SGA, if the blocks are not already present in the SGA
Return results in such a way that the application can process the information
Background Processes
To maximize performance and accommodate many users, a multiprocess Oracle system uses some additional Oracle processes called background processes .
An Oracle instance can have many background processes; not all are always present. The background processes in an Oracle instance include the following:
●
DatabaseWriter (DBW0 or DBW n )
●
Log Writer (LGWR)

●
Checkpoint (CKPT)
●
System Monitor (SMON)
●
Process Monitor (PMON)
●
Archiver (ARC n )
●
Recoverer (RECO)
Figure 2 The Background Processes of a Multiple-Process Oracle Instance

Database Writer Process (DBW n )
The database writer process (DBWn) writes the contents of buffers to datafiles. The
DBW n processes are responsible for writing modified (dirty) buffers in the database buffer cache to disk.
When a buffer in the database buffer cache is modified, it is marked dirty . A cold buffer is a buffer that has not been recently used according to the least recently used
(LRU) algorithm. The DBW n process writes cold, dirty buffers to disk so that user processes are able to find cold, clean buffers that can be used to read new blocks into the cache.
DBW n manages the buffer cache so that user processes can always find free buffers.
Log Writer Process (LGWR)
The log writer process (LGWR) is responsible for redo log buffer management—writing the redo log buffer to a redo log file on disk. LGWR writes all redo entries that have been copied into the buffer since the last time it wrote.
The redo log buffer is a circular buffer.
LGWR writes one contiguous portion of the buffer to disk. LGWR writes:
A commit record when a user process commits a transaction
Redo log buffers
– Every three seconds
– When the redo log buffer is one-third full
–
When a DBW n process writes modified buffers to disk, if necessary
–
View Description
V$LOG
V$LOGFILE
-
Displays the redo log file information from the control file
-
Identifies redo log groups and members and member status
V$LOG_HISTORY -
Contains log history information

Checkpoint Process (CKPT)
When a checkpoint occurs, Oracle must update the headers of all datafiles to record the details of the checkpoint. This is done by the CKPT process.
System Monitor Process (SMON)
The system monitor process (SMON) performs recovery , if necessary, at instance startup. SMON is also responsible for cleaning up temporary segments that are no longer in use and for coalescing contiguous free extents within dictionary managed tablespaces. If any terminated transactions were skipped during instance recovery because of file-read or offline errors, SMON recovers them when the tablespace or file is brought back online. SMON checks regularly to see whether it is needed.
Other processes can call SMON if they detect a need for it.
Process Monitor Process (PMON)
The process monitor (PMON) performs process recovery when a user process fails .
PMON is responsible for cleaning up the database buffer cache and freeing resources that the user process was using.
Recoverer Process (RECO)
The recoverer process (RECO) is a background process used with the distributed database configuration that automatically resolves failures involving distributed transactions.
Archiver Processes (ARC n )
The archiver process (ARCn) copies online redo log files to a designated storage device after a log switch has occurred. ARC n processes are present only when the database is in
ARCHIVELOG mode, and automatic archiving is enabled.

Running a Database in ARCHIVELOG Mode
When you run a database in
ARCHIVELOG mode, you specify the archiving of the online redo log. The database control file indicates that a group of filled online redo log files cannot be used by LGWR until the group is archived. A filled group is immediately available for archiving after a redo log switch occurs.
A database backup, together with online and archived redo log files, guarantees that you can recover all committed transactions in the event of an operating system or disk failure.
Figure 3 Online Redo Log File Use in ARCHIVELOG Mode

Trace Files and the Alert Log
Each server and background process can write to an associated trace file . When a process detects an internal error, it dumps information about the error to its trace file.
Each database also has an alert
.
log
. The alert file of a database is a chronological log of messages and errors.
Table 1 – Process and Session Views

Dedicated Server Configuration
Figure 4 illustrates Oracle running on two computers using the dedicated server architecture. In this configuration, a user process runs the database application on one machine, and a server process runs the associated Oracle server on another machine.
Figure 4 Oracle Using Dedicated Server Processes

Shared server architecture eliminates the need for a dedicated server process for each connection. A dispatcher directs multiple incoming network session requests to a pool of shared server processes. An idle shared server process from a shared pool of server processes picks up a request from a common queue, which means a small number of shared servers can perform the same amount of processing as many dedicated servers.
Figure 5 The Shared Server Configuration and Shared Server Processes

A number of different processes are needed in a shared server system:
A network listener process that connects the user processes to dispatchers or dedicated servers (the listener process is part of Oracle Net Services, not
Oracle).
One or more dispatcher processes
One or more shared server processes
Scalability
Oracle’s shared server architecture increases the scalability of applications and the number of clients simultaneously connected to the database. It can enable existing applications to scale up without making any changes to the application itself.
Dispatcher Request and Response Queues
A request from a user is a single program interface call that is part of the user’s SQL statement.When a user makes a call, its dispatcher places the request on the request queue , where it is picked up by the next available shared server process.
The request queue is in the SGA and is common to all dispatcher processes of an instance. The shared server processes check the common request queue for new requests, picking up new requests on a first-in-first-out basis. One shared server process picks up one request in the queue and makes all necessary calls to the database to complete that request.
When the server completes the request, it places the response on the calling dispatcher’s response queue . Each dispatcher has its own response queue in the SGA.
The dispatcher then returns the completed request to the appropriate user process.

Dispatcher Processes (D nnn )
The dispatcher processes support shared server configuration by allowing user processes to share a limited number of server processes.
You can create multiple dispatcher processes for a single database instance. At least one dispatcher must be created for each network protocol used with Oracle.
Shared Server Processes (Snnn)
Each shared server process serves multiple client requests in the shared server configuration. Shared server processes and dedicated server processes provide the same functionality, except shared server processes are not associated with a specific user process. Instead, a shared server process serves any client request in the shared server configuration.
The PGA of a shared server process does not contain user-related data (which needs to be accessible to all shared server processes). The PGA of a shared server process contains only stack space and process-specific variables.
All session-related information is contained in the SGA.
Table 2 Differences in Memory Allocation Between Dedicated and Shared
Servers

i
i