Failover drill / planned role transition

A decision tree that identifies the type of role change (planned switchover, emergency failover, or a drill that does not touch production) and gives the correct command sequence and verification steps for each scenario. Goal: be ready to transition with no data loss when planned, with minimal loss in an emergency, and with no downtime at all in a drill.

What do you want to do?

Choose the context of the role change. Are you doing a planned transition while the primary is healthy (maintenance/migration), has the primary really died and an emergency transition is needed, or are you running a drill/readiness validation without touching production?

• Planned switchover (primary is healthy)
• Emergency failover (primary is dead)
• Drill / readiness test (do not touch production)

Planned transition — are you ready first?

The goal of a planned switchover is ZERO data loss. For that, before the transition you must make sure the replica has caught up with the primary (lag ~0) and is healthy. Check the lag with the commands below; if the lag is close to zero, proceed to the transition steps.

SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;   -- DG: SELECT name, value FROM v$dataguard_stats WHERE name LIKE '%lag%';

• Lag is close to zero, ready to transition
• Lag is high, wait for sync first

Planned switchover (controlled transition without data loss)

While the primary and standby are healthy and in sync, swap the roles in a controlled way. Order matters: stop writes, make sure the remaining changes have reached the standby, then hand over the role and redirect the application to the new primary.

Emergency transition — is the primary really dead?

Before forcing a failover, verify that the primary is truly unreachable and assess the split-brain risk. If the primary is actually alive (e.g. a transient network outage), a forced transition leads to two separate writable copies (split-brain). Also compare lag to choose the most up-to-date standby.

-- try to reach the primary: tnsping primary_db; and on the standby: SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;

• Yes, the primary is dead — force the transition
• Not sure / the primary may come back

Emergency failover (primary is dead, transition with risk of data loss)

The primary is unreachable and you cannot wait for it to come back. You need to force-promote the standby; with asynchronous replication some of the last transactions may be lost. Your priority is to restore service, then identify the loss window and safely bring back the old primary.

Drill / readiness test (validate without touching production)

Prove that you are ready for failover without performing a real transition. Verify replica health, that lag is acceptable and that the application can be redirected, without affecting production. Optionally rehearse a real switchover on an isolated copy.