Oracle Database Internals: Understanding SGA, Background Processes, and

Physical vs Logical Structures – Detailed Guide Book ✅

• Introduction to SGA

SGA (System Global Area) is a shared memory region that contains data and control information for a single

Oracle database instance. It is allocated at the time of instance startup and deallocated at shutdown. SGA is

shared by all server and background processes and plays a critical role in improving performance and reducing

disk I/O by caching data and metadata in memory.

• Purpose and Behavior

Key Characteristics:

- Shared across all connected users and background processes

- Stored in RAM to provide fast access to frequently used data

- Tunable (size and behavior can be managed via parameters)

- Controlled by initialization parameters like sga_target, sga_max_size, db_cache_size, etc. SGA can be
allocated automatically using AMM or manually via static memory parameters.

1. Database Buffer Cache

The Database Buffer Cache is a critical memory structure within the SGA that caches copies of data blocks

read from the datafiles. This helps reduce the number of physical I/O operations by storing frequently accessed

data in memory. When a user issues a query, Oracle checks the buffer cache first before accessing disk. It

uses an LRU (Least Recently Used) algorithm to manage buffer aging. Blocks are categorized into

'clean' and 'dirty' blocks - dirty blocks are modified in memory but not yet written to disk. The DBWR
 Oracle Database Internals: Understanding SGA, Background Processes, and
Physical vs Logical Structures – Detailed Guide Book ✅

(Database Writer) process is responsible for writing dirty buffers to disk. You can control its size with the

'DB_CACHE_SIZE' parameter. A larger buffer cache improves performance by increasing the buffer cache

hit ratio. Performance can be monitored using views like V$DB_CACHE_ADVICE and

V$BUFFER_POOL_STATISTICS. Proper tuning is essential in OLTP environments where frequent reads are

common.

2. Shared Pool

The Shared Pool caches a wide variety of programmatic and metadata information. It is divided into two main

components: the Library Cache and the Data Dictionary Cache. The Library Cache stores parsed SQL and

PL/SQL code to avoid reparsing during repeated executions. This enhances performance, especially in systems

with many repetitive queries. The Data Dictionary Cache contains metadata about users, tables, privileges, and

other schema objects. An undersized shared pool can lead to excessive parsing and latch contention. You can

size it using the SHARED_POOL_SIZE parameter. Using bind variables efficiently increases shared pool

efficiency. Monitoring can be done using views such as V$LIBRARYCACHE and V$ROWCACHE. In high-load

environments, shared pool tuning is a key aspect of performance tuning.

3. Redo Log Buffer

The Redo Log Buffer temporarily stores redo entries generated by DML and DDL operations. Redo entries

contain information to reconstruct changes made to the database, ensuring recoverability. These entries are

written to the redo log files by the LGWR (Log Writer) process. Redo entries are flushed when a COMMIT is

issued, when the buffer is one-third full, or every 3 seconds. A very small redo log buffer can cause user commits

to wait, impacting performance. The LOG_BUFFER parameter is used to size it, though typically it's auto-tuned.

Redo logging is essential for database recovery in case of crash or media failure. You can monitor redo activity

using V$LOG and V$LOG_HISTORY. High redo generation could indicate poorly tuned transactions or

excessive DML. Redo size must be considered in Data Guard and GoldenGate environments.
 Oracle Database Internals: Understanding SGA, Background Processes, and
Physical vs Logical Structures – Detailed Guide Book ✅

4. Large Pool

The Large Pool is an optional memory area used for large memory allocations that would otherwise burden the

shared pool. It supports Oracle features like shared server sessions, RMAN (Recovery Manager) operations,

and parallel queries. It is particularly helpful in avoiding fragmentation of the shared pool. This pool is useful for

systems using I/O slaves or session multiplexing. The size can be controlled with the LARGE_POOL_SIZE

parameter. It is not used to cache SQL or PL/SQL like the shared pool. In backup-intensive systems, RMAN

allocations benefit from a properly sized large pool. Shared server mode heavily utilizes this pool to store UGA

(User Global Area). Monitoring can be done using V$SGASTAT and V$LARGE_POOL. If not sized correctly,

RMAN jobs may fail with memory errors or fallback to shared pool usage.

5. Java Pool

The Java Pool is required for executing Java stored procedures and for running Java applications inside the

Oracle JVM. It is not used in environments that do not utilize Java code. This pool holds session-specific Java

code and Java method areas. It is allocated per-session and should be adequately sized if Java is used heavily.

The parameter JAVA_POOL_SIZE is used to manage its size. Improper sizing may lead to 'ORA-04030: out of

process memory' errors during execution of Java code. Its usage is mostly seen in middleware-intensive

systems or web applications using Oracle JVM. You can monitor this pool using V$SGASTAT view. Java code

stored in Oracle Database can use this pool to store objects, methods, and bytecode.

6. Streams Pool

The Streams Pool is used to support Oracle Streams and Advanced Queueing operations. It is required for

operations involving OGG Integrated Replicat and Data Pump Extract. When not explicitly configured, it can

allocate memory from the shared pool, which is not ideal. The parameter STREAMS_POOL_SIZE is used to

manually configure its size. It also supports background capture processes for mining redo logs. Improper

configuration can result in performance bottlenecks for replication Oracle recommends setting this pool

explicitly when using Streams, GoldenGate, or AQ. The Streams Pool is also used in In-Memory Distributed

Transactions. You can monitor its usage using V$SGASTAT and V$STREAMS_POOL_ADVICE. It is not

required in databases not using Oracle Streams or Advanced Queuing.

 Oracle Database Internals: Understanding SGA, Background Processes, and
Physical vs Logical Structures – Detailed Guide Book ✅

Now let’s see what Oracle background processes are.

#2) Background Processes

Oracle has a collection of processes where background processes manage memory, perform disk I/O

operations, and other maintenance activities. These processes are categorized as mandatory and optional

processes.

Below listed are a few of the database required processes, hence mandatory background processes.

Here are 10 essential background processes

1. Process Monitor (PMON)

PMON is responsible for cleaning up failed user processes. It releases resources like locks and memory held

by terminated sessions. PMON also registers the database instance with the listener, ensuring connectivity. It

periodically checks for dead processes and cleans up their remnants. If a process crashes, PMON ensures

recovery. It works alongside SMON for instance recovery. PMON runs automatically and does not require

manual intervention.
 Oracle Database Internals: Understanding SGA, Background Processes, and
Physical vs Logical Structures – Detailed Guide Book ✅

2. System Monitor (SMON)

SMON handles instance recovery after a crash or failure. It cleans up temporary segments that are no longer

needed. SMON also merges free space in tablespaces to optimize storage. If a failed transaction left incomplete

changes, SMON ensures rollback. In Oracle RAC, SMON can recover other instances. It wakes up periodically

to perform housekeeping tasks. SMON is crucial for maintaining database integrity.

3. Database Writer (DBWn)

DBWn writes modified (dirty) buffers from the database buffer cache to datafiles. It ensures that changes

made in memory are safely stored on disk. Multiple DBWn processes can be configured for performance

optimization. It works asynchronously, meaning it does not block user transactions. DBWn is triggered when

the buffer cache fills up or a checkpoint occurs. It improves database efficiency by managing memory usage.

Without DBWn, data changes would not be persisted.

4. Log Writer (LGWR)

LGWR writes redo log entries from the redo log buffer to the online redo log files. It ensures that all committed

transactions are recorded for recovery purposes. LGWR operates synchronously, meaning it writes logs before

confirming a transaction commit. It works closely with DBWn to maintain data consistency. LGWR is crucial for

crash recovery, ensuring no committed data is lost. It writes logs in batches to optimize performance. LGWR

also interacts with archive processes for backup.

5. Checkpoint (CKPT)
CKPT signals DBWn to write dirty buffers to disk and updates control files and datafile headers. It ensures

that changes in memory are safely recorded on disk. CKPT improves database performance by reducing

recovery time after a crash. It works alongside LGWR and DBWn to maintain consistency. CKPT does not write

data itself but coordinates the writing process. Frequent checkpoints help minimize recovery time. It is essential

for maintaining database integrity.

 Oracle Database Internals: Understanding SGA, Background Processes, and
Physical vs Logical Structures – Detailed Guide Book ✅

6. Recoverer (RECO)
RECO resolves distributed transaction failures in Oracle databases. It ensures that transactions across

multiple databases are either fully committed or rolled back. RECO automatically connects to remote databases

to resolve inconsistencies. It works in distributed environments where transactions span multiple systems. If a

network failure occurs, RECO ensures proper recovery. It periodically checks for unresolved transactions and

attempts resolution. RECO is essential for maintaining data consistency in distributed databases.

7. Archiver (ARCn)
ARCn copies redo log files to archive storage for backup and recovery. It ensures that historical transaction

logs are available for point-in-time recovery. Multiple ARCn processes can run simultaneously for performance

optimization. It works in databases running in **ARCHIVELOG mode**, ensuring data safety. ARCn interacts

with LGWR to archive logs efficiently. Archived logs are crucial for disaster recovery and replication. Without

ARCn, long-term recovery would not be possible.

8. Queue Monitor (QMNC)

QMNC manages Oracle Streams and Advanced Queueing (AQ) processes. It ensures efficient message

processing in queue-based applications. QMNC schedules and executes queue-related tasks asynchronously.

It helps in event-driven architectures where messages need to be processed reliably. QMNC interacts with

other background processes to optimize queue performance. It is essential for applications using Oracle AQ

for messaging. Without QMNC, queue-based workflows would be inefficient.

9. Job Scheduler (CJQ0)

CJQ0 manages scheduled jobs in Oracle databases. It ensures that predefined tasks run at specified

intervals. CJQ0 interacts with job queue processes (Jnnn) to execute scheduled jobs. It optimizes resource

usage by running jobs efficiently. CJQ0 is crucial for automating maintenance tasks like backups and statistics

gathering. It periodically checks for new jobs and assigns them to worker processes. Without CJQ0, scheduled

tasks would require manual execution.

 Oracle Database Internals: Understanding SGA, Background Processes, and
Physical vs Logical Structures – Detailed Guide Book ✅

10. Manageability Monitor (MMON)

MMON collects and analyzes database performance metrics. It helps in proactive monitoring and tuning of

database performance. MMON interacts with Automatic Workload Repository (AWR) to store performance

data. It triggers alerts for issues like high CPU usage or slow queries. MMON ensures that diagnostic data is

available for troubleshooting. It works alongside MMNL (Manageability Monitor Lite) for lightweight monitoring.

Without MMON, database administrators would lack critical performance insights.

===================================================================================

Components of Physical And Logical Database Structure of Oracle

Database

Physical structures

The physical layer of Oracle Database consists of files stored on the server’s disk. These include the

following files:

• Control files: Control files are pivotal to the operation of an Oracle database. In particular,

they store metadata about the database, including the names and locations of data files and

redo log files, the database name, and other critical information. Moreover, control files are

indispensable during database startup and recovery.

• Data files: Data files store the actual data within the database. These files are organized into

logical structures called tablespaces, which we’ll discuss later.

• Redo log files: Redo log files capture all changes made to the database, ensuring data

integrity and enabling recovery in the event of a failure.

 Oracle Database Internals: Understanding SGA, Background Processes, and
Physical vs Logical Structures – Detailed Guide Book ✅

Logical structures

The logical architecture of Oracle Database provides an abstraction layer over the physical files.

Here are the key components:

Tablespaces :
Tablespaces logically organize data that are physically stored in datafiles.

• A tablespace belongs to only one database, and has at least one datafile that is used to store

data for the associated tablespace.

• The term “tablespaces” is misleading because a tablespace can store tables, but can also

store many other database objects such as indexes, views, sequences, etc.

• Datafiles are always assigned to only one tablespace and, therefore, to only one database.

• Tablespace is contain one or more segments (table,index etc).

 Oracle Database Internals: Understanding SGA, Background Processes, and
Physical vs Logical Structures – Detailed Guide Book ✅

Segments:

A segment is a set of extents allocated for a specific database object, such as a table. For example,

the data for the employees table is stored in its own data segment, whereas each index for

employees is stored in its own index segment. Every database object that consumes storage

consists of a single segment.A tablespace is a database storage unit that contains one or more

segments.and play a crucial role in managing and organizing data efficiently.

 Oracle Database Internals: Understanding SGA, Background Processes, and
Physical vs Logical Structures – Detailed Guide Book ✅

Extents:

In an Oracle database, an extent is a contiguous group of data blocks used to store information within a

segment, which is a container for database objects like tables and indexes. Segments are composed of one

or more extents, and when a segment's existing space is full, Oracle allocates a new extent.

Data Block:

A data block is the smallest logical unit of data storage in Oracle Database. One logical data block

corresponds to a specific number of bytes of physical disk space, for example, 2 KB. Data blocks are the

smallest units of storage that Oracle Database can use or allocate.

==================================================================================

OVERVIEW

• A database is made up of one or more tablespaces

• A tablespace is made up of one or more data files, a tablespace contains segments

• A segment (table, index, etc) is made up of one or more extents. A segment exists in a

tablespace but may have data in many data files within a tablespace.

• An extent is a continuous set of blocks on a disk. An extent is in a single tablespace and is

always in a single file within that tablespace.

• A block is the smallest unit of allocation in the database. A block is the smallest unit of i/o used

by the database.