Oracle Database Administration Training Series – Day 11

High Availability with Data Guard

Oracle Data Guard is a robust feature to ensure high availability, disaster recovery, and data
protection for Oracle databases. It maintains standby databases that can take over production
operations in the event of planned maintenance, unexpected outages, or disasters.

1. Data Guard Architecture and Components

Primary Database

• The production database that processes user transactions and handles business operations.

Standby Database

• A copy of the primary database that synchronizes with the primary to stay current. Types
include:

o Physical Standby: Maintains a block-for-block replica of the primary database.

o Logical Standby: Uses SQL apply to replicate changes at the SQL level, allowing it to
be open for queries and reporting.

Redo Transport Services

• Transmits redo data from the primary database to the standby database.

Apply Services

• Applies redo data on the standby database to keep it synchronized with the primary:

o Redo Apply: Used in physical standby (via recovery processes).

o SQL Apply: Used in logical standby.

Role Management Services

• Manages transitions between primary and standby roles, supporting switchover and failover.

Data Guard Broker

• A management and monitoring tool that simplifies setup, configuration, and role transitions.

2. Setting Up Physical Standby Database

Prerequisites

1. Primary Database Configuration:

o Archive log mode must be enabled:

ALTER DATABASE ARCHIVELOG;

o Force logging must be enabled:

ALTER DATABASE FORCE LOGGING;

2. Network Configuration:

1
 o Configure Oracle Net Services (TNS) on both primary and standby servers.

o Update tnsnames.ora with connection details for both primary and standby.

3. Disk Space:

o Ensure sufficient storage is available on the standby server for database files.

Steps to Set Up Physical Standby

1. Backup Primary Database:

o Create an RMAN backup of the primary database:

rman target /

BACKUP DATABASE PLUS ARCHIVELOG;

2. Restore Backup on Standby:

o Copy the backup files to the standby server.

o Restore the database:

rman target /
RESTORE CONTROLFILE FROM '/path/to/backup';
RESTORE DATABASE;
RECOVER DATABASE;

3. Set Initialization Parameters:

o Update init.ora or spfile on the standby with:

DB_UNIQUE_NAME='standby_db'
LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary_db,standby_db)'
LOG_ARCHIVE_DEST_1='LOCATION=/path/to/archivelogs'
LOG_ARCHIVE_DEST_2='SERVICE=primary_db'
FAL_SERVER='primary_db'
FAL_CLIENT='standby_db'

o Use the same parameters on the primary to recognize the standby.

4. Start Managed Recovery:

o Start the standby database in recovery mode:

ALTER DATABASE MOUNT STANDBY DATABASE;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT

LOGFILE DISCONNECT FROM SESSION;

5. Verify Configuration:

o Check synchronization status on both primary and standby:

SELECT DATABASE_ROLE, PROTECTION_MODE FROM V$DATABASE;

2
3. Role Transition: Switchover and Failover

Switchover

• A planned role reversal between the primary and standby databases without data loss.

Steps:

1. Verify the primary is ready for switchover:

SELECT SWITCHOVER_STATUS FROM V$DATABASE;

2. Execute switchover on the primary:

ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

3. Execute switchover on the standby:

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

4. Restart both databases in their new roles.

Failover

• An unplanned role transition to the standby database, typically due to a primary database
failure.

Steps:

1. Confirm the standby is ready for failover:

SELECT DATABASE_ROLE, SWITCHOVER_STATUS FROM V$DATABASE;

2. Initiate failover:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

ALTER DATABASE ACTIVATE STANDBY DATABASE;

3. Update application connection strings to point to the new primary.

Real-Time Challenges and Resolutions

Scenario 1: Transport Lag

• Problem: Redo logs are not transmitted promptly from primary to standby.

• Cause: Network latency or insufficient bandwidth.

• Solution: Optimize network settings, enable asynchronous redo transport, and monitor
using:

SELECT DEST_ID, DEST_NAME, GAP_STATUS FROM V$ARCHIVE_GAP;

Scenario 2: Apply Lag

• Problem: Standby is unable to apply redo logs in real time.

• Cause: Insufficient resources on the standby server.

3
 • Solution: Increase memory and CPU resources or enable parallel recovery:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL;

Scenario 3: Switchover Fails

• Problem: Switchover fails due to invalid state or corrupted logs.

• Solution:

o Verify redo logs are applied completely:

SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE APPLIED='YES';

o Resolve gaps in log application.

Benefits of Data Guard for MODI Airlines:

1. High Availability:

o Ensures 24/7 availability of the booking system, even during server maintenance.

2. Disaster Recovery:

o Protects ticket booking data from corruption or loss due to natural disasters.

3. Data Protection:

o Prevents data loss by maintaining synchronized copies of the database.

4. Load Balancing:

o Use standby databases for read-heavy operations like flight searches and reporting.

Best Practices

1. Test Role Transitions Regularly:

o Perform switchover and failover simulations to validate configurations.

2. Monitor Lags:

o Use OEM or custom scripts to continuously monitor redo transport and apply lags.

3. Automate Configuration:

o Use Data Guard Broker for easier setup and monitoring.

4. Regular Backups:

o Complement Data Guard with RMAN backups for added data protection.

By implementing Oracle Data Guard effectively, a MODI airline ticket booking system can achieve
continuous availability, protect customer data, and handle unexpected failures without impacting
operations.

4
Oracle Data Guard provides three protection modes to maintain high availability and data protection
based on business requirements. Each mode offers a trade-off between data protection and
performance, allowing you to choose the most suitable mode for your environment.

1. Maximum Protection Mode

Description:

This mode guarantees zero data loss. The primary database does not commit a transaction until it
confirms that the redo data has been written to at least one standby database.

How it Works:

• The primary database waits for acknowledgment from the standby database(s) before
completing a commit.

• Uses SYNC redo transport mode with AFFIRM.

Configuration:

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;

Use Case:

• Ideal for critical systems like financial institutions, stock exchanges, or airline ticketing
systems, where data loss is unacceptable.

Pros:

• Guarantees zero data loss.

Cons:

• Performance impact on the primary database due to waiting for acknowledgment.

• If no standby database is available, the primary database shuts down to prevent data
inconsistencies.

2. Maximum Availability Mode

Description:

This mode prioritizes zero data loss while providing high availability. Transactions are committed only
after ensuring redo data is written to at least one standby database, but the primary database
remains operational if the standby is temporarily unavailable.

How it Works:

• Works similarly to Maximum Protection, but does not shut down the primary if all standbys
are unavailable.

• Uses SYNC redo transport mode with AFFIRM.

5
 • If the standby is unavailable, transactions are temporarily committed locally until the standby
is reachable.

Configuration:

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

Use Case:

• Suitable for critical systems like airline booking systems, where data loss must be minimized
but availability of the primary system is essential.

Pros:

• Ensures zero data loss as long as at least one standby is accessible.

• High availability: The primary database continues to function even if the standby database is
temporarily down.

Cons:

• Slight performance overhead due to synchronous redo transmission.

3. Maximum Performance Mode

Description:

This mode prioritizes performance over zero data loss. Transactions are committed on the primary
database without waiting for acknowledgment from the standby database.

How it Works:

• Uses ASYNC redo transport mode.

• Redo logs are shipped to the standby database asynchronously, ensuring minimal impact on
primary database performance.

Configuration:

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

Use Case:

• Best suited for systems where performance is critical and some data loss is acceptable, such
as reporting databases or low-priority applications.

Pros:

• Minimal performance impact on the primary database.

• Allows flexibility in network configurations and distances.

Cons:

• Potential for data loss if the primary database fails before the redo data is shipped and
applied to the standby.

6
Comparison Table

Feature Maximum Protection Maximum Availability Maximum Performance

Redo Transmission SYNC + AFFIRM SYNC + AFFIRM ASYNC

None (if standby is

Data Loss None Possible
reachable)

Impact on
High Medium Low
Performance

Shuts down if no
Primary Availability Remains operational Remains operational
standby

Critical systems (no Critical systems (high Performance-prioritized

Use Case
data loss) availability) systems

Scenario: MODI Airline Ticketing System

1. Maximum Protection:

o Use this mode for critical ticket booking operations where no data can be lost, such
as during peak travel seasons or when handling large transaction volumes.

2. Maximum Availability:

o Suitable for balancing ticket booking with high availability, ensuring smooth
operation even if one standby temporarily goes offline.

3. Maximum Performance:

o Useful for analytical reporting or ticketing logs, where minor data loss is acceptable
for maintaining better performance.

Each protection mode should be configured based on the business continuity plan and acceptable
trade-offs between performance and data safety.

Scenarios and Solutions for Oracle Data Guard in a MODI Airline Ticket Booking System

Scenario 1: Redo Transport Lag

Problem:
Redo logs are not transmitted promptly from the primary database to the standby, causing delays in
synchronization.

Cause:

• Network latency between the primary and standby database servers.

• Insufficient bandwidth for transporting redo data.

• Incorrect redo transport configuration.

7
Solution:

1. Check Network Latency:

o Use tools like ping or traceroute to measure latency and identify bottlenecks.

2. Enable Compression:

o Compress redo data during transport:

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) COMPRESSION=ENABLE';

3. Switch to ASYNC Mode:

o If synchronous redo transport (SYNC) causes delays, use asynchronous transport

(ASYNC):

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC';

4. Monitor Gaps:

o Identify and resolve archive gaps:

SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

Scenario 2: Apply Lag on Standby

Problem:
The standby database cannot apply redo logs in real-time, causing data discrepancies.

Cause:

• Insufficient memory or CPU resources on the standby server.

• Disk I/O bottlenecks during redo application.

Solution:

1. Parallel Recovery:

o Increase the number of recovery processes to speed up application:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL;

2. Increase Memory:

o Allocate more memory to the DB_CACHE_SIZE and LOG_BUFFER parameters on the

standby.

3. Optimize Disk I/O:

o Place redo logs on high-performance storage, such as SSDs.

4. Tune Redo Apply:

o Use the RECOVERY_MODE parameter for optimizing redo apply:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE

DISCONNECT FROM SESSION;

8
Scenario 3: Archive Gap

Problem:
The standby database is missing some archived redo logs, resulting in an incomplete recovery.

Cause:

• Network disruption between primary and standby.

• Primary database fails to transmit redo logs.

Solution:

1. Identify Missing Logs:

o Check the archive log gap:

SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

2. Manually Copy Logs:

o Copy missing archive logs from primary to standby:

scp /primary/archivelogs/1_12345.arc standby:/standby/archivelogs/

3. Register Logs on Standby:

o Register the copied logs:

ALTER DATABASE REGISTER LOGFILE '/standby/archivelogs/1_12345.arc';

4. Restart Managed Recovery:

o Restart recovery to apply the logs:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT

LOGFILE DISCONNECT FROM SESSION;

Scenario 4: Switchover Fails

Problem:
A planned switchover from primary to standby fails due to role transition errors.

Cause:

• Primary database has unshipped redo logs.

• Standby is not in a synchronized state.

Solution:

1. Verify Synchronization:

o Ensure no redo logs are pending for transmission:

9
 SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE TARGET='STANDBY';

2. Ship Pending Logs:

o Force a log switch on the primary to ship pending logs:

ALTER SYSTEM SWITCH LOGFILE;

3. Check Switchover Status:

o Verify switchover readiness:

SELECT SWITCHOVER_STATUS FROM V$DATABASE;

4. Retry Switchover:

o Perform switchover commands:

ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

ALTER DATABASE OPEN;

Scenario 5: Failover is Needed

Problem:
The primary database crashes unexpectedly, requiring a failover to the standby database.

Cause:

• Server failure or corruption of the primary database.

Solution:

1. Activate Standby:

o Convert the standby database to primary:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

ALTER DATABASE ACTIVATE STANDBY DATABASE;
2. Point Applications to Standby:

o Update the connection strings in the application to point to the new primary
database.

3. Rebuild the Failed Primary:

o Restore and recover the failed primary database from backups.

o Convert it into a new standby using RMAN:

RMAN> DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE;

Scenario 6: Logical Standby Corruption

Problem:
The logical standby database starts showing data inconsistencies compared to the primary database.

Cause:

• Errors in SQL apply due to unsupported DML or DDL operations.

10
Solution:

1. Verify SQL Errors:

o Check the SQL apply error log for issues:

SELECT * FROM DBA_LOGSTDBY_EVENTS WHERE EVENT_TIME > SYSDATE - 1;

2. Skip Problematic Transactions:

o Skip specific transactions causing errors:

EXEC DBMS_LOGSTDBY.SKIP_TRANSACTION('transaction_id');

3. Re-Synchronize Logical Standby:

o Rebuild the logical standby from the primary database using data export/import:

expdp ... # Export from primary

impdp ... # Import to logical standby

Scenario 7: Data Guard Broker Issue

Problem:
Data Guard Broker fails to monitor or manage the configuration properly.

Cause:

• Misconfigured broker files.

• Incorrect parameters in dg_broker_start.

Solution:

1. Restart Data Guard Broker:

o Restart the broker process:

ALTER SYSTEM SET DG_BROKER_START=FALSE;

ALTER SYSTEM SET DG_BROKER_START=TRUE;
2. Verify Configuration:

o Check the broker configuration:

SHOW CONFIGURATION;

3. Recreate Broker Files:

o Recreate the broker configuration if it is corrupted:

DGMGRL> CREATE CONFIGURATION 'DGuardConfig' AS PRIMARY DATABASE IS

'primary_db' CONNECT IDENTIFIER IS 'primary';

Scenario 8: Standby Database Fails

Problem:
The standby database becomes unavailable due to hardware failure.

Cause:

11
 • Storage or server crash.

Solution:

1. Rebuild Standby:

o Rebuild the standby database using RMAN:

RMAN> DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE;

2. Enable Synchronization:

o Restart redo log shipping from the primary database:

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

These scenarios and solutions illustrate how Oracle Data Guard ensures high availability, disaster
recovery, and efficient operations in a mission-critical system like MODI airline ticket booking.

12