DBAtlas · Database operations atlas

Oracle Data Guard 19c physical standby (with Broker; single instance, Oracle Restart, RAC)

OracleLevel: AdvancedDuration: 2–4 hours (depending on data size)

Builds a physical standby for a running 19c primary database with RMAN DUPLICATE … FROM ACTIVE DATABASE and adds it to the Data Guard Broker. The result is a standby that receives and applies redo in real time, a broker configuration in SUCCESS status and a tested switchover (optionally a failover/reinstate test and Fast-Start Failover + observer). Primary and standby can each be single instance, Oracle Restart or RAC; for day-to-day operation and failures of an existing configuration, use the Data Guard operations guide.

Topology: Primary (single instance / Oracle Restart / RAC 2–8 nodes) + physical standby (single instance / Oracle Restart / RAC) + optional observer

Before you start

  • Oracle Database software of the same version and the same RU as the primary is installed on …all standby nodes…the standby server… (software only; no database), with the same ORACLE_HOME path (…). Same operating system family and endianness.… Grid Infrastructure (…cluster…Oracle Restart…) is installed and running on the standby with the same or a newer RU.…
  • The primary database is Enterprise Edition. Data Guard is included in EE; opening the standby (read only) while apply is running requires an Active Data Guard license.
  • On all servers, the oracle user's profile defines ORACLE_HOME=…, ORACLE_SID and PATH (……1, …2 … on the primary nodes…… on the primary…; the standby profile is written in this guide).… On the side with Grid, the grid user's profile defines ORACLE_HOME=… and ORACLE_SID=+ASM… (+ASM1, +ASM2 … on RAC)…; asmcmd and lsnrctl run with this profile.…
  • All servers resolve each other by name (DNS or /etc/hosts)…; the SCAN names (…………, …………) resolve to 3 addresses in DNS… and …/tcp is open in both directions. Network bandwidth can carry the redo generation rate…; for SYNC, round-trip latency preferably below 1–2 ms….
  • ASM disk groups with the same names as on the primary (…, …) are mounted on the standby and have enough free space.
  • Clusterware/Oracle Restart is healthy on the standby…; all standby nodes are in the cluster (olsnodes)….
  • On the primary, every instance's redo thread is enabled (v$thread ENABLED = PUBLIC) and all threads have the same number and size of online redo groups.
  • The standby has as much disk space as the primary for data files, the FRA (… GB) and archive logs.
  • Clocks are synchronized with NTP/chrony; time zones are identical.
  • The primary has a password file (REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE) and the SYS password is known. The password must not contain @, /, " or spaces (they break RMAN/DGMGRL connect strings).
  • If the primary is not in ARCHIVELOG mode, one restart is required… (all instances go down)…; a maintenance window for this is approved. A current RMAN backup of the primary exists.
  • Oracle Client (Administrator install type, includes dgmgrl and mkstore) or the Database software is installed on the observer server; it can reach primary and standby on …/tcp.

Phases of the guide

  • Pre-check — Check the current state of the primary
  • Primary preparation — Define the FRA (if missing) · Enable ARCHIVELOG mode (if needed) · Enable force logging and Flashback Database · Set the Data Guard parameters · Create the standby redo logs · Verify the password file
  • Oracle Net (tnsnames, static listener) — Add the tnsnames.ora entries (primary…, every node…) · Add the static listener registrations (primary) · Add the static listener registration (primary node …: …) · Open the listener port in the firewall… (all nodes)…
  • Standby server preparation — Extract the directory list on the primary and send it to the standby · Copy the password file to the standby · Copy the password file to the standby (from the Clusterware registration) · Prepare oratab and the environment file (standby) · Prepare oratab and the environment file (standby node …: …) · Create the directories (standby…, every node…) …
  • Creating the standby (RMAN DUPLICATE) and Redo Apply — Create the standby: RMAN DUPLICATE FROM ACTIVE DATABASE · Verify the state of the standby · Create the standby redo logs if missing (standby) · Remove the temporary pfile (standby) · RAC standby: write the cluster parameters to the spfile · RAC standby: move the spfile and the password file to ASM …
  • Data Guard Broker and protection mode — Move the broker configuration files to a shared location (primary RAC) · Start the broker (primary) · Move the broker configuration files to a shared location (standby RAC) · Start the broker (standby) · Create the broker configuration · Set the apply instance (RAC standby) …
  • Switchover test — Switchover test: make the standby the primary · Check the state after the switchover · Switchback: restore the original roles
  • Flashback on the standby — Enable Flashback Database on the standby
  • Failover and reinstate test — Failover test 1/4: simulate a primary crash · Failover test 2/4: fail over to the standby · Failover test 3/4: start the old primary in MOUNT · Failover test 4/4: reinstate the old primary as a standby (REINSTATE) · Restore the original roles after the failover
  • Fast-Start Failover and observer — Write tnsnames.ora (observer) · Create a wallet for the observer · Define the wallet in sqlnet.ora (observer) · Test the connection with the wallet (observer) · Set the Fast-Start Failover properties · Write the observer start script (observer) …
  • Post-installation — Set the archive log deletion policy (primary) · Set the archive log deletion policy (standby) · Write the archive cleanup script (standby…, every node…) · Test the script manually with the cron environment (standby…, every node…) · Define the cron job (standby…, every node…) · Verify the cron file permissions …
Open the step-by-step plan for your environment →