Oracle 23ai Standby Databases

A standby database is a continuously maintained copy of a primary database that you can activate when the primary becomes unavailable. In Oracle 23ai, standby databases are most commonly implemented with Oracle Data Guard, which ships and applies redo so you can meet disaster recovery and high-availability goals with predictable data loss and recovery time targets.

The key idea is simple: as the primary generates redo, the standby receives it (redo transport), stores it (archived redo and/or standby redo logs), and applies it (redo apply). Because redo must be transmitted and applied, a standby can be slightly behind the primary, but modern configurations using real-time transport and real-time apply can drive lag extremely low.

• Disaster recovery: Provides a ready-to-activate database at another host/site (on-prem or OCI).
• High availability: Supports planned role transitions (switchover) and unplanned transitions (failover).
• Data protection choices: Lets you choose tradeoffs between performance and potential data loss.
• Operational flexibility: Some configurations allow read-only workload on the standby (Active Data Guard) while redo is applied.

• Physical standby: Block-for-block replica of the primary; applies redo at the block level. This is the most common choice for DR/HA.
• Logical standby: Applies changes as SQL (useful for certain reporting/transformation scenarios, but less common than physical standby).
• Snapshot standby: A physical standby temporarily opened read-write for testing; later it is converted back and resynchronized by applying the accumulated redo (after discarding local changes).

Data Guard protection modes formalize your “speed vs. safety” tradeoff. The names vary by documentation and configuration detail, but the practical model is:

• Maximum protection: prioritizes zero data loss; can halt primary processing if redo cannot be safely shipped.
• Maximum availability: targets zero data loss, but does not permanently stop the primary if the standby is unreachable (it will fall back).
• Maximum performance: favors primary performance by shipping redo asynchronously; accepts some potential data loss during failures.

• Switchover: planned transition with no data loss; the primary becomes standby and a standby becomes primary.
• Failover: unplanned transition after a failure; you activate a standby as the new primary.
• Fast-start failover: optional automation that can trigger failover when health conditions indicate the primary is down.

In practice, most teams manage these transitions with Data Guard Broker (rather than hand-editing parameters), because Broker centralizes configuration state, validation, and orchestration.

1. Redo transport: how redo is sent to the standby (SYNC/ASYNC; optional compression/encryption; one or more destinations).
2. Standby redo logs (SRLs): enable real-time apply by receiving redo similarly to online redo on the primary.
3. Redo apply: how the standby applies changes (managed recovery, real-time apply).
4. Monitoring: track apply/transport lag, gaps, and destination status via dynamic performance views and Broker.

Quick checks from SQL*Plus:

-- Current logging mode (ARCHIVELOG is required for classic redo shipping)
SELECT log_mode FROM v$database;

-- Destination health and errors (examples; columns vary by view)
SELECT dest_id, status, error FROM v$archive_dest_status;

-- High-level lag metrics (when Data Guard is configured)
SELECT name, value, unit FROM v$dataguard_stats
WHERE name IN ('transport lag','apply lag','apply finish time');

Broker-oriented management (DGMGRL):

-- Typical Broker session
DGMGRL> connect /
DGMGRL> show configuration;
DGMGRL> show database verbose <standby_db_unique_name>;

-- Planned role transition
DGMGRL> switchover to <standby_db_unique_name>;

-- Unplanned (manual) activation
DGMGRL> failover to <standby_db_unique_name>;

In hardened environments, Data Guard administration is commonly performed using dedicated administrative privileges (for example, connecting as SYSDG for Data Guard operations), and secure authentication (password files / wallet-based approaches, depending on deployment).

In Oracle Cloud Infrastructure, standby databases are frequently deployed as part of a broader business continuity design (separate AD/region, explicit network controls, automated backups, and monitored Broker configurations). The mechanics remain the same: redo transport + redo apply, with the “cloud” primarily changing how you provision infrastructure, automate operations, and observe telemetry.

Oracle 23ai standby databases are best thought of as a redo-driven continuity pipeline: generate redo on the primary, ship it safely, apply it quickly, and practice role transitions so you can switch over with confidence. In the next step of this module, you typically connect standby strategy back to your backup plan (RMAN), retention requirements for archived redo, and operational monitoring so the standby stays “ready.”