Documente Academic
Documente Profesional
Documente Cultură
Setup:
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:
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.
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
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;
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
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.