Physical Standby Architecture, Redo Transport, Apply, Protection Modes, and Roles

Learning outcomes

ServiceHub runs in one site and the business asks, “If that site disappears, can another database take over with little or no data loss?” A nightly RMAN backup answers media recovery, but not continuous remote currency. Oracle Data Guard answers a different problem: it ships redo from a primary database to one or more standby databases and applies that redo so a standby can assume the primary role after a planned or unplanned event.

1. A physical standby is a block-for-block recovery copy

A physical standby database has the same on-disk database structures as its primary and is kept synchronized by Redo Apply. Primary transactions generate redo exactly as Chapter 14 described. Data Guard transports that redo to the standby. A Remote File Server (RFS) writes incoming redo to a standby redo log (SRL); managed recovery processes such as MRP0 use normal database recovery mechanisms to apply the change vectors to standby datafiles.

This means physical standby currency is recovery-driven rather than SQL-replay-driven. A bad committed application update is valid redo and will normally be transported/applied too. Data Guard is therefore disaster-recovery replication, not protection from every logical mistake and not a replacement for Chapter 15 backups/Chapter 16 Flashback.

2. Current process evidence uses V$DATAGUARD_PROCESS

SELECT  db_unique_name,  database_role,  open_mode,  protection_mode,  protection_level,  switchover_statusFROM v$database;

SELECT  name,  role,  pid,  apply,  stop_stateFROM v$dataguard_processORDER BY name,pid;

V$DATAGUARD_PROCESS is the current process view; Oracle documents it as the replacement for the older V$MANAGED_STANDBY view. Typical names include RFS, MRP0, transport workers, and archiver-related processes.

3. Standby redo logs are the remote durability landing zone

SRLs are structurally similar to online redo logs but receive redo from another database. Current Oracle guidance requires at least as many SRL groups as online redo groups for each redo thread and requires SRLs to be at least as large as the largest source online redo log; Oracle recommends identically sized online/SRL files for operational simplicity.

-- Primary/source:SELECT thread#,group#,bytes,statusFROM v$logORDER BY thread#,group#;-- Standby/destination:SELECT thread#,group#,bytes,status,usedFROM v$standby_logORDER BY thread#,group#;

After a role transition the old primary becomes a redo destination, so production designs create appropriate SRLs on both sides before the transition. In Oracle Real Application Clusters (RAC), every redo thread must be covered.

4. Protection mode controls the transaction/redo contract—not application routing

None of these modes automatically updates DNS, connection pools, application sessions, or external load balancers. Client failover is a separate service/network/application concern.

5. Transport lag and apply lag answer different questions

SELECT  name,  value,  unit,  time_computed,  datum_timeFROM v$dataguard_statsWHERE name IN ('transport lag','apply lag','apply finish time')ORDER BY name;

Transport lag measures how far received redo trails source generation. Apply lag includes both transport delay and unapplied received redo, so it can be larger. An unchanged DATUM_TIME across repeated queries is itself evidence that the standby is not receiving fresh source information. On a primary, V$DATAGUARD_STATS returns no lag rows; that is expected, not proof that lag is zero.

6. Redo gaps are sequence ranges missing from the standby

Transport can recover ordinary gaps automatically using archived redo and Fetch Archive Log (FAL) behavior when configuration/network/archive retention are correct. When a gap blocks apply, diagnose missing sequence coverage rather than restarting MRP repeatedly.

SELECT  thread#,  low_sequence#,  high_sequence#FROM v$archive_gapORDER BY thread#;

SELECT  dest_id,  status,  target,  db_unique_name,  destination,  error,  synchronization_statusFROM v$archive_dest_statusWHERE status <> 'INACTIVE'ORDER BY dest_id;

7. Free design-validation lab: measure the source workload Data Guard would have to carry

Because Redo Apply is not licensed in Free, the mandatory lab measures the source-side facts needed for a real design: current role, ARCHIVELOG state, redo-group geometry and redo generation rate. No standby is created.

ALTER SESSION SET CONTAINER=CDB$ROOT;SELECT  db_unique_name,  database_role,  open_mode,  log_mode,  force_logging,  protection_mode,  protection_levelFROM v$database;SELECT  thread#,  COUNT(*) AS online_groups,  MAX(bytes) AS largest_online_log_bytesFROM v$logGROUP BY thread#ORDER BY thread#;

SELECT  SYSTIMESTAMP AS captured_at,  MAX(CASE WHEN name='redo size' THEN value END) AS redo_bytes,  MAX(CASE WHEN name='user commits' THEN value END) AS user_commitsFROM v$sysstatWHERE name IN ('redo size','user commits');

Subtract two snapshots and divide by elapsed seconds. This produces measured redo bytes/second for the interval. Use that value later for network/standby storage sizing; do not derive production bandwidth from a synthetic Free benchmark.

8. Entitled topology blueprint

ALTER SYSTEM SET LOG_ARCHIVE_CONFIG=  'DG_CONFIG=(servicehub_pri,servicehub_stby)'  SCOPE=BOTH;ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=  'SERVICE=servicehub_stby ASYNC   VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)   DB_UNIQUE_NAME=servicehub_stby'  SCOPE=BOTH;ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO  SCOPE=BOTH;

Actual creation also needs matching database identity/DB_UNIQUE_NAME planning, password authentication, listener/services, files/storage, control-file/SPFILE preparation, backups or RMAN DUPLICATE FOR STANDBY, SRLs, ARCHIVELOG, and compatibility/platform support. Broker can manage transport/apply properties after the databases exist.

9. Deliberately wrong: “Data Guard means we no longer need backups or client failover”

Deleting a table, committing wrong data, or corrupting application logic can be reproduced at the standby. Site failure still requires applications to locate/reconnect to the new primary. A standby also cannot replace long-term retention, point-in-time restore depth, or offline/offsite backup copies.

10. Production judgment

Use physical Data Guard when continuous remote recovery and role transition justify the second-system operational cost. Size SRLs/network/apply capacity from measured redo rate and peak behavior. Keep both sites patched/secured equivalently, preserve archived redo for gap resolution, and monitor transport/apply freshness continuously.

Current 26ai licensing: Data Guard Redo Apply is unavailable in Free/SE2-ODA and available in EE, EE-ES and specified higher cloud offerings. No management pack is required for the dynamic views used here. Lesson 2 moves from the redo mechanism to the Broker control plane that coordinates health and role transitions.

Authoritative references

• Introduction to Oracle Data Guard — physical standby, Redo Apply and protection modes
• Redo Transport Services — SRLs, RFS and transport requirements
• V$DATAGUARD_PROCESS — current Data Guard process evidence
• V$DATAGUARD_STATS — transport/apply lag definitions
• Licensing Information — Data Guard/Active Data Guard offering matrix