Switchover of Databases (Primary to standby and standby to primary)

This document applies to Oracle Enterprise Edition.

Setup:

Prim (Primary Database with connection string as “prim”)

Stnd (Secondary Database with connection string as “stnd”)

Archivelog Destination 1 of Primary Database is “/u01/arch/prim” and Archivelog destination 2 of

Primary database is pointing to the service-name of the standby database.

Archivelog Destination 1 of prim:

Archivelog Destination 2 of prim:

Archivelog Destination 1 of Standby database is “/u01/arch/stnd” and archivelog destination 2 of

standby database is pointing to the service-name of the primary database. (Note: destination 2 in
standby database is not mandatory. It is required only if the standby database would be running in
as primary database during switchover or failover. Hence it would be a good practice to set this
parameter to avoid problems during the switchover or failover.)

Archivelog destination 1 of stnd:

Archivelog destination 2 of stnd:

Pre-Switchover Checks:

These checks will have to be performed before the switchover activity is performed.

Verify whether Managed Recovery process is running on the standby database

Use the following query to check if the managed recovery process is running on the standby
database.

SQL>select process,status,sequence# from v$managed_standby;

The above fig. shows that the Managed Recovery Process (MRP0) is running on the standby
database. If MRP is not running, then start the process with real time enabled using the below query
in the standby database.

SQL>alter database recover managed standby disconnect from session;

Once when the MRP has started on the standby database, make sure that the archive logs generated
at the primary end are shipped and getting applied to the standby database.

At the primary side check the maximum archive log sequence that has got generated:
At the standby side, check the maximum archive log sequence that has been applied from the
primary database:

In the above case, sequence# 82 is the maximum sequence generated at the primary database and
the same has been applied to the standby database.

Verify primary and standby tempfiles match

For each temporary tablespace on the standby, verify that temporary files associated with that
tablespace on the primary database also exist on the standby database. Tempfiles added after initial
standby creation are not propagated to the standby. Run this query on both the primary and target
physical standby databases and verify that they match.

SQL>select tmp.name filename,bytes,ts.name tablespace from v$tempfile tmp, v$tablespace ts where

tmp.ts#=ts.ts#;

Verify that all datafiles are online on both primary and standby databases

Check whether all the datafiles are online prior to the switchover on both primary and standby
databases

SQL>select name from v$datafile where status=’OFFLINE’;

On Primary side:

On Standby side:

If there are any offline datafiles, then bring them online using the below query
SQL>alter database datafile <datafile name> online;

Switchover Steps:

These steps are performed during the switchover process at the primary database side.

Check if there are any jobs running on the primary database using the below query.
SQL>select * from dba_jobs_running;

If there are any jobs running on the primary database and if it’s execution is not very important, then
terminate the job to continue further.
Block further job submission by setting the job_queue_processes parameter to 0 so that there would
be no jobs running during switchover.

In the above fig. the job_queue_processes parameter is set to 1000. Set this parameter to the value
0.

Verify that the primary database can be switched over to the standby

Query the switchover_status column of the v$database view on the primary database to determine
whether the primary database can be switched over to the standby.

A value of TO STANDBY or SESSIONS ACTIVE (which requires the WITH SESSION SHUTDOWN clause
on the switchover command) indicates that the primary database can be switched to the standby
role. If neither of these values is returned, a switchover is not possible because redo transport is
either mis-configured or is not functioning properly.

Switchover the primary database to standby

Once when value of switchover_status returns “TO STANDBY” or “SESSIONS ACTIVE” on the primary
database, then perform the switchover using the below query

SQL>alter database commit to switchover to physical standby with session shutdown;

Now the primary database is switched over to the standby database. The execution of the above
command may take some time and the archive logs generated during its execution would be
automatically applied to the standby database. Once when the command is executed with the
output as “Database altered”, it means that the primary database has been switched over to the
standby.
Note: Always perform the switchover of the primary database to standby database first and then switchover
the standby database to primary. If not, then you would end up landing with two primary databases

Switchover the standby database to primary

Query the switchover_status column from the v$database view at the standby side to determine
whether the standby database can be switched over to the primary database.

A value of TO PRIMARY or SESSIONS ACTIVE indicates that the standby database is ready to be
switched to the primary role. If neither of these values is returned, verify that redo apply is active
and that redo transport is configured and working properly. Continue to query this column until the
value returned is either TO PRIMARY or SESSIONS ACTIVE.

Once when the value of switchover_status returns “TO PRIMARY” or “SESSIONS ACTIVE” on the
standby database, then perform the switchover using the below query

SQL>alter database commit to switchover to primary with session shutdown;

Now the standby database has been switched over to the primary database.

Open the new primary database (stnd)

The new primary database will be in mount state. Open this new primary database using the below
query.

SQL>alter database open;

Restart the new standby database

Restart the new standby database (old primary database prim), bring it to the mount stage and start
the managed recovery process.

Shutdown the new standby database (prim)

SQL>shutdown immediate;

Startup the new standby database (prim) in mount stage

SQL>startup mount;

Start the managed recovery process on the the new standby database (prim)

SQL>alter database recover managed standby database disconnect from session;

Post-Switchover tasks

Reset the job_queue_processes parameter to its previous value

Set the job queue processes to its original value on the new standby (prim).
  

Now the roles of the databases have been changed. The primary database (prim) has been changed
to standby database and the standby database (stnd) has been changed to primary database.

The archive logs that get generated in the new primary database (stnd) get shipped automatically to
the new standby database (prim) and they are applied on it automatically.

Maximum archivelog generated at the new primary database (stnd)

Maximum archivelog that has been shipped and applied to the new standby database (prim)

The roles can again be reversed by following the same above procedures.