Switchover of Databases (Primary to standby and standby to primary) in Dataguard oracle 11g.
Oracle Version:- Enterprise Edition Release 11.2.0.1
OS:- Rhel 6.4
Primary database:- Prim
Standby database:- Stand
Switchover is a planned event, it is ideal when we might want to upgrade the primary database or change
the storage/hardware configuration (add memory, cpu networking), we may even want to upgrade the
configuration to Oracle RAC .
What happens during a switchover is the following :
1.) Notifies the primary database that a switchover is about to occur
2.) Disconnect all users from the primary database
3.) Generate a special redo record that signals the End of Redo (EOR)
4.) Converts the primary database into a standby database
5.) Once the standby database applies the final EOR record, guaranteeing that no data loss has been lost,
converts the standby database into the primary database.
Before doing the switchover lets run few select queries to find out some info:-
In primary:-
SQL> select status,INSTANCE_NAME ,database_role from v$database,v$instance;
STATUS INSTANCE_NAME DATABASE_ROLE
------------ ---------------- ----------------
OPEN prim PRIMARY
In standby:-
SQL> select status,INSTANCE_NAME ,database_role from v$database,v$instance;
STATUS INSTANCE_NAME DATABASE_ROLE
------------ ---------------- ----------------
MOUNTED stand PHYSICAL STANDBY
In primary:-
Archive log destination of Prim:-
SQL> show parameter log_archive_dest_1;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1 string LOCATION=/u01/app/oracle/flash
_recovery_area VALID_FOR=(ALL_
LOGFILES,ALL_ROLES) DB_UNIQUE_
NAME=prim
SQL> show parameter log_archive_dest_2;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2 string SERVICE=stand LGWR ASYNC VALID
_FOR=(ALL_LOGFILES,PRIMARY_ROL
E) DB_UNIQUE_NAME=stand
*Archivelog Destination 1 of Primary Database is "/u01/app/oracle/flash_recovery_area" and Archivelog
destination 2 of Primary database is pointing to the service-name of the standby database.
In standby:-
Archive log destination of Stand:-
SQL> show parameter log_archive_dest_1;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1 string LOCATION=/u01/app/oracle/flash
_recovery_area VALID_FOR=(ALL_
LOGFILES,ALL_ROLES) DB_UNIQUE_
NAME=stand
SQL> show parameter log_archive_dest_2;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2 string SERVICE=prim LGWR ASYNC VALID_
FOR=(ALL_LOGFILES,PRIMARY_ROLE
) DB_UNIQUE_NAME=prim
*Archivelog Destination 1 of Standby database is "/u01/app/oracle/flash_recovery_area" 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.)
Pre-Switchover Checks:-
In standby database:-
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;
PROCESS STATUS SEQUENCE#
--------- ------------ ----------
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CLOSING 27
RFS IDLE 0
RFS IDLE 28
MRP0 WAIT_FOR_LOG 28
The above result 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 database end are shipped and getting applied to the standby database.
At primary database:-
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
27
At standby database:-
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
27
In the above case, sequence# 27 is the maximum sequence generated at the primary database and the
same has been applied to the standby database.So both database's log files are in sync.
*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.
In primary database:-
SQL> select ts#, name ,status from v$tempfile;
TS# NAME STATUS
---------- ---------------------------------------- -------
3 /u01/app/oracle/oradata/prim/temp01.dbf ONLINE
SQL> select ts#,name from v$tablespace;
TS# NAME
---------- ----------------------------------------
0 SYSTEM
1 SYSAUX
2 UNDOTBS1
4 USERS
3 TEMP
6 EXAMPLE
In Standby database:-
SQL> select ts#, name ,status from v$tempfile;
TS# NAME STATUS
---------- ---------------------------------------- -------
3 /u01/app/oracle/oradata/stand/temp01.dbf ONLINE
SQL> select ts#,name from v$tablespace;
TS# NAME
---------- ----------------------------------------
0 SYSTEM
1 SYSAUX
2 UNDOTBS1
4 USERS
3 TEMP
6 EXAMPLE
*Verify that all datafiles are online on both primary and standby databases:-
On both primary and standby database:-
SQL> select name from v$datafile where status='OFFLINE';
no rows selected
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;
no rows selected
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.
SQL> show parameter job_queue_process;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
job_queue_processes integer 1000
Set this parameter to the value 0.
SQL> alter system set job_queue_processes=0 scope=spfile;
System altered.
*Verify that the primary database can be switched over to the standby
In primary database:-
SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO 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
In primary:-
SQL> alter database commit to switchover to physical standby with session shutdown;
Database altered.
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.
In standby database:-
SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO PRIMARY
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
Oracle Version:- Enterprise Edition Release 11.2.0.1
OS:- Rhel 6.4
Primary database:- Prim
Standby database:- Stand
Switchover is a planned event, it is ideal when we might want to upgrade the primary database or change
the storage/hardware configuration (add memory, cpu networking), we may even want to upgrade the
configuration to Oracle RAC .
What happens during a switchover is the following :
1.) Notifies the primary database that a switchover is about to occur
2.) Disconnect all users from the primary database
3.) Generate a special redo record that signals the End of Redo (EOR)
4.) Converts the primary database into a standby database
5.) Once the standby database applies the final EOR record, guaranteeing that no data loss has been lost,
converts the standby database into the primary database.
Before doing the switchover lets run few select queries to find out some info:-
In primary:-
SQL> select status,INSTANCE_NAME ,database_role from v$database,v$instance;
STATUS INSTANCE_NAME DATABASE_ROLE
------------ ---------------- ----------------
OPEN prim PRIMARY
In standby:-
SQL> select status,INSTANCE_NAME ,database_role from v$database,v$instance;
STATUS INSTANCE_NAME DATABASE_ROLE
------------ ---------------- ----------------
MOUNTED stand PHYSICAL STANDBY
In primary:-
Archive log destination of Prim:-
SQL> show parameter log_archive_dest_1;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1 string LOCATION=/u01/app/oracle/flash
_recovery_area VALID_FOR=(ALL_
LOGFILES,ALL_ROLES) DB_UNIQUE_
NAME=prim
SQL> show parameter log_archive_dest_2;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2 string SERVICE=stand LGWR ASYNC VALID
_FOR=(ALL_LOGFILES,PRIMARY_ROL
E) DB_UNIQUE_NAME=stand
*Archivelog Destination 1 of Primary Database is "/u01/app/oracle/flash_recovery_area" and Archivelog
destination 2 of Primary database is pointing to the service-name of the standby database.
In standby:-
Archive log destination of Stand:-
SQL> show parameter log_archive_dest_1;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1 string LOCATION=/u01/app/oracle/flash
_recovery_area VALID_FOR=(ALL_
LOGFILES,ALL_ROLES) DB_UNIQUE_
NAME=stand
SQL> show parameter log_archive_dest_2;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2 string SERVICE=prim LGWR ASYNC VALID_
FOR=(ALL_LOGFILES,PRIMARY_ROLE
) DB_UNIQUE_NAME=prim
*Archivelog Destination 1 of Standby database is "/u01/app/oracle/flash_recovery_area" 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.)
Pre-Switchover Checks:-
In standby database:-
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;
PROCESS STATUS SEQUENCE#
--------- ------------ ----------
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CLOSING 27
RFS IDLE 0
RFS IDLE 28
MRP0 WAIT_FOR_LOG 28
The above result 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 database end are shipped and getting applied to the standby database.
At primary database:-
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
27
At standby database:-
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
27
In the above case, sequence# 27 is the maximum sequence generated at the primary database and the
same has been applied to the standby database.So both database's log files are in sync.
*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.
In primary database:-
SQL> select ts#, name ,status from v$tempfile;
TS# NAME STATUS
---------- ---------------------------------------- -------
3 /u01/app/oracle/oradata/prim/temp01.dbf ONLINE
SQL> select ts#,name from v$tablespace;
TS# NAME
---------- ----------------------------------------
0 SYSTEM
1 SYSAUX
2 UNDOTBS1
4 USERS
3 TEMP
6 EXAMPLE
In Standby database:-
SQL> select ts#, name ,status from v$tempfile;
TS# NAME STATUS
---------- ---------------------------------------- -------
3 /u01/app/oracle/oradata/stand/temp01.dbf ONLINE
SQL> select ts#,name from v$tablespace;
TS# NAME
---------- ----------------------------------------
0 SYSTEM
1 SYSAUX
2 UNDOTBS1
4 USERS
3 TEMP
6 EXAMPLE
*Verify that all datafiles are online on both primary and standby databases:-
On both primary and standby database:-
SQL> select name from v$datafile where status='OFFLINE';
no rows selected
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;
no rows selected
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.
SQL> show parameter job_queue_process;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
job_queue_processes integer 1000
Set this parameter to the value 0.
SQL> alter system set job_queue_processes=0 scope=spfile;
System altered.
*Verify that the primary database can be switched over to the standby
In primary database:-
SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO 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
In primary:-
SQL> alter database commit to switchover to physical standby with session shutdown;
Database altered.
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.
In standby database:-
SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO PRIMARY
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
Run following in standby database;-
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 (stand)
The new primary database will be in mount state. Open this new primary database using the below query.
SQL>alter database open;
SQL> select status,INSTANCE_NAME ,database_role from v$database,v$instance;
STATUS INSTANCE_NAME DATABASE_ROLE
------------ ---------------- ----------------
OPEN stand PRIMARY
*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;
ORA-01507: database not mounted
ORACLE instance shut down.
Startup the new standby database (prim) in mount stage
SQL>startup mount;
ORACLE instance started.
Total System Global Area 413372416 bytes
Fixed Size 2213896 bytes
Variable Size 335546360 bytes
Database Buffers 71303168 bytes
Redo Buffers 4308992 bytes
Database mounted.
Start the managed recovery process on the the new standby database (prim)
SQL>alter database recover managed standby database disconnect from session;
Database altered.
QL> select status,INSTANCE_NAME ,database_role from v$database,v$instance;
STATUS INSTANCE_NAME DATABASE_ROLE
------------ ---------------- ----------------
MOUNTED prim PHYSICAL STANDBY
*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).
SQL> show parameter job_queue
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
job_queue_processes integer 0
SQL> alter system set job_queue_processes=1000 scope=spfile;
System altered.
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)
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
34
Maximum archivelog that has been shipped and applied to the new standby database (prim)
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
34
*Now if we want the real time apply enabled on new standby database(prim)
Perform the following queries on new standby database(prim)
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database open;
Database altered.
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
Please share your ideas and opinions about this topic. If you like this post, then please share with others. Please subscribe on email for every updates on mail.
If you need entity framework core versions, you can check this article.
ReplyDelete