Autonomous Data Guard: local standby for HA and what switchover/failover looks like

#What it is

• A standby database kept in sync with the primary using Oracle Data Guard, managed by OCI.
• Local standby: in another AD (multi-AD regions) or on separate Exadata infrastructure in the same AD (single-AD regions).
• Cross-region standby: in a remote region for DR (see the OCI DR posts). You can have both.

#Enable it

Console → Autonomous Database → Disaster recovery → Add peer database → choose Autonomous Data Guard and the local region.

oci db autonomous-database get --autonomous-database-id <adb-ocid> \
  --query "data.{role:role, localStandby:\"local-standby-db\".\"lifecycle-state\", lagSec:\"local-standby-db\".\"lag-time-in-seconds\"}"

#Failover behaviour (local standby)

• Automatic failover happens if the primary becomes unavailable (OCI monitors it). Typical targets: RTO under a few minutes, RPO near zero (around zero seconds for local standby; check current documentation for exact SLOs).
• After failover, OCI creates a new standby when possible.
• The connection strings stay the same: wallet/TLS connection strings point to the current primary.

#Switchover test

Console → Disaster recovery → Switchover. Primary and standby swap roles without data loss; use it to rehearse and measure application behaviour.

#Application readiness

• Use connection strings with retry settings (RETRY_COUNT, RETRY_DELAY, CONNECT_TIMEOUT) as in the downloaded wallet.
• Enable Transparent Application Continuity on the service for supported drivers:

BEGIN
  DBMS_APP_CONT_ADMIN.ENABLE_TAC('<adb_name>_tp.adb.oraclecloud.com', 'AUTO', 600);
END;
/

• Connection pools with validation, so dead connections are discarded after a role change.

#Cost

The standby is billed (base ECPUs and storage) like an extra database, but it's the simplest way to protect against infrastructure failures beyond what a single Autonomous Database already handles.

#Events to watch

Subscribe to Autonomous Database events (failover, switchover, Data Guard state changes) and alert on standby lag above your RPO.

Note

Data Guard copies everything, including mistakes. Keep backups and use point-in-time clones for logical errors.