Pre-Switchover Checks — Never Skip These

Verify the configuration is healthy on both primary and standby before initiating any role change. A switchover that fails midway is more disruptive than the planned maintenance.

Check Database Role and Switchover Readiness

-- Run on primary
SELECT db_unique_name, database_role, switchover_status,
       protection_mode, protection_level
FROM v$database;

switchover_status must be TO STANDBY before you can proceed. If it shows SESSIONS ACTIVE, active sessions are blocking the role change — either wait for them to complete or kill them. If it shows NOT ALLOWED, the standby has not acknowledged the primary's redo transport.

Verify Redo Apply on the Standby

-- Run on standby
SELECT process, status, sequence#, block#, blocks
FROM v$managed_standby
WHERE process LIKE 'MRP%';

MRP should show APPLYING_LOG. If it shows WAIT_FOR_LOG, the standby is waiting for redo that has not arrived — check the transport configuration.

Check for a Sequence Gap

-- On primary: last archived sequence
SELECT MAX(sequence#) last_archived
FROM v$archived_log
WHERE dest_id = 1 AND standby_dest = 'NO';

-- On standby: last applied sequence
SELECT MAX(sequence#) last_applied
FROM v$archived_log
WHERE applied = 'YES';

A gap of 0–2 is normal (in-flight redo). A larger gap means the standby is behind — let it catch up before switching over.

DGMGRL Validation

dgmgrl /
DGMGRL> VALIDATE DATABASE VERBOSE <standby_db_unique_name>;

Look for ERROR or WARNING lines in the output. Any WARNING: Apply lag is X minutes must be resolved before a clean switchover.

DGMGRL Switchover (Preferred Method)

# Connect to DGMGRL on the primary host as oracle OS user
dgmgrl /
DGMGRL> SHOW CONFIGURATION;
-- Verify all databases show SUCCESS or WARNING (not DISABLED or ERROR)

DGMGRL> SWITCHOVER TO <standby_db_unique_name>;
-- Progress messages:
-- Performing switchover NOW, please wait...
-- Operation requires a connection to instance "STANDBY1" on database "STDBY"
-- Switchover processing complete.


DGMGRL> SHOW CONFIGURATION;
-- Former standby should now show "Primary database"
-- Former primary should show "Physical standby database"

After switchover completes, applications need to reconnect to the new primary. If using a SCAN listener or service-based connection, this happens automatically.

SQL Switchover Without Broker

Use this path if you are not using the Data Guard broker (dg_broker_start=FALSE).

-- Step 1: On the PRIMARY — commit to standby role
-- SESSIONS ACTIVE clause lets Oracle drain sessions; WITH SESSION SHUTDOWN
-- forces immediate session termination if needed
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN;
-- Step 2: On the STANDBY — commit to primary role
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

-- Step 3: Open the new primary
ALTER DATABASE OPEN;

-- Step 4: Back on the former primary (now the new standby) —
-- mount it and start redo apply
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Update LOG_ARCHIVE_DEST_n in the new primary's spfile to point at the new standby's TNS alias if needed.

Failover — Primary Is Lost

Failover is a one-way operation: the primary is declared dead and the standby takes over. Do not failover on a network blip. Confirm the primary is genuinely unreachable from at least two independent paths before proceeding.

DGMGRL Failover

DGMGRL> FAILOVER TO <standby_db_unique_name>;

Without IMMEDIATE, DGMGRL tries to flush any unsent redo from the primary first — this minimises data loss but requires the primary to be reachable at the network level.

-- If the primary is completely unreachable (accept potential data loss)
DGMGRL> FAILOVER TO <standby_db_unique_name> IMMEDIATE;

SQL Failover Without Broker

-- On the standby: finish applying all received redo
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

-- Verify MRP has stopped (it will stop automatically after FINISH)
SELECT process, status, sequence# FROM v$managed_standby;


-- Convert to primary
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;


-- Open the new primary
ALTER DATABASE OPEN;

Reinstating the Old Primary as New Standby

If Flashback Database was enabled on the old primary before the failover, you can convert it to a standby rather than rebuilding from scratch.

-- On the new primary: find the SCN at which the standby became primary
SELECT standby_became_primary_scn FROM v$database;
-- On the old primary: start in mount mode
STARTUP MOUNT;

-- Flashback to just before the failover point
FLASHBACK DATABASE TO SCN <standby_became_primary_scn>;


-- Convert to physical standby
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;


-- Restart in mount mode and start redo apply
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

The old primary is now a standby receiving redo from the new primary. Optionally re-add it to the broker configuration with ADD DATABASE.

Common Switchover and Failover Failures

ORA-16467: Switchover Target Is Not Synchronized

ORA-16467: switchover target is not synchronized with the primary database

The standby has an apply lag. Query the lag:

SELECT name, value, unit, time_computed
FROM v$dataguard_stats
WHERE name IN ('apply lag', 'transport lag');

Wait for the apply lag to reach zero, or diagnose why the standby cannot catch up (archive log destination full, MRP crashed, network congestion).

ORA-16472: Flashback Database Required

ORA-16472: feature requires Flashback Database to be enabled

The broker is configured for automatic reinstatement after failover, which requires Flashback Database. Enable it before the next failover:

-- On both databases (in mount mode)
ALTER DATABASE FLASHBACK ON;
ALTER DATABASE OPEN;

Switchover Hangs at SESSIONS ACTIVE

-- Find and kill active sessions blocking the switchover
SELECT sid, serial#, username, status, program, machine
FROM v$session
WHERE status = 'ACTIVE'
  AND username IS NOT NULL
  AND username NOT IN ('SYS','SYSTEM')
ORDER BY last_call_et DESC;

ALTER SYSTEM KILL SESSION '<sid>,<serial#>' IMMEDIATE;

Then retry the switchover. If a high-volume OLTP application is holding sessions open, coordinate with the application team to drain connections to the primary before initiating the role change.