Oracle Database / Advanced: secure and recoverable evolution / Lesson 17

Data Guard, RAC and client continuity

Match availability mechanisms to failure domains and reason about transport lag, apply lag and uncertain client outcomes.

About 5 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish shared-database clustering from standby replication.
Define role-transition and application verification evidence.

Availability begins with a failure model

A second instance does not automatically protect against lost shared storage, operator deletion or a regional disaster. Oracle RAC and Data Guard address different architectural concerns: RAC permits multiple instances to access one database, whereas Data Guard maintains standby databases using transported and applied redo. They can be combined, but neither substitutes for independent recoverable backups. Describe which components can fail together, where copies and keys reside, and how the application locates the current write service. Avoid promising zero downtime from a product name without a tested transition and client behavior contract.

Transport and apply measure different distances

Transport lag concerns redo reaching a standby, while apply lag concerns redo being incorporated into its data state. A standby may possess recent redo but still need time to apply it before the required role transition or reporting point. A timestamp observed once is not a continuing health guarantee, especially if telemetry itself stops refreshing. The synthetic timeline separates primary generation, standby receipt and standby application so each delay is visible. Its sequence numbers are teaching labels, not a statement about a real Data Guard configuration, protection mode or measured recovery point.

text Illustrative technical example; logical results are reasoned, not engine-tested.

primary_generated: sequence 44
standby_received: sequence 44
standby_applied: sequence 41
interpretation: receipt is current in this model; apply still trails

Sequence receipt alone does not prove the standby data state has reached the same point. These labels do not measure elapsed lag.

Switchover and failover have different premises

A switchover is a planned role transition under suitable health conditions; a failover responds to loss or unavailability of the primary and can carry different data-loss and reinstatement consequences. The exact outcome depends on protection mode, transport, available redo and operational conditions. This lesson supplies no promotion command. An approved runbook must establish authority, verify the intended target, fence conflicting writers and preserve the old primary’s status before enabling a new write path. Otherwise two applications can continue sending writes to inconsistent destinations even if each individual database appears locally available.

Read role evidence within its privilege scope

V$DATABASE exposes database role, open mode and protection fields through authorized access. A role of PRIMARY does not by itself establish that the application reaches the correct service or that the other site is fenced. Conversely, a read-only standby can be healthy for its intended role. Read-only access while apply continues is associated with Active Data Guard feature entitlements; do not assume every standby deployment includes it. Cloud offerings may bundle features differently from on-premises editions, so consult the applicable licensing and service documentation for the actual subscription.

sql Illustrative technical example; logical results are reasoned, not engine-tested.

SELECT database_role, open_mode, protection_mode, protection_level
FROM v$database;

Illustrative read-only inspection requiring appropriate authorization. Actual values must be interpreted with transport, apply and service evidence.

A reachable database is not a completed user request

Clients need reviewed service discovery, reconnect behavior and transaction-outcome handling. A pooled connection can remain tied to a failed endpoint until its validation or event handling reacts. A request interrupted near COMMIT may have an unknown outcome even after a new connection succeeds. Preserve request identifiers and reconcile before replaying side effects. Application Continuity and related capabilities have driver, service, workload and entitlement prerequisites; they are not universal automatic retry wrappers. A rehearsal should test synthetic booking uniqueness, external-effect coordination and observed interruption time, with limitations recorded rather than hidden behind a green database dashboard.

Common errors and fixes

A synchronized receipt metric is treated as zero apply lag

Why it happens: Redo transport and data application were conflated.
How to fix it: Inspect both positions, freshness and the selected target state.
Prevent it next time: Alert on stale telemetry as well as lag magnitude.

Applications still write to the old site after transition

Why it happens: Service routing and writer fencing were outside the tested runbook.
How to fix it: Follow the approved incident coordination and verify one authoritative write path.
Prevent it next time: Rehearse client routing and old-primary isolation with database transitions.

Reconnect retries duplicate a booking

Why it happens: The application replayed an uncertain committed request without reconciliation.
How to fix it: Resolve the persisted request identity before resubmission.
Prevent it next time: Test interruption near commit and external notifications explicitly.

Check your understanding

1. Does RAC alone establish disaster recovery for a lost storage system?

Show worked solution

No. Multiple instances can still depend on a shared failure domain. Define storage and site failures, then evaluate independent standby and backup strategies with their own tested recovery paths. Keep edition, options and cloud entitlements part of the architecture review rather than inferring them from installed binaries.

2. Why might a standby that received sequence 44 still need recovery work before a target state is available?