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 its 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.