Finalize the standby database for Data Guard on Google Cloud NetApp Volumes

06/24/2026 Contributors

Finalize the standby database for Oracle Data Guard on Google Cloud NetApp Volumes by creating standby redo log files, enabling flashback database, activating redo shipping, and verifying Data Guard state.

Tier-specific: This procedure is required only for Prod HA (Data Guard + FSFO) tier.

Step 1: Create standby redo log files

Create standby redo log files on both database hosts to support Fast-Start Failover. Size must be greater than or equal to the largest primary online redo log, and count should equal (online groups per thread) + 1. After GCNV seeding, drop and recreate standby redo logs on the standby to fix replicated paths.

Create standby redo log files on the primary database (orcl):

ALTER SYSTEM SET db_create_file_dest='+DATA' SCOPE=BOTH;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 ('+DATA') SIZE 1024M;
-- repeat (online log groups + 1) times

Drop and recreate standby redo log files on the standby database (orcls) after GCNV seeding. Replicated paths under +DATA/ORCL/… cause ORA-19527 / ORA-16086 until rebuilt:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER SYSTEM SET standby_file_management=MANUAL SCOPE=BOTH;
-- DROP STANDBY LOGFILE GROUP for each group# in v$standby_log;
ALTER SYSTEM SET db_create_file_dest='+DATA' SCOPE=BOTH;
ALTER SYSTEM SET standby_file_management=AUTO SCOPE=BOTH;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 ('+DATA') SIZE 1024M;
-- repeat (online groups + 1) times; one member per group
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

Step 2: Enable flashback and start recovery

Enable flashback database on the standby to support automatic reinstatement after failover, then start managed recovery with real-time apply. Flashback must be enabled before starting managed recovery because it cannot be enabled while MRP is active.

Shutdown the standby database, restart in MOUNT mode, and enable flashback database on oracdb2:

# On oracdb2
sudo -u oracle bash -c '
. ~/.bash_profile
export ORACLE_SID=orcls
sqlplus / as sysdba <<SQL
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER SYSTEM SET db_flashback_retention_target=1440 SCOPE=BOTH;
ALTER DATABASE FLASHBACK ON;
EXIT
SQL'

Start managed recovery with real-time apply:

sudo -u oracle bash -c '
. ~/.bash_profile
export ORACLE_SID=orcls
sqlplus / as sysdba <<SQL
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
EXIT
SQL'

USING CURRENT LOGFILE enables real-time apply (redo applied as it lands in SRLs).

Step 3: Enable redo shipping

Enable redo transport from the primary to the standby by activating LOG_ARCHIVE_DEST_STATE_2, which was deliberately set to DEFER in Step 2 of the standby initialization procedure to suppress ORA-12154 errors during standby creation.

Switch LOG_ARCHIVE_DEST_STATE_2 to ENABLE and force a log switch to initiate redo shipping:

sudo -u oracle bash -c '
. ~/.bash_profile
sqlplus / as sysdba <<SQL
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;
ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM ARCHIVE LOG CURRENT;
EXIT
SQL'

Verify redo shipping is working correctly:

sudo -u oracle bash -c '
. ~/.bash_profile
sqlplus / as sysdba <<SQL
SELECT dest_id, status, error FROM v\$archive_dest_status WHERE dest_id IN (1,2);
EXIT
SQL'
# Expected: dest_id=2, STATUS=VALID, ERROR null.

If dest_2 shows ORA-12154, bounce the primary. After Step 1: Enable the broker on both databases, manage transport via DGMGRL.

Step 4: Verify Data Guard state

Verify that the primary database is in READ WRITE mode and the standby database is mounted with managed recovery applying redo logs.

Verify the primary database role and open mode on oracdb1:

sudo -u oracle sqlplus -s / as sysdba \
  <<<"SELECT database_role || ' | ' || open_mode FROM v\$database;"
# Expected: PRIMARY | READ WRITE

Verify the standby database role, open mode, and managed recovery status on oracdb2:

gcloud compute ssh oracdb2 --tunnel-through-iap --zone=us-west1-b

sudo -u oracle bash <<'BASH'
. ~/.bash_profile
export ORACLE_SID=orcls

sqlplus -s / as sysdba <<'SQL'
SELECT database_role || ' | ' || open_mode
FROM v$database;

SELECT process, status, sequence#
FROM v$managed_standby
WHERE process IN ('MRP0','RFS');

EXIT
SQL
BASH

Expected on the standby: PHYSICAL STANDBY | MOUNTED; MRP0 with APPLYING_LOG.

If the standby reports MOUNTED but apply is not running, restart managed recovery on oracdb2:

sudo -u oracle bash -c '
. ~/.bash_profile
export ORACLE_SID=orcls
sqlplus / as sysdba <<SQL
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
EXIT
SQL'

What's next?

To activate automated role management and failover protection, continue with Configure Oracle Data Guard Broker, Fast-Start Failover, and the Observer.