Data Guard Switchover vs Failover: When to Use Which

Published Aug 2026 · 7 min read

It is 3am, the primary is not answering, and you have a standby sitting right there. The decision you make in the next two minutes determines whether tomorrow is a normal day or a week of rebuilding.

Switchover and failover both end with the standby running as primary. Only one of them is reversible without a rebuild, and picking the wrong one under pressure is the mistake that costs the most.

The one-line difference

A switchover is planned and lossless: the two databases co-operate, roles swap cleanly, and both remain part of the configuration. A failover is what you do when the primary is not available to co-operate — the standby is promoted unilaterally, and the old primary is left behind.

The decision is almost always driven by one question: can the primary still ship redo?

If the primary is alive and you have a maintenance window, it is a switchover. If the primary is gone and the business is waiting, it is a failover. The grey zone — primary technically up but unusable — is where judgement is needed, and the tie-breaker is whether it can still ship its remaining redo.

Before you touch anything: the pre-checks

Most switchovers that "hang" were never ready to start. Three checks take under a minute and prevent nearly all of it. First, ask the broker directly:

DGMGRL> SHOW CONFIGURATION;

Configuration - dgprod

  Protection Mode: MaxAvailability
  Members:
  prod_pri - Primary database
    prod_std - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 41 seconds ago)

DGMGRL> VALIDATE DATABASE prod_std;

  Database Role:     Physical standby database
  Primary Database:  prod_pri

  Ready for Switchover:  Yes
  Ready for Failover:    Yes (Primary Running)

  Managed by Clusterware:
    prod_pri: YES
    prod_std: YES

VALIDATE DATABASE is the check worth internalising. "Ready for Switchover: Yes" means the broker has already verified redo transport, apply state and the standby redo logs. If it says No, it also tells you why — fix that instead of forcing the command.

Second, confirm the roles and switchover status from SQL*Plus on both sides:

SQL> SELECT name, database_role, open_mode, switchover_status
  2  FROM   v$database;

NAME      DATABASE_ROLE    OPEN_MODE   SWITCHOVER_STATUS
--------- ---------------- ----------- ------------------
PROD      PRIMARY          READ WRITE  TO STANDBY

TO STANDBY on the primary and TO PRIMARY on the standby is the clean state. SESSIONS ACTIVE is fine — it only means users are connected. RECOVERY NEEDED, RESOLVABLE GAP or UNRESOLVABLE GAP mean stop: redo is missing.

Third, check the lag. A switchover with a large apply lag will sit there applying redo while your window burns:

SQL> SELECT name, value, time_computed
  2  FROM   v$dataguard_stats
  3  WHERE  name IN ('transport lag','apply lag');

NAME            VALUE           TIME_COMPUTED
--------------- --------------- ---------------------
transport lag   +00 00:00:00    05-AUG-2026 02:41:07
apply lag       +00 00:00:02    05-AUG-2026 02:41:07

Performing a switchover

With the broker configured, it is one command, run from either side:

DGMGRL> CONNECT sys@prod_pri;
Password: ********
Connected to "prod_pri"

DGMGRL> SWITCHOVER TO prod_std;
Performing switchover NOW, please wait...
Operation requires a connection to database "prod_std"
Connecting ...
Connected to "prod_std"
New primary database "prod_std" is opening...
Operation requires start up of instance "PROD" on database "prod_pri"
Starting instance "PROD"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "prod_std"

The broker stops the apply, ships the final redo, reverses both roles and restarts what needs restarting. When it returns, the old primary is already a standby.

Without the broker, the same thing in SQL*Plus. From 12.1 onwards the single-statement form is available and is much harder to get wrong:

-- On the current primary
SQL> ALTER DATABASE SWITCHOVER TO prod_std VERIFY;

Database altered.

The VERIFY keyword runs the readiness checks first and fails fast with a clear error rather than leaving you half-switched. On older configurations you may still meet the classic sequence — ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN; on the primary, then ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; on the standby — but if the broker is available, use it.

Afterwards, verify both sides rather than trusting the success message:

DGMGRL> SHOW CONFIGURATION;

  Members:
  prod_std - Primary database
    prod_pri - Physical standby database

Configuration Status:
SUCCESS

Performing a failover

Failover is for when the primary cannot participate. Connect to the standby — the primary may be unreachable — and promote it:

DGMGRL> CONNECT sys@prod_std;
Password: ********
Connected to "prod_std"

DGMGRL> FAILOVER TO prod_std;
Performing failover NOW, please wait...
Failover succeeded, new primary is "prod_std"

Plain FAILOVER is a complete failover: the standby applies all the redo it has already received, then activates. That is what you want by default, because it preserves every transaction that made it across the wire.

FAILOVER TO prod_std IMMEDIATE; skips the remaining apply and activates immediately. It is faster and loses more. Keep it for the case where the apply itself is broken.

Without the broker, the manual equivalent is to finish the available redo and then activate:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
  2  FINISH;

Database altered.

SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;

Database altered.

Once that ACTIVATE runs, the old primary and the new primary have diverged. There is no undo.

Fast-Start Failover, briefly

Fast-Start Failover hands the decision to an observer process, which fails over automatically when the primary is unreachable for longer than FastStartFailoverThreshold. It requires Flashback Database on both databases and a protection mode of Maximum Availability or Maximum Protection. It is genuinely useful, but treat it as a deliberate design decision with a tested observer — not something to enable during an incident.

The part everyone forgets: reinstating the old primary

After a failover, the old primary is not a standby. It is a diverged database sitting outside the configuration. What happens next depends on one setting you had to make before the outage:

SQL> SELECT flashback_on FROM v$database;

FLASHBACK_ON
------------------
YES

If that says YES, the old primary can be rewound past the point of divergence and reinstated as a standby:

-- Start the old primary in MOUNT, then from DGMGRL:
DGMGRL> REINSTATE DATABASE prod_pri;
Reinstating database "prod_pri", please wait...
Reinstatement of database "prod_pri" succeeded

If it says NO, there is no shortcut. The old primary must be rebuilt from backup or with an RMAN DUPLICATE TARGET DATABASE FOR STANDBY. On a large database that is hours or days of your week.

The lesson is not a command, it is a checklist item: enable Flashback Database on both databases while everything is healthy. It costs some flashback log space and buys you the ability to undo a failover.

Common mistakes

• Failing over when a switchover would have worked. If the primary can still ship redo, a switchover keeps it in the configuration and loses nothing. Failover throws that away.
• No Flashback Database. Discovered only after the failover, when reinstate is not an option.
• Ignoring the gap. Any GAP status in SWITCHOVER_STATUS means redo is missing. Resolve it first.
• Forgetting the TNS and service layer. The role changed; applications still point at the old host. Role-based services that start on the primary role, plus a correct tnsnames.ora, are what make the change invisible to users.
• Leaving the observer running during a planned switchover. With Fast-Start Failover enabled, do the maintenance the supported way rather than fighting the observer.
• Never rehearsing. A switchover you have performed in a lab is a fifteen-minute task. A switchover you have only read about becomes an outage.

A drill worth running this quarter

Switch over to the standby, run the application there for a day, then switch back. It validates redo transport, your service definitions, your TNS entries and your own muscle memory — and it is entirely reversible. Teams that do this quarterly are the ones who stay calm at 3am.

The commands are the easy part. The hard part is having already decided which one you are running before the pager goes off. For the full mechanics — building the standby, the broker configuration, protection modes and Fast-Start Failover on real labs — our live Oracle Data Guard training walks through each of these end to end, and the Oracle 19c Data Guard recorded course covers the same ground at your own pace with lifetime access. Oracle's own Data Guard Concepts and Administration guide is the authoritative reference for the syntax variations across releases, and more playbooks like this one are on the DBNexus blog.

Commands verified against Oracle 19c with Data Guard Broker; the broker syntax shown is unchanged in 23ai and 26ai.