DBA Playbook · Advanced Implementation · Real-Time Project

Oracle 19c Data Guard Setup Cross-Cloud Migration

A complete real-world implementation guide for configuring Oracle Data Guard Physical Standby as part of a cross-cloud database migration. Covers environment preparation, RMAN Active Database Duplication, redo log shipping, Managed Recovery Process, Data Guard Broker configuration, and full validation procedures for Oracle 19c disaster recovery architecture.

Sections

19c

Oracle DB

★★★

Advanced

Real

Project

▶ View Implementation 📋 Environment Overview

Project Context

Environment & Architecture Overview

This implementation establishes Oracle Data Guard Physical Standby for two databases across cloud platforms, providing high availability and disaster recovery with real-time redo log shipping.

☁️

Source Environment

Source Cloud Platform — Primary DB

🎯

Target Environment

Target Cloud Platform — Standby DB

🗄️

Oracle Version

Oracle Database 19c Enterprise

🛡️

DR Type

Physical Standby Database

💽

Storage Type

Non-ASM — Standard Filesystem

🔄

Migration Type

Cross-Cloud Database Migration

📡

RMAN Method

Active Database Duplication

🔁

Recovery Mode

MRP — Managed Recovery Process

📋 Databases Configured

Database 1: PRIMARYDB → STANDBYDB
Database 2: PRIMARYDB2 → STANDBYDB2
Physical Standby with real-time redo log shipping and MRP managed recovery
Data Guard Broker configured for centralized monitoring and management

Implementation Guide

Step-by-Step Configuration

Follow all sections in sequence. Each section maps directly to the original implementation. All commands and configurations are preserved exactly as executed in the production migration.

Phase 1 — Target Environment Preparation

SECTION 2.1

👤

Oracle OS User & Group Configuration

Create the Oracle OS user and all required DBA OS groups on every target server. Oracle Database must run under a dedicated non-root user with specific group memberships — this is a mandatory security requirement from Oracle's installation guidelines. The id oracle command at the end verifies all group assignments are correct.

bash — Target Server

# Create Oracle OS user
useradd oracle
passwd oracle

# Create required DBA groups
groupadd oinstall
groupadd dba
groupadd oper
groupadd backupdba
groupadd dgdba
groupadd kmdba
groupadd racdba

# Assign Oracle user to groups
usermod -g oinstall oracle
usermod -G dba,oper,backupdba,dgdba,kmdba,racdba oracle
id oracle

📌 Key Notes

oinstall is the primary group — set with -g
All other groups are supplementary — set with -G
dgdba is required specifically for Data Guard operations
Run on all target servers in the configuration

SECTION 2.2

🔥

Firewall & SELinux Configuration

Disable the firewall and SELinux on target servers to allow unrestricted Oracle database communication between source and target environments. In production configurations, firewall rules should be added specifically for Oracle ports instead of full disablement — however, for a migration lab this approach eliminates network-related blockers.

bash — Target Server

systemctl stop firewalld
systemctl disable firewalld
sestatus

# Set SELINUX=disabled in /etc/selinux/config
vi /etc/selinux/config

SECTION 2.3

📦

Oracle Pre-Install Package & YUM Repositories

Install the oracle-database-preinstall-19c RPM package. This package automatically configures all required kernel parameters, OS limits, and system settings for Oracle Database — saving significant manual configuration effort. The package is pulled from Oracle's official YUM repository.

bash — Target Server

# Import Oracle GPG key
rpm --import https://yum.oracle.com/RPM-GPG-KEY-oracle-ol7

# Configure Oracle Linux 7 YUM repository
wget https://yum.oracle.com/public-yum-ol7.repo \
  -O /etc/yum.repos.d/public-yum-ol7.repo

yum-config-manager --enable ol7_latest
yum-config-manager --enable ol7_optional_latest
yum clean all && yum makecache

# Install Oracle 19c pre-install package
yum install -y oracle-database-preinstall-19c

📌 Key Notes

The preinstall package sets kernel parameters (shmmax, shmall, semaphores, etc.) automatically
Also configures /etc/security/limits.conf OS limits for the oracle user
Run on all target servers before any Oracle software installation

Phase 2 — Oracle Directory Structure & Software Installation

SECTION 3

📁

Oracle Directory Structure

Create the required directory tree for Oracle Home, software staging, and database files. The /u01 mount point holds Oracle software and database files, while /u02 is used for archive logs. Correct ownership and permissions are critical — Oracle installer will fail if these are incorrect.

bash — Target Server

# Oracle Home and software staging
mkdir -p /u01/app/oracle/product/19.0.0.0/dbhome_1
mkdir /u01/software
chmod 775 -R /u01
chown oracle:oinstall /u01 -R

# Secondary disk for archive logs
chown oracle:oinstall /u02 -R
chmod 775 /u02/ -R

📌 Key Notes

ORACLE_BASE = /u01/app/oracle
ORACLE_HOME = /u01/app/oracle/product/19.0.0.0/dbhome_1
/u02 — separate disk/mount point for archive logs — keeps archive logs off the main OS disk
Owner must be oracle:oinstall — not root

SECTION 4

⚙️

Oracle 19c Software Installation

Transfer Oracle 19c software binaries from the source server to all target servers using SCP, then unzip and run the installer. The binary transfer via SCP is the recommended approach for cross-cloud migrations where both environments have network connectivity — it avoids re-downloading from Oracle and ensures identical software versions.

bash — 4.1 Transfer Binaries from Source to Target

# Transfer Oracle 19c binaries to target servers
scp -v /u01/app/oracle/product/19.0.0.0/LINUX.X64_193000_db_home.zip \
  oracle@<target-server-ip-1>:/u01/software

bash — 4.2 Install Oracle Database Software

chmod 775 LINUX.X64_193000_db_home.zip
unzip LINUX.X64_193000_db_home.zip \
  -d /u01/app/oracle/product/19.0.0.0/dbhome_1/

cd /u01/app/oracle/product/19.0.0.0/dbhome_1/
./runInstaller

Phase 3 — System Configuration

SECTION 5.1

🧠

HugePages Configuration

Configure Linux HugePages for optimal Oracle SGA memory management. HugePages pre-allocates large memory pages for Oracle's System Global Area (SGA), eliminating the overhead of standard 4KB page table management and preventing memory from being swapped. The value is calculated based on the total SGA size of all databases running on the server.

bash — Target Server

# Check current HugePages status
grep -i huge /proc/meminfo

# Configure in /etc/sysctl.conf
vm.nr_hugepages = <calculated_value>

# Apply and verify
sudo sysctl -p
grep HugePages /proc/meminfo

reboot

📌 Key Notes

vm.nr_hugepages = Total SGA size (in bytes) ÷ 2,097,152 (2MB page size) + buffer
A reboot is required for HugePages to take effect
After reboot, verify with: grep HugePages /proc/meminfo — HugePages_Free should match configured value
Must account for SGA of all databases on the server, not just one

SECTION 5.2

🌿

Oracle Environment Variables (.bash_profile)

Set Oracle environment variables in the oracle user's .bash_profile on the target server. These variables tell the Oracle binaries where the Oracle Home is, which database instance to connect to, and configure library paths. Without these, Oracle CLI tools like sqlplus, rman, and lsnrctl will not function.

bash — ~/.bash_profile (oracle user)

export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_1
export ORACLE_SID=STANDBYDB
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib
export CLASSPATH=$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib

Phase 4 — Network Configuration

SECTION 6.1

📡

listener.ora — Target Server

Configure the Oracle listener on the target (standby) server. The listener is the network gateway that accepts incoming Oracle Net connections on TCP port 1521. It must be running and correctly configured before the standby database can receive redo data or accept RMAN connections from the primary.

$ORACLE_HOME/network/admin/listener.ora

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = <target-server-hostname>)(PORT = 1521))
    )
  )

bash — Start Listener

lsnrctl start

SECTION 6.2

🔗

tnsnames.ora — Both Servers

Configure TNS entries on both primary and standby servers to allow bidirectional Oracle Net connectivity. Data Guard requires each server to be able to resolve and connect to the other by service name — the primary sends redo to the standby, and the broker communicates in both directions.

$ORACLE_HOME/network/admin/tnsnames.ora — Both Servers

PRIMARYDB =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = <source-server-ip>)(PORT = 1521))
    (CONNECT_DATA = (SERVER = DEDICATED)(SERVICE_NAME = PRIMARYDB))
  )

STANDBYDB =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = <target-server-ip>)(PORT = 1521))
    (CONNECT_DATA = (SERVER = DEDICATED)(SERVICE_NAME = STANDBYDB))
  )

bash — Validate Connectivity from Both Sides

tnsping PRIMARYDB
tnsping STANDBYDB

📌 Key Notes

Both tnsping commands must succeed from both servers before proceeding
TNS connectivity failure is the most common blocker during Data Guard setup
Verify firewall allows TCP 1521 between source and target IPs

Phase 5 — Standby Database Preparation

SECTION 7.1

📂

Directory Structure for Standby Database

Create the complete directory structure that the standby database will use for control files, data files, redo logs, and archive logs on the target server. RMAN Active Duplication will attempt to write to these paths during the duplication process — they must exist and be writable by the oracle user before RMAN is run.

bash — Target Server

mkdir -p /u01/app/oracle/admin/PRIMARYDB/adump
mkdir -p /u01/PRIMARYDB/controlfiles1
mkdir -p /u01/PRIMARYDB/controlfiles2
mkdir -p /u01/PRIMARYDB/datafiles
mkdir -p /u01/PRIMARYDB/redologs1
mkdir -p /u01/PRIMARYDB/redologs2
mkdir -p /u02/archivelogs

SECTION 7.2

📄

Initialization Parameter File (initSTANDBYDB.ora)

Create a minimal initialization parameter file for the standby instance. This file is used only to start the instance in NOMOUNT mode before RMAN duplication begins. RMAN will overwrite the parameter file with the proper SPFILE during duplication. Key parameters establish the Data Guard configuration identifiers and archive log destinations.

$ORACLE_HOME/dbs/initSTANDBYDB.ora

db_name=PRIMARYDB
db_unique_name=STANDBYDB
log_archive_config='DG_CONFIG=(PRIMARYDB,STANDBYDB)'
log_archive_dest_1='LOCATION=/u02/archivelogs VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=STANDBYDB'
log_archive_dest_2='SERVICE=PRIMARYDB ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PRIMARYDB'
fal_server=PRIMARYDB
fal_client=STANDBYDB
standby_file_management=AUTO
control_files='/u01/PRIMARYDB/controlfiles1/control01.ctl','/u01/PRIMARYDB/controlfiles2/control02.ctl'

SECTION 7.3

▶️

Start Standby Instance in NOMOUNT Mode

Start the standby instance in NOMOUNT mode using the parameter file just created. NOMOUNT mode starts the Oracle instance and allocates memory (SGA) without mounting or opening any database. This is the required state for RMAN Active Duplication — the instance must be running but no database files should be mounted yet.

SQL*Plus — Standby Server (ORACLE_SID=STANDBYDB)

sqlplus / as sysdba

startup nomount pfile='/u01/app/oracle/product/19.0.0.0/dbhome_1/dbs/initSTANDBYDB.ora';

SECTION 7.4

🔑

Copy Password File from Primary to Standby

Copy the Oracle password file (orapwPRIMARYDB) from the primary server to the standby server. RMAN uses SYS credentials to connect to both the primary and standby during duplication — both databases must have the same SYS password, enforced via matching password files.

bash — Primary Server

scp -v orapwPRIMARYDB \
  oracle@<target-server-ip>:/u01/app/oracle/product/19.0.0.0/dbhome_1/dbs

Phase 6 — RMAN Active Database Duplication

SECTION 8

🚀

Standby Database Creation — RMAN Active Duplicate

RMAN Active Database Duplication creates the standby database by duplicating the primary database directly over the network — no backup files are required. Oracle streams the data files, control file, and SPFile from the primary directly to the standby in real time. This is the recommended method for cross-cloud migrations with network connectivity between environments.

⚙️ Architecture

Target connection: SYS@PRIMARYDB — the source database being duplicated
Auxiliary connection: SYS@STANDBYDB — the standby instance in NOMOUNT
6 target channels + 6 auxiliary channels for parallel streaming
Run via nohup in background — duplication can take hours for large databases

SECTION 8.1

📜

RMAN Execution Shell Script

Shell script that sets the Oracle environment and invokes RMAN with the duplicate script. The script includes timestamped log file generation for monitoring and audit purposes.

rman_duplicate_STANDBYDB.sh

#!/usr/bin/ksh
# RMAN Active Duplicate Script
# Source: PRIMARYDB (Source Platform) | Target: STANDBYDB (Target Platform)

export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_1
export ORACLE_SID=STANDBYDB
export PATH=$ORACLE_HOME/bin:$PATH

LOG_DIR=/u02/rmanduplicate
BAK_DATE=`date '+%d%b%Y_%H_%M'`
LOG_FILE=${LOG_DIR}/rman_dup_STANDBYDB_${BAK_DATE}.log
RCV_FILE=${LOG_DIR}/rman_duplicate_script.rcv

rman target sys/<db_password>@PRIMARYDB auxiliary sys/<db_password>@STANDBYDB \
  cmdfile=$RCV_FILE \
  log=$LOG_FILE

SECTION 8.2

🔧

RMAN Duplicate Script (rman_duplicate_script.rcv)

The RMAN command script that performs the active duplication. Allocates 6 parallel channels on both target and auxiliary to maximize transfer throughput. The DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE NOFILENAMECHECK command with SPFILE overrides sets all required Data Guard parameters in the new standby SPFILE during duplication.

rman_duplicate_script.rcv

RUN {
  ALLOCATE CHANNEL t1 DEVICE TYPE DISK;
  ALLOCATE CHANNEL t2 DEVICE TYPE DISK;
  ALLOCATE CHANNEL t3 DEVICE TYPE DISK;
  ALLOCATE CHANNEL t4 DEVICE TYPE DISK;
  ALLOCATE CHANNEL t5 DEVICE TYPE DISK;
  ALLOCATE CHANNEL t6 DEVICE TYPE DISK;
  ALLOCATE AUXILIARY CHANNEL c1 DEVICE TYPE DISK;
  ALLOCATE AUXILIARY CHANNEL c2 DEVICE TYPE DISK;
  ALLOCATE AUXILIARY CHANNEL c3 DEVICE TYPE DISK;
  ALLOCATE AUXILIARY CHANNEL c4 DEVICE TYPE DISK;
  ALLOCATE AUXILIARY CHANNEL c5 DEVICE TYPE DISK;
  ALLOCATE AUXILIARY CHANNEL c6 DEVICE TYPE DISK;

  DUPLICATE TARGET DATABASE
    FOR STANDBY
    FROM ACTIVE DATABASE NOFILENAMECHECK
    SPFILE
      SET db_unique_name='STANDBYDB'
      SET db_name='PRIMARYDB'
      SET control_files='/u01/PRIMARYDB/controlfiles1/control01.ctl',
                        '/u01/PRIMARYDB/controlfiles2/control02.ctl'
      SET log_archive_config='DG_CONFIG=(PRIMARYDB,STANDBYDB)'
      SET log_archive_dest_1='LOCATION=/u02/archivelogs VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=STANDBYDB'
      SET log_archive_dest_2='SERVICE=PRIMARYDB ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PRIMARYDB'
      SET fal_server='PRIMARYDB'
      SET fal_client='STANDBYDB'
      SET STANDBY_FILE_MANAGEMENT='AUTO'
      SET audit_file_dest='/u01/app/oracle/admin/PRIMARYDB/adump';

  RELEASE CHANNEL t1;
  RELEASE CHANNEL t2;
  RELEASE CHANNEL t3;
  RELEASE CHANNEL t4;
  RELEASE CHANNEL t5;
  RELEASE CHANNEL t6;
  RELEASE CHANNEL c1;
  RELEASE CHANNEL c2;
  RELEASE CHANNEL c3;
  RELEASE CHANNEL c4;
  RELEASE CHANNEL c5;
  RELEASE CHANNEL c6;
}

SECTION 8.3

📊

Execute Duplicate in Background (nohup) & Monitor

Execute the duplication shell script using nohup so it continues running even if the SSH session disconnects. Monitor progress via the RMAN log file and watch the data files directory grow as files are copied from the primary.

bash — Standby Server

# Run in background (survives SSH disconnects)
nohup ./rman_duplicate_STANDBYDB.sh &

# Monitor RMAN log in real time
tail -100f /u02/rmanduplicate/rman_dup_STANDBYDB_<date>.log

# Monitor datafile copy progress
du -sh /u01/PRIMARYDB/datafiles/

📌 Key Notes

Duplication time depends on database size and network bandwidth — can range from minutes to hours
Watch the RMAN log for FINISHED status or any ORA- errors
du -sh /u01/PRIMARYDB/datafiles/ gives a real-time view of how much data has been copied
Do not kill the nohup process — let it complete fully

Phase 7 — Redo Log Shipping Configuration

SECTION 9

📨

Configure Log Archive Dest on Primary

Enable Data Guard redo log shipping on the primary database by setting log_archive_config and log_archive_dest_3 to ship redo logs to the standby. This is what makes the standby database receive real-time changes from the primary — the foundation of Data Guard continuous protection.

SQL*Plus — Primary Server (ORACLE_SID=PRIMARYDB)

ALTER SYSTEM SET log_archive_config='DG_CONFIG=(PRIMARYDB,STANDBYDB)'
  SCOPE=BOTH SID='*';

ALTER SYSTEM SET log_archive_dest_3='SERVICE=STANDBYDB ASYNC
  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=STANDBYDB'
  SCOPE=BOTH SID='*';

ALTER SYSTEM SET log_archive_dest_state_3=ENABLE SCOPE=BOTH SID='*';

SHOW PARAMETER log_archive_config;

Phase 8 — Standby Redo Log Configuration

SECTION 10

📋

Drop & Recreate Standby Redo Logs

Configure Standby Redo Log (SRL) groups on the standby database. SRLs are the buffer where the standby receives redo data before applying it. They must match the primary redo log size (200M in this implementation) and there should be one more SRL group than the number of online redo log groups on the primary.

SQL*Plus — Standby Server

-- Set to MANUAL before making changes
ALTER SYSTEM SET standby_file_management=MANUAL;

-- Drop existing standby redo log groups
ALTER DATABASE DROP STANDBY LOGFILE GROUP 4;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 5;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 6;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 7;

-- Recreate matching primary redo log size (200M)
ALTER DATABASE ADD STANDBY LOGFILE GROUP 4
  ('/u01/PRIMARYDB/redologs1/srl04_01.log',
   '/u01/PRIMARYDB/redologs2/srl04_02.log') SIZE 200M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 5
  ('/u01/PRIMARYDB/redologs1/srl05_01.log',
   '/u01/PRIMARYDB/redologs2/srl05_02.log') SIZE 200M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 6
  ('/u01/PRIMARYDB/redologs1/srl06_01.log',
   '/u01/PRIMARYDB/redologs2/srl06_02.log') SIZE 200M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 7
  ('/u01/PRIMARYDB/redologs1/srl07_01.log',
   '/u01/PRIMARYDB/redologs2/srl07_02.log') SIZE 200M;

-- Re-enable AUTO after changes
ALTER SYSTEM SET standby_file_management=AUTO;

SELECT * FROM v$logfile;

📌 Key Notes

SRL size must match primary online redo log size (200M in this case)
Multiplexed across two paths (redologs1 and redologs2) for redundancy
Always set standby_file_management=MANUAL before dropping/adding — return to AUTO after
Verify all new SRL groups appear in v$logfile with type STANDBY

Phase 9 — Managed Recovery Process (MRP)

SECTION 11

🔄

Start MRP on Standby Database

Start the Managed Recovery Process (MRP) on the standby database. MRP is the background process that continuously receives redo data shipped from the primary and applies it to the standby, keeping the databases synchronized. The USING CURRENT LOGFILE option enables Real-Time Apply — redo is applied as it arrives in the standby redo logs without waiting for archiving.

SQL*Plus — Standby Server

-- Start real-time redo apply
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
  USING CURRENT LOGFILE DISCONNECT;

-- Verify database role and status
SELECT name, database_role, protection_mode, protection_level,
       open_mode, switchover_status
FROM v$database;

📌 Key Notes

DISCONNECT runs MRP as a background process — SQL*Plus session is freed
Expected database_role: PHYSICAL STANDBY
Expected open_mode: MOUNTED (or READ ONLY if opened for reporting)
Expected switchover_status: NOT ALLOWED (while MRP is running)

Phase 10 — Validation & Health Checks

SECTION 12.1

🔍

Redo Log Sequence Verification

Verify redo log sequence numbers between primary and standby to confirm synchronization. The Difference column should be 0 or very close to 0 for a healthy Data Guard configuration. A persistent gap indicates redo shipping or apply issues that require investigation.

SQL*Plus — Standby Server

SELECT
  ARCH.THREAD#                              AS "Thread",
  ARCH.SEQUENCE#                            AS "Last Sequence Received",
  APPL.SEQUENCE#                            AS "Last Sequence Applied",
  (ARCH.SEQUENCE# - APPL.SEQUENCE#)         AS "Difference"
FROM
  (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG
    WHERE (THREAD#, FIRST_TIME) IN
      (SELECT THREAD#, MAX(FIRST_TIME)
       FROM V$ARCHIVED_LOG GROUP BY THREAD#)) ARCH,
  (SELECT THREAD#, SEQUENCE# FROM V$LOG_HISTORY
    WHERE (THREAD#, FIRST_TIME) IN
      (SELECT THREAD#, MAX(FIRST_TIME)
       FROM V$LOG_HISTORY GROUP BY THREAD#)) APPL
WHERE ARCH.THREAD# = APPL.THREAD#
ORDER BY 1;

SECTION 12.2

🔀

Log Switch Test on Primary

Force a log switch on the primary and verify that the new sequence is received and applied on the standby. This is the most direct validation that the entire redo shipping pipeline is working end-to-end.

SQL*Plus — Primary Server

ALTER SYSTEM SWITCH LOGFILE;

SELECT thread#, MAX(sequence#) AS "Last Standby Seq Generated"
FROM v$archived_log val, v$database vdb
WHERE val.resetlogs_change# = vdb.resetlogs_change#
GROUP BY thread#
ORDER BY thread#;

SECTION 12.3

📈

Transport & Apply Lag Monitoring

Monitor all Data Guard health metrics using Oracle dynamic performance views. These queries should be part of every DBA's ongoing operational runbook for a Data Guard environment.

SQL*Plus — Standby Server

-- Transport and apply lag
SELECT name, value, unit FROM v$dataguard_stats
WHERE name IN ('transport lag','apply lag');

-- MRP process status
SELECT process, status, thread#, sequence#
FROM v$managed_standby;

-- Archive gap check
SELECT * FROM v$archive_gap;

-- Database block corruption check
SELECT * FROM v$database_block_corruption;

-- Datafile status
SELECT file#, name, status FROM v$datafile;

-- Standby redo log groups
SELECT group#, thread#, bytes/1024/1024 MB, status
FROM v$standby_log;

📌 Health Check Targets

transport lag and apply lag — should both show +00 00:00:00 (zero lag)
MRP process = MRP0, status = APPLYING_LOG
v$archive_gap — should return no rows
v$database_block_corruption — should return no rows
All datafiles in v$datafile should have status ONLINE

Phase 11 — Data Guard Broker Configuration

SECTION 13.1

🎛️

Enable Broker on Primary & Standby

Enable the Data Guard Broker on both databases. The Broker provides centralized management, automated switchover/failover, and a single interface (dgmgrl) to manage the entire Data Guard configuration. Setting dg_broker_start=TRUE starts the DMON background process on each instance.

SQL*Plus — Run on BOTH Primary and Standby

SHOW PARAMETER dg_broker_start;
ALTER SYSTEM SET dg_broker_start=TRUE SCOPE=BOTH;
SHOW PARAMETER broker_config_file;

SECTION 13.2

🧹

Clear Archive Dest on Standby Before Broker Setup

Before creating the Broker configuration, clear the manual LOG_ARCHIVE_DEST_2 and LOG_ARCHIVE_DEST_3 settings on the standby. The Broker will manage redo shipping configuration automatically — having both manual and Broker-managed settings conflicts and causes errors.

SQL*Plus — Standby Server ONLY

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='' SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='' SCOPE=BOTH;
SHOW PARAMETER LOG_ARCHIVE_DEST;

SECTION 13.3

🏗️

Create Broker Configuration (On Primary)

Create the Data Guard Broker configuration using dgmgrl. This registers the primary database, adds the standby database, and then enables the complete configuration. Once enabled, the Broker takes over management of redo shipping and monitors both databases continuously.

dgmgrl — Primary Server

dgmgrl / as sysdba

CREATE CONFIGURATION DG_PRIMARYDB
  AS PRIMARY DATABASE IS PRIMARYDB
  CONNECT IDENTIFIER IS PRIMARYDB;

ADD DATABASE STANDBYDB
  AS CONNECT IDENTIFIER IS STANDBYDB
  MAINTAINED AS PHYSICAL;

ENABLE CONFIGURATION;

SHOW CONFIGURATION;

SHOW DATABASE VERBOSE PRIMARYDB;
SHOW DATABASE VERBOSE STANDBYDB;

📌 Key Notes

SHOW CONFIGURATION should display SUCCESS status
Both databases should show SUCCESS in SHOW DATABASE output
If Broker shows WARNING — check the specific warning with SHOW DATABASE VERBOSE
Broker logs are in $ORACLE_BASE/diag/rdbms/ for troubleshooting

SECTION 13.4

✅

Final Verification After Broker Setup

Perform a final end-to-end validation after Broker setup. Force a log switch on the primary and verify the sequence number advances identically on the standby. The sequence difference should be zero, confirming the Broker-managed Data Guard configuration is fully operational.

SQL*Plus — Primary Server

ALTER SYSTEM SWITCH LOGFILE;

SELECT thread#, MAX(sequence#) AS "Last Seq Generated"
FROM v$archived_log val, v$database vdb
WHERE val.resetlogs_change# = vdb.resetlogs_change#
GROUP BY thread#
ORDER BY thread#;

SQL*Plus — Standby Server — Final Sequence Check

SELECT
  ARCH.THREAD#                              AS "Thread",
  ARCH.SEQUENCE#                            AS "Last Sequence Received",
  APPL.SEQUENCE#                            AS "Last Sequence Applied",
  (ARCH.SEQUENCE# - APPL.SEQUENCE#)         AS "Difference"
FROM
  (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG
    WHERE (THREAD#, FIRST_TIME) IN
      (SELECT THREAD#, MAX(FIRST_TIME)
       FROM V$ARCHIVED_LOG GROUP BY THREAD#)) ARCH,
  (SELECT THREAD#, SEQUENCE# FROM V$LOG_HISTORY
    WHERE (THREAD#, FIRST_TIME) IN
      (SELECT THREAD#, MAX(FIRST_TIME)
       FROM V$LOG_HISTORY GROUP BY THREAD#)) APPL
WHERE ARCH.THREAD# = APPL.THREAD#
ORDER BY 1;

Implementation Complete

✅ Final Outcome — Migration & DR Architecture

The cross-cloud Oracle Data Guard configuration was completed successfully across all implementation phases. All validation checks passed with zero transport and apply lag.

✓

Data Guard Physical Standby — Two Databases

Physical standby databases configured for both PRIMARYDB → STANDBYDB and PRIMARYDB2 → STANDBYDB2 on the target cloud platform.

✓

Standby Databases Synchronized

Physical standby databases created on target platform via RMAN Active Duplication and fully synchronized with primary databases on source platform.

✓

Real-Time Redo Log Shipping & MRP Active

Real-time redo log shipping enabled via log_archive_dest_3. MRP running continuously with USING CURRENT LOGFILE for zero-delay real-time apply.

✓

Standby Redo Logs Configured

SRL groups 4–7 configured on standby to match primary redo log size (200M), multiplexed across two paths for redundancy.

✓

Data Guard Broker Operational

Broker configured with DG_PRIMARYDB configuration. Both databases show SUCCESS status. Centralized monitoring and automated failover capability enabled.

✓

Zero Transport & Apply Lag Verified

Transport lag and apply lag verified at +00 00:00:00 post-setup. Sequence difference = 0 confirmed via final log switch validation.

✓

HA & DR Environment Ready

Environment validated and ready to support high availability and disaster recovery operations, including switchover and failover procedures.

✓

Cross-Cloud Migration Completed

Oracle databases successfully migrated from source cloud platform to Oracle 19c on target cloud platform with Data Guard protection active from day one.

📌 Implementation Reference

Document Type: Sample Reference — Based on Real-World Implementation
All technical procedures, commands, and outcomes reflect actual implementation steps
All server identifiers, IPs, and environment-specific values replaced with generic placeholders
Oracle Version: 19c (19.0.0.0) — Storage: Non-ASM Standard Filesystem