This section will provide you with details on how to perform a Graceful Switchover (GS) which is a controlled, reversible and zero data loss process which switches primary and standby database roles. It is not to be executed in Primary Site Disaster Scenarios.

It is useful in situations when you would like to for perform any sort of maintenance on your production server (for example OS patch, hardware maintenance, etc …)

Graceful switchover requires Primary and Standby site to be fully online and connected. GS is completely different process from Failover (Activation) process.

1. Prerequisites

Because switchover is reversible process for switching roles, it’s also very complex. There are number of prechecks you should do before when planning the switchover process.

Note that none of those steps will require any downtime from your primary.

A. Communication must work from standby to primary

During normal synchronization, only communication Primary => Standby is used and there’s no guarantee that it work. To verify, please do following:

disable automated standby update (ASU) and run one time backup & transfer + apply as per Post Tasks - Automatic Standby Update (ASU)
afterwards run on primary server:

cd standbymp/oracle
./dbvctl -d SLASH -f switchover_precheck

$ /usr/dbvisit/standbymp/oracle/dbvctl -d SLASH -f switchover_precheck

Running pre-checks       ... done

On completion of Gracefull Switchover new primary database will have tempfiles and redologs as following:

REDOLOGS
Group 1: One OMF member in each location: /u02/app/oracle/oradata,/u02/app/oracle/fast_recovery_area
Group 2: One OMF member in each location: /u02/app/oracle/oradata,/u02/app/oracle/fast_recovery_area
Group 3: One OMF member in each location: /u02/app/oracle/oradata,/u02/app/oracle/fast_recovery_area

TEMPFILES
Id 1: OMF file under /u02/app/oracle/oradata
Id 2: OMF file under /u02/app/oracle/oradata
Id 4: OMF file under /u02/app/oracle/oradata
Id 5: OMF file under /u02/app/oracle/oradata

Once precheck completes, enable again ASU

B. Dbvisit Base folder must have free space equal to redo log member size

you need to check that mountpoint where DBVISIT_BASE is located has sufficient space for one online redo log member. The size of redo log member can be seen on primary:

SQL> select distinct(bytes)/1024/1024 from v$log;

In case the space isn’t sufficient you may need to add DDC variables GSDIR, GSDIR_DR as per DDC File Maintenance

C. All Pluggable databases on Primary should be READ WRITE

Run on primary:

Except PDB$SEED of course. This applies only to CDB databases.

D. All paths in RMAN settings must exist on primary and standby server

Run on primary and standby:

all paths must exist on both servers. This specifically regard controlfile autobackup location.

2. Important considerations

There are following important considerations before running GS:

If RMAN is used in no-catalog mode on primary or standby database, execution of Graceful Switchover will render any backup information and setting in primary and standby controlfiles unusable. After Graceful switchover, crosscheck and catalog of existing backups must be performed. This is because controlfile is swapped between primary and standby database.
Restore points are not supported and must be dropped prior to GS
If your primary and / or standby database are registered with oracle grid as srvctl resources and you have defined custom services, you need to add parameters SERVICE_USED, SERVICE_USED_DR to your DDC file and set them to Y as per: DDC File Maintenance

3. Running Graceful Switchover from GUI

Graceful Switchover is extremely sensitive for logswitches done on primary database and because of this, GS must be always performed on primary database without any connected application.

The expected duration of the switchover is around 10 minutes and it doesn’t scale with database size.

We recommend following steps as safest approach for succesfully completing GS procedure:

A: stop automated standby update (ASU)
B: stop application
C: stop database listener on primary server and make sure it's stopped on standby server
D: restart primary database (this will ensure database will be cleared of any user sessions)
E: perform backup & send + apply archivelog
F: start GS process in GUI and wait for it to finish
G: perform backup & send + apply archivelog

Modification of ASU as well as sending & applying archivelogs is described here:

Post Tasks - Automatic Standby Update (ASU)

To Start Graceful switchover in GUI click on the “Graceful Switchover” option in the ACTIONS pane:

On the next window, click on start (3) once prerequisite check completes successfully:

Note the position and status of primary and standby server (1,2) before the switchover commences.

After starting, switchover task will be visible in the task bar on the right:

And you can view its details by clicking on it:

Once switchover completes, you will see on the dashboard Databases with reversed roles:

Enable Automatic Standby update (ASU) again.

To Switch back to the original configuration, repeat the same steps.

Dbvisit Standby Version 12 User Guide

Graceful Switchover (GS)

Analytics

1. Prerequisites

2. Important considerations

3. Running Graceful Switchover from GUI

Related content