Oracle DB Architecture.

md 2024-02-11

Oracle Database Architecture

Oracle Database Architecture encompasses various components and structures that govern how data is
stored, managed, and accessed within the database environment. It is divided into two main categories:
Instance and Database Structure.

Instance
The Instance represents the set of memory structures and background processes that manage the database's
operation.

System Global Area (SGA)

The SGA is a shared memory region containing data and control information for the instance.

Memory Structures:
Buffer Cache: Stores copies of data blocks read from data files.
Shared Pool: Contains shared SQL and PL/SQL code, including cached data dictionary
information.
Redo Log Buffer: Stores redo entries generated by DML operations before they are written to the
redo log files.
Large Pool: Used for large memory allocations, such as parallel execution buffers and I/O server
processes.
Java Pool: Used for Java-related memory allocations.
Streams Pool: Used for Oracle Streams-related memory allocations.
Fixed SGA: Contains fixed-size structures such as locks and kernel variables.

PGA (Program Global Area)

When a user's session executes a query in Oracle Database, the Program Global Area (PGA) plays a crucial role
in managing memory and resources.

1. Session Initialization:

PGA Allocation: When a user session connects to the database, Oracle allocates PGA memory to
manage session-specific data and operations.
Example: When User A connects to the database and executes a query, Oracle allocates
PGA memory for User A's session.

2. Private SQL Area:

Description: Within the PGA, each user's session has a private SQL area that stores information
related to SQL statement processing.
Example: When User A executes a query, Oracle creates a private SQL area to hold the
parsed representation of the SQL statement, bind variable values, and execution context
for User A's session.

3. Session Memory:

1 / 18
Oracle DB Architecture.md 2024-02-11

Description: PGA allocates memory for session-specific data structures and variables needed for
query execution.
Example: User A's session memory holds session parameters, cursor state, and other
session-specific variables required for processing the query.

4. SQL Work Area:

Description: PGA provides a SQL work area for sorting, hashing, and other operations performed
during query execution.
Example: When sorting or hashing is required for User A's query, PGA dynamically
allocates memory within the SQL work area to perform these operations.

5. Stack Space:

Description: PGA allocates stack space for managing program flow, local variables, and function
calls during query execution.
Example: If User A's query involves PL/SQL functions or procedures, PGA allocates stack
space to manage function calls and local variables.

6. Cursor State:

Description: PGA maintains cursor state information for each open cursor within a session,
including current position and fetch status.
Example: PGA tracks the cursor state for User A's query, ensuring consistency and
integrity during query processing.

Background Processes

Background processes are responsible for managing memory, handling user connections, and performing
various background tasks.

Database Writer (DBWn): Writes modified data blocks from the buffer cache to the data files.
Log Writer (LGWR): Writes redo log entries from the redo log buffer to the redo log files.
Checkpoint (CKPT): Signals when checkpoints should occur to update the data files and control file.
System Monitor (SMON): Performs crash recovery, coalesces free space, and recovers terminated
transactions.
Process Monitor (PMON): Cleans up failed sessions and releases resources held by terminated sessions.
Archiver (ARCn): Archives filled redo log files to disk or tape for backup and recovery purposes.
Recoverer (RECO): Resolves distributed transaction failures.
Dispatcher (Dnnn): Dispatches user connection requests to shared server processes.
Job Queue Processes (Jnnn): Executes jobs scheduled by the Oracle job scheduler.

Database Structure
The Database Structure refers to the physical and logical organization of data within the database.

Datafiles

Datafiles contain the actual data of the database.

Primary Datafiles
2 / 18
Oracle DB Architecture.md 2024-02-11

Temporary Datafiles
Read-Only Datafiles
Control Files (Metadata files)

Redo Log Files

Redo log files record changes made to the database.

Online Redo Log Files

Archived Redo Log Files

Control Files

Control files contain critical information about the database's physical structure.

Primary Control Files

Multiplexed Control Files

Tablespaces

Tablespaces are logical storage units containing segments.

Permanent Tablespaces
Temporary Tablespaces
Undo Tablespaces

Segments

Segments contain data for database objects like tables and indexes.

Data Segments
Undo Segments
Temporary Segments

Extents and Blocks

Extent: A contiguous unit of storage allocated to a segment.

Block: The smallest unit of storage within a datafile, typically 8KB in size.

Initialization Parameter Files

Initialization parameter files define the configuration of the Oracle instance.

SPFILE (Server Parameter File)

PFILE (Parameter File)

Password File

Password files contain encrypted credentials for users with administrative privileges.

Archived Redo Log Files

3 / 18
Oracle DB Architecture.md 2024-02-11

Archived redo log files are copies of redo log files that have been archived to secondary storage for backup
and recovery purposes.

Oracle Database Architecture (Tree Diagram)

│
├── Instance
│ ├── System Global Area (SGA)
│ │ ├── Memory Structures
│ │ │ ├── Buffer Cache
│ │ │ ├── Shared Pool
│ │ │ ├── Redo Log Buffer
│ │ │ ├── Large Pool
│ │ │ ├── Java Pool
│ │ │ ├── Streams Pool
│ │ │ └── Fixed SGA
│ │ └── Background Processes
│ │ ├── Database Writer (DBWn)
│ │ ├── Log Writer (LGWR)
│ │ ├── Checkpoint (CKPT)
│ │ ├── System Monitor (SMON)
│ │ ├── Process Monitor (PMON)
│ │ ├── Archiver (ARCn)
│ │ ├── Recoverer (RECO)
│ │ ├── Dispatcher (Dnnn)
│ │ └── Job Queue Processes (Jnnn)
│ ├── Initialization Parameter Files
│ │ ├── SPFILE (Server Parameter File)
│ │ └── PFILE (Parameter File)
│ ├── Program Global Area (PGA)
│ │ ├── Stack Space
│ │ ├── Session Memory
│ │ └── Private SQL Area
│ │ ├── SQL Work Area
│ │ ├── Cursor State
│ │ └── Runtime Area
│ └── Control Files
│
└── Database Structure
├── Datafiles
│ ├── Primary Datafiles
│ ├── Temporary Datafiles
│ ├── Read-Only Datafiles
│ └── Control Files
├── Redo Log Files
│ ├── Online Redo Log Files
│ └── Archived Redo Log Files
├── Control Files
│ ├── Primary Control Files
│ └── Multiplexed Control Files
├── Tablespaces
│ ├── Permanent Tablespaces

4 / 18
Oracle DB Architecture.md 2024-02-11

│ ├── Temporary Tablespaces

│ └── Undo Tablespaces
├── Segments
│ ├── Data Segments
│ ├── Undo Segments
│ └── Temporary Segments
├── Extents and Blocks
├── Initialization Parameter Files
│ ├── SPFILE (Server Parameter File)
│ └── PFILE (Parameter File)
├── Password File
└── Archived Redo Log Files

Understanding Startup Process in OracleDB

The startup process in Oracle Database involves initializing the necessary components to make the database
available for user connections. Let's break down the startup process step by step, along with examples and
commands:

1. Starting the Listener (Optional)

If the listener is not already running, you may need to start it to enable client connections to the database.

Example (Linux/Unix):

lsnrctl start

2. Starting the Oracle Instance

You can start the Oracle instance using SQL*Plus or SQLcl, connecting as a user with administrative privileges
(e.g., SYSDBA).

Example (SQL*Plus):

CONNECT / AS SYSDBA;
STARTUP;

Explanation:

CONNECT / AS SYSDBA: Connects to the database as a user with SYSDBA privileges. The "/" indicates
that no username or password is provided.
STARTUP: Starts the Oracle instance. By default, it opens the database in read/write mode.

3. Specifying Startup Options

You can specify various startup options when starting the instance, such as starting in restricted mode,
mounting but not opening the database, or starting in upgrade mode.

5 / 18
Oracle DB Architecture.md 2024-02-11

Example (Starting in restricted mode):

STARTUP RESTRICT;

Example (Mounting but not opening the database):

STARTUP MOUNT;

Example (Starting in upgrade mode):

STARTUP UPGRADE;

4. Checking Database Status

After starting the database, you can check its status to ensure it is up and running properly.

Example (Checking database status):

SELECT STATUS FROM V$INSTANCE;

5. Opening the Database (if necessary)

If the database is mounted but not yet open, you can open it to allow user connections.

Example (Opening the database):

ALTER DATABASE OPEN;

6. Confirming Successful Startup

Verify that the database is accessible and functioning as expected by connecting with a regular user account.

Example (Connecting as a regular user):

CONNECT username/password;

This completes the startup process of an Oracle Database, including starting the listener (if necessary), starting
the instance, specifying startup options, checking database status, opening the database (if required), and
confirming a successful startup.

6 / 18
Oracle DB Architecture.md 2024-02-11

Startup Modes in OracleDB

In Oracle Database, there are different startup modes that you can specify when starting the database
instance. Each startup mode serves a specific purpose and allows you to control how the instance is brought
online. Here are the various startup modes:

1. Nomount Mode

Accessed Files: Initialization parameter files

Initialization parameter files (such as the SPFILE or PFILE) are accessed to retrieve configuration settings
needed for starting the instance.
In this mode, the instance is started, but the database is not mounted.
It is typically used when creating a new database or when performing certain maintenance tasks that do
not require the database to be opened.
No database files are accessed in this mode.
Background Processes: Minimal set of background processes required for instance startup.
Typically includes processes like PMON (Process Monitor) and SMON (System Monitor) to
perform basic instance initialization and startup tasks.

Note: NOMOUNT Mode is also known as 'Started' in SQLPlus session.

Example:

STARTUP NOMOUNT;

2. Mount Mode

Accessed Files: Control Files

Control files are read and used to locate the datafiles and redo log file.
In this mode, the instance is started, and the database is mounted, but not opened.
Control files are read and used to locate the datafiles and redo log files, but the database is not
accessible to users.
This mode is useful for performing tasks that require the database to be mounted, such as database
recovery or backup operations.
Background Processes: Additional background processes may be activated compared to NOMOUNT
mode.
In addition to the basic processes, other background processes such as DBWn (Database Writer)
and LGWR (Log Writer) may be activated to perform tasks related to instance startup and
mounting the database.

Example:

STARTUP MOUNT;

3. Open Mode

7 / 18
Oracle DB Architecture.md 2024-02-11

Accessed Files: Control Files, Data Files, Redo Log Files

In this mode, the instance is started, and the database is fully opened and accessible to users.
All database files, including datafiles and redo log files, are accessed and available for read and write
operations.
This is the default startup mode if no other mode is specified.
Background Processes: All background processes required for normal database operation.
In this mode, all standard background processes such as DBWn, LGWR, PMON, SMON, CKPT
(Checkpoint), and others are activated to support user connections and database operations.

Example:

STARTUP;

4. Restricted Mode

Accessed Files: Control Files, Data Files, Redo Log Files

In this mode, the instance is started, and the database is opened with restricted access.
Only users with the RESTRICTED SESSION privilege can connect to the database.
It is useful for performing maintenance tasks or troubleshooting without allowing regular user access.
Background Processes: Similar to Open Mode, but with restricted user access.
All standard background processes are activated, ensuring normal database operation. However,
only users with the RESTRICTED SESSION privilege can connect to the database.

Example:

STARTUP RESTRICT;

5. Upgrade Mode

Accessed Files: Control Files, Data Files, Redo Log Files

This mode is used during database upgrade operations.
It starts the instance in a special mode that allows database upgrade scripts to be run.
It disables some features and checks to facilitate the upgrade process or scripts.
Background Processes: Similar to Open Mode, but with special restrictions for upgrade tasks.
All standard background processes required for database operation are activated. Additionally,
specific upgrade-related processes or checks may be initiated to facilitate the upgrade process.

Example:

STARTUP UPGRADE;

6. Force Mode

Accessed Files: Control Files, Data Files, Redo Log Files

8 / 18
Oracle DB Architecture.md 2024-02-11

This mode is used to override certain startup restrictions or errors.

It is typically used in emergency situations where normal startup operations fail.
Be cautious when using this mode, as it may bypass critical checks and validations.
Background Processes: Similar to Open Mode, but may include additional recovery-related processes
in case of startup errors.
All standard background processes are activated, and additional recovery-related processes may
be triggered to handle startup errors or inconsistencies in the database environment.

Example:

STARTUP FORCE;

Understanding the various startup modes in Oracle Database allows you to choose the appropriate mode for
different scenarios, such as database creation, maintenance tasks, recovery operations, or upgrade
procedures. Each mode provides specific functionalities and controls to ensure the instance is started and
managed according to your requirements.

Login Process in Oracle Database

The login process in Oracle Database involves the following steps:

1. Client Request:

The client application sends a connection request to the Oracle Database server.

2. Listener Processing:

Oracle Net Listener routes the connection request to the appropriate database instance.
Server Processes: Upon receiving the connection request, the listener starts necessary server
processes to handle the incoming connection. These processes include Database Writer (DBWn),
Log Writer (LGWR), Process Monitor (PMON), and others, which are essential for database
operation.

3. Authentication:

Oracle Database server verifies the provided username and password.

4. User Session Creation:

Upon successful authentication, a user session is created.

Background Processes: Along with the user session, background processes like System Monitor
(SMON), Process Monitor (PMON), and Checkpoint (CKPT) are started to manage and monitor
the session.

5. Authorization:

The server checks the user's privileges and permissions.

6. Execution:

9 / 18
Oracle DB Architecture.md 2024-02-11

The client application can execute SQL queries or transactions using the established session.

7. Session Termination:

When the user logs out or the session ends, resources are released.

Example
SQL*Plus Login Process

sqlplus username/password@service_name

Example: sqlplus hannibal/tiger@orcl

The client application SQL*Plus sends a connection request to the database server.
Oracle Net Listener routes the request to the orcl database instance.
Oracle Database server verifies the provided username and password.
Upon successful authentication, a user session is created for the user hannibal.
hannibal can now execute SQL queries or transactions using the established session.

Understanding this login process, including the role of server processes and background processes, helps in
troubleshooting connection issues and enforcing security policies within the Oracle Database environment.

Login Process in Oracle Database

│
├── Client Request
│ └── Listener Processing
│ ├── Oracle Net Listener
│ │ ├── Routes connection request
│ │ └── Starts server processes
│ └── Authentication
│ └── User Session Creation
│ └── Authorization
│ └── Execution
│ └── Session Termination

In this diagram version:

The "Listener Processing" node includes the Oracle Net Listener's role in routing the connection request
and starting server processes.
The details of individual server processes have been omitted for brevity.
The diagram retains the sequential flow of the login process, from client request to session termination.

Connection Modes in Oracle Database: Dedicated vs.

Shared

10 / 18
Oracle DB Architecture.md 2024-02-11

In Oracle Database, two primary connection modes dictate how client applications connect to the database:
Dedicated and Shared. Each mode offers distinct characteristics and is suited for different scenarios.

1. Dedicated Connection Mode

Description: In Dedicated mode, each client connection has its dedicated server process on the
database server, ensuring exclusive resources for each connection.

Characteristics:

Provides dedicated server processes for each client connection.

Ensures isolation and resource allocation for individual connections.
Ideal for applications with predictable workloads and low to moderate connection requirements.

Resource Allocation:

Dedicated resources ensure consistent and reliable performance for each connection.
Guaranteed memory and CPU allocation for individual connections.

User Waiting:

Minimal contention for server resources, leading to faster response times.

Users do not need to wait for resources to become available.

Usage:

Recommended for applications where each user requires consistent and dedicated access to
database resources.
Commonly used in OLTP (Online Transaction Processing) environments with a relatively low
number of concurrent connections.

2. Shared Connection Mode

Description: In Shared mode, multiple client connections share a pool of server processes on the
database server, enabling efficient resource utilization.

Characteristics:

Server processes are shared among multiple client connections.

Offers better scalability and resource utilization compared to Dedicated mode.
Suitable for applications with varying workloads and high connection requirements.

Resource Allocation:

Shared resources enable efficient utilization of server resources, accommodating a larger number
of connections.
Resources are allocated dynamically based on demand, optimizing resource usage.

User Waiting:

Increased potential for contention as multiple connections compete for shared resources.
Users may experience longer wait times during peak usage periods.

11 / 18
Oracle DB Architecture.md 2024-02-11

Usage:

Recommended for applications with a large number of concurrent users or fluctuating workloads.
Commonly used in data warehouse environments, web applications, and systems with high user
concurrency.

Example for Dedicated Connection Mode

Connecting as a Database Administrator in Dedicated Mode:

CONNECT sys/password@hostname:port/service_name AS SYSDBA;

CONNECT sysadmin/mypassword@localhost:1521/orcl AS SYSDBA;

In this example, a database administrator connects to the Oracle Database in Dedicated mode using
SYSDBA privileges. The dedicated connection ensures exclusive access to system resources for
administrative tasks.

Example for Shared Connection Mode

Connecting as a Regular User in Shared Mode:

CONNECT username/password@hostname:port/service_name;

CONNECT hannibal/tiger@localhost:1521/orcl;

Here, a regular user named 'hannibal' connects to the Oracle Database in Shared mode. In Shared
mode, multiple users share server resources, allowing efficient resource utilization and scalability.

Database Access in Oracle Database

When a user logs into an Oracle Database, the database access depends on the database startup state and
the user's connection mode. Here's a brief overview:

1. Fresh Database Startup

Access Points:

Initialization parameter files

Control files
Redo log files
Datafiles

12 / 18
Oracle DB Architecture.md 2024-02-11

Example:

During startup, the database instance reads initialization parameter files to configure memory
allocation and other settings.
Control files are accessed to determine the database's state and structure.
Redo log files are accessed for instance recovery and applying changes to the database.
Datafiles are verified for integrity and consistency.

2. Database Already Running

Access Points:

Dedicated or Shared Connection

Example:

In dedicated connection mode, the user connects to a dedicated server process, providing
exclusive access to database resources.
In shared connection mode, users share server processes, and access to databases depends on
session settings, roles, and permissions.

Database Access Algorithms in Oracle: FIFO and LRU

Oracle Database employs First-In-First-Out (FIFO) and Least Recently Used (LRU) replacement policies to
manage data access efficiently. These algorithms are crucial for optimizing performance and resource
utilization in memory caching. Let's dive deeper with examples to provide insights into how FIFO and LRU
work:

1. FIFO (First-In-First-Out)
Description: FIFO is a cache replacement policy where the oldest cached data is evicted first when the
cache is full. This means that the data that has been in the cache the longest is replaced when new data
needs to be cached.

Usage: FIFO ensures that data is replaced in the order it was originally cached, regardless of how
frequently or infrequently it has been accessed since then. This policy is suitable for scenarios where
access patterns are relatively stable over time.

Example

Suppose we have a buffer cache in Oracle Database with a capacity of 100 pages. When a new page needs to
be cached and the cache is already full, the FIFO algorithm will evict the page that was cached earliest,
regardless of how often it has been accessed since then.

If pages A, B, C, ..., X, Y, and Z are currently cached in that order (with A being the oldest and Z being the
newest), and a new page W needs to be cached, FIFO will evict page A (the oldest) to make room for page W.

2. LRU (Least Recently Used)

13 / 18
Oracle DB Architecture.md 2024-02-11

Description: LRU is a cache replacement policy where the least recently used data is evicted first when
the cache is full. This means that the data that has been accessed least recently is replaced when new
data needs to be cached.

Usage: LRU ensures that the most recently accessed data remains in the cache, while older or less
frequently accessed data is evicted. This policy is beneficial for systems with dynamic and changing
access patterns.

Example

Consider the same buffer cache scenario with a capacity of 100 pages. If LRU is employed, the page that was
accessed least recently will be evicted when a new page needs to be cached.

Suppose pages A, B, C, ..., X, Y, and Z are currently cached, with A being the least recently accessed and Z
being the most recently accessed. If a new page W needs to be cached, LRU will evict page A (the least
recently accessed) to make room for page W.

FIFO and LRU are essential cache replacement policies used in Oracle Database to manage data access
efficiently. By evicting data based on their age or access frequency, these algorithms optimize memory usage
and improve overall system performance.

Memory Management in Oracle Database

Memory management in Oracle Database is crucial for optimizing performance and resource utilization.
Oracle employs a hierarchical approach to memory management, with various components at the instance
and database levels. Both manual and automatic memory management options are available to meet diverse
workload requirements.

1. Instance Level Memory Management

At the instance level, Oracle manages memory structures shared by all user sessions and processes.

a. SGA (System Global Area)

Description: Shared memory region containing shared data and control information.
Example: The buffer cache in the SGA stores frequently accessed data blocks to reduce disk I/O.
Usage: SGA size is crucial for database performance. It should be appropriately sized based on the
workload and available system resources.

b. PGA (Program Global Area)

Description: Memory region for individual session-specific data and operations.

Example: When User A runs a query, PGA allocates memory for its private SQL area and SQL work area.
Usage: PGA size impacts query execution. Allocating sufficient PGA memory prevents excessive disk I/O
and enhances query performance.

2. Database Level Memory Management

At the database level, Oracle manages memory structures for specific operations and functionalities.

14 / 18
Oracle DB Architecture.md 2024-02-11

a. Buffer Cache

Description: Caches frequently accessed data blocks to reduce disk I/O.

Example: Buffer cache stores recently read data blocks from the employees table.
Usage: Proper sizing of the buffer cache improves query response times by minimizing disk reads.

b. Shared Pool

Description: Stores shared SQL and PL/SQL code, and parsed execution plans.
Example: Shared pool caches the parsed representation of frequently executed SQL statements.
Usage: Adequate sizing of the shared pool reduces parsing overhead and enhances SQL statement
execution.

c. Redo Log Buffer

Description: Temporarily holds redo entries before writing to redo log files.
Example: Redo log buffer stores transaction changes before they're written to the redo log file.
Usage: Sizing the redo log buffer impacts transaction processing and recovery. Proper sizing ensures
efficient redo log write operations.

d. Large Pool

Description: Optional memory component for large allocations and backup operations.
Example: Large pool improves performance for RMAN backup operations.
Usage: Allocating memory to the large pool enhances performance for large data movement
operations and backup processes.

e. Additional Memory Components

Description: Specialized memory components for specific functionalities.

Example: In-Memory Area enhances performance by storing data in memory for faster access.
Usage: Enabling the In-Memory Area accelerates analytical queries and reporting by leveraging in-
memory data storage.

3. Manual and Automatic Memory Management

Oracle offers options for both manual and automatic memory management to meet varying needs.

Manual Memory Management

Description: DBAs manually configure memory sizes based on workload requirements.

Example: DBAs set SGA_TARGET and PGA_AGGREGATE_TARGET in initialization parameter files.
Usage: Manual memory management provides granular control over memory allocation, allowing DBAs
to fine-tune memory settings based on specific workload characteristics.

Automatic Memory Management (AMM)

Description: Oracle dynamically adjusts memory sizes based on workload demands.

Example: Setting MEMORY_TARGET allows Oracle to manage SGA and PGA collectively.

15 / 18
Oracle DB Architecture.md 2024-02-11

Usage: AMM simplifies memory management by automatically adjusting memory allocations based on
workload changes, reducing administrative overhead and optimizing resource utilization.

Effective memory management in Oracle Database is essential for optimizing performance and resource
utilization. By leveraging insights, examples, and usage scenarios, database administrators can make informed
decisions to optimize memory resources and enhance overall system performance under varying workload
conditions.

Multiplexing in Oracle Database

Multiplexing in Oracle Database involves duplicating critical components, such as control files and redo log
files, to enhance data reliability and fault tolerance.

1. Control File Multiplexing

Control files store metadata about the database structure and are essential for database startup. Multiplexing
control files involves maintaining multiple copies across different disk locations to mitigate the risk of data
loss. Consider the following example:

Original Control File

/u01/app/oracle/oradata/control01.ctl

Multiplexed Control Files

/u02/app/oracle/oradata/control02.ctl
/u03/app/oracle/oradata/control03.ctl

Pros of Control File Multiplexing

Redundancy: Provides redundancy and ensures database availability even if one control file becomes
inaccessible or corrupt.
Fault Tolerance: Enhances fault tolerance by safeguarding against single points of failure.
Quick Recovery: Facilitates quick recovery in case of control file corruption or loss.

Cons of Control File Multiplexing

Increased Storage Overhead: Requires additional storage space to maintain multiple copies of control
files.
Management Complexity: Adds complexity to database administration tasks such as backup and
recovery, as multiple control files need to be managed.

2. Redo Log File Multiplexing

Redo log files record changes made to data in the database and are crucial for database recovery and rollback
operations. Multiplexing redo log files involves creating multiple copies to ensure redundancy. Here's an

16 / 18
Oracle DB Architecture.md 2024-02-11

example:

Original Redo Log Group

Group 1:
- `/u01/app/oracle/oradata/redo01.log`
- `/u01/app/oracle/oradata/redo02.log`

Multiplexed Redo Log Groups

Group 1:
/u02/app/oracle/oradata/redo01.log
/u02/app/oracle/oradata/redo02.log
Group 2:
/u03/app/oracle/oradata/redo03.log
/u03/app/oracle/oradata/redo04.log

Pros of Redo Log File Multiplexing

Enhanced Data Protection: Improves data protection by ensuring that changes are safely stored in
multiple redo log files.
Improved Recovery: Facilitates faster recovery in the event of a redo log file failure or corruption.
High Availability: Contributes to high availability by reducing the risk of data loss during database
operations.

Cons of Redo Log File Multiplexing

Increased Storage Overhead: Requires additional storage space to maintain multiple copies of redo
log files.
Performance Impact: May introduce a slight performance overhead due to the need to write changes
to multiple redo log files.

Tree Diagrams of Multiplexing

Control File Multiplexing

Control File Multiplexing

│
└── Original Control File: /u01/app/oracle/oradata/control01.ctl
│
├── Multiplexed Control Files
│ ├── control02.ctl: /u02/app/oracle/oradata
│ └── control03.ctl: /u03/app/oracle/oradata

Redo Log File Multiplexing

17 / 18
Oracle DB Architecture.md 2024-02-11

Redo Log File Multiplexing

│
└── Original Redo Log Group
├── Group 1
│ ├── redo01.log: /u01/app/oracle/oradata
│ └── redo02.log: /u01/app/oracle/oradata
│
├── Multiplexed Redo Log Group 1
│ ├── redo01.log: /u02/app/oracle/oradata
│ └── redo02.log: /u02/app/oracle/oradata
│
└── Multiplexed Redo Log Group 2
├── redo03.log: /u03/app/oracle/oradata
└── redo04.log: /u03/app/oracle/oradata

Multiplexing in Oracle Database involves duplicating critical components such as control files and redo log
files to enhance data reliability and fault tolerance. By maintaining multiple copies across different disk
locations, Oracle ensures continuous operation and data integrity even in the event of hardware failures or
disk corruption.

18 / 18