Switchover

A switchover is a role reversal between the primary database and one of its standby databases.

A switchover guarantees no data loss and is typically done for planned maintenance of the primary system. During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role.

Whenever possible, you should switch over to a physical standby database:

  • If the switchover transitions a physical standby database to the primary role, then:

    • The original primary database will be switched to a physical standby role.

    • Other members of the configuration will receive redo from the designated redo source based on the new primary.

    • The original primary database will be restarted as a part of the switchover operation. Note that the new primary database does not need to be restarted.

      Standby databases not involved in the switchover (known as bystander standby databases) continue operating in the state they were in before the switchover occurred and will automatically begin applying redo data received from the new primary database.

  • If the switchover transitions a logical standby database to the primary role, then:

    • The original primary database will be switched to a logical standby role.

    • Neither the primary database nor the logical standby database needs to be restarted after the switchover completes.

      Other logical standby bystander databases in the broker configuration will remain viable after the switchover. All physical and snapshot standby databases will be disabled and must be re-created from a copy of the new primary database after a switchover to a logical standby database.

    Switchover to a logical standby database is disallowed when the configuration is operating in maximum protection mode.

    WARNING:

    After a switchover to a logical standby database any snapshot or physical standby databases in the broker configuration are no longer viable as standby databases and will; be disabled by the broker. If the switchover to a logical standby is only for a short time, the disabled snapshot and physical standby databases can be successfully reenabled after switching back to the original primary. Reenabling Disabled Databases After a Role Change describes how to restore their viability as standby databases.

    If the switchover to a logical standby is only for a short time, the disabled snapshot and physical standby databases can be successfully reenabled after switching back to the original primary.

Before Performing a Switchover Operation

These are some points to consider before you begin a switchover.

  • When you start a switchover, the broker verifies that at least one standby database, including the primary database that is about to be transitioned to the standby role, is configured to support the overall protection mode (maximum protection, maximum availability, or maximum performance) after the switchover is completed.

  • Prepare the primary database in advance for its possible future role as a standby database in the context of the overall protection mode (see Managing Data Protection Modes). Such preparation includes:

    • Ensuring that standby redo log files are configured on the primary database.

    • Presetting database properties related to redo transport services, such as LogXptMode, NetTimeout, StandbyArchiveLocation, StandbyAlternateLocation, and RedoRoutes. For more details about managing redo transport services using database properties, see Managing Redo Transport Services.

    • Reset database properties related to Redo Apply services, such as DelayMins. Any apply delay must be removed before beginning a switchover. The broker will not allow a switchover to a standby that has an apply delay configured (DelayMins property is set to a non-zero value). For more details about managing Redo Apply services using properties, see Managing Log Apply Services.

    • For each temporary table, verifying that temporary files associated with that table on the primary database also exist on the standby database.

    Note that the broker does not use the properties to set up redo transport services and Redo Apply services until you actually switch over the primary database to the standby role. Thus, the validity of the values of these properties is not verified until after the switchover. Once you set these properties, their values persist through role changes during switchover and failover.

  • If fast-start failover is enabled, then a switchover can be performed only to the pre-specified target standby database and only if the standby database is synchronized with the primary database or is within the configured lag limit, for the max availability and max performance modes respectively. For information about enabling fast-start failover, see Enabling Fast-Start Failover.

  • You can use the SHOW CONFIGURATION WHEN PRIMARY IS command to show the redo transport configuration (based on each member's setting of the RedoRoutes property) that would be in effect if the specified database were the primary database. You can use this information to identify ahead of time any redo transport configurations that would be incorrect after a role change, including any standbys that will not receive redo because the RedoRoutes property was not configured correctly.

After a switchover completes, the broker preserves the overall Oracle Data Guard protection mode as part of the switchover process by keeping the protection mode at the same protection level (maximum protection, maximum availability, or maximum performance) it was at before the switchover. Apply services on all other bystander standby databases automatically begin applying redo data received from the new primary database.

If there are physical or snapshot standby databases in the configuration and the switchover occurs to a logical standby database, you need to re-create those databases from a copy of the new primary database and then reenable those databases, as described in Reenabling Disabled Databases After a Role Change.

Note:

In an Oracle Data Guard configuration, the SRVCTL -startoption and -role are updated after switchover to reflect the current open mode and database role on the new primary and standby databases. See "Database Service Configuration Requirements" for additional information about how the broker interacts with Oracle Restart.

Starting a Switchover

When a switchover is started, the primary and standby databases that are involved should have as small a redo lag as possible.

The act of switching roles should be a well-planned activity. Oracle Data Guard Concepts and Administration provides information about setting up the databases in preparation of a switchover.

To start a switchover using Cloud Control, select the standby database that you want to change to the primary role and click Switchover. When using DGMGRL, you need to issue the SWITCHOVER command, specifying the name of the standby database that you want to change into the primary role.

The broker controls the rest of the switchover.

How the Broker Performs a Switchover

These are the actions the broker performs after you start a switchover.

  1. Verifies that the primary and the target standby databases are in the following states:

    1. The primary database is enabled and is in the TRANSPORT-ON state.

    2. The target standby database is enabled and is in the APPLY-ON state.

    The broker allows the switchover to proceed as long as there are no errors for the primary database and the standby database that you selected to participate in the switchover operation. Errors occurring for any other configuration members will not impede the switchover.

  2. If block change tracking is enabled on the primary database, and the target standby database is mounted, broker remembers this setting so that block change tracking can be enabled on the new primary database.

  3. If the WAIT option is included in the SWITCHOVER command, and the databases are managed by Oracle Clusterware:

    • The broker notifies Oracle Clusterware to stop active services.

    • The broker continuously monitors for all sessions that are connected through these services to exit or for the specified wait time expires.

      • If a non-zero value is specified for the WAIT option, broker waits for the amount of time specified in the WAIT option.

      • If no value is specified for the WAIT option, broker waits for the amount of time specified by maximum configured drain_timeout amongst the active services. The drain_timeout is specified in the SRVCTL add service command.

      Note that a switchover operation may be started before the specified wait time, if all the sessions that are connected though the active services exit.

  4. Switches roles between the primary and standby databases.

    The broker first converts the original primary database to run in the standby role. If any errors occur during either conversion, the broker stops the switchover. See Troubleshooting Problems During a Switchover Operation for more information.

  5. Updates the broker configuration file to record the change in roles.

    This allows the appropriate Data Guard services, such as redo transport or redo apply, to be started when the database is restarted later for any reason.

  6. If the old primary database had block change tracking enabled and the target standby was mounted, the broker enables block change tracking on the new primary database.

  7. Restarts the new standby (former primary) database if the switchover occurs to a physical standby database, and Redo Apply begins applying redo data from the new primary database.

    If the switchover occurs to a physical standby database, and the former primary database is managed by Oracle Clusterware, broker directs Oracle Clusterware to restart the new physical standby database. Else, broker restarts the new physical standby database.

    After the restart, Redo Apply begins applying redo data from the new primary database.

  8. The new primary database is opened in read/write mode and redo transport services are started.

    If the former physical standby database was running with real-time query enabled, the new physical standby database will run with real-time query enabled.

    If the database is managed by Oracle Clusterware, broker does not open any of the PDBs. Instead, Oracle Clusterware opens PDBs on particular instances based on the service configuration. If the database is not managed by Oracle Clusterware, broker opens all the PDBs on the new primary database and on the target standby database (if real-time query is enabled).

The broker verifies the state and status of the databases to ensure that the switchover transitioned the databases to their new role correctly. Bystander standby databases that are not disabled by the broker after the switchover will continue operating in the state they were in before the switchover.

In the rare event that a switchover operation fails and you are left with no primary database, retry the switchover command. You can switch back to the original primary and then either retry the switchover to the original target standby, or choose another standby in the configuration to switch over to. See Troubleshooting Oracle Data Guard for more information.