Data Guard Switchover to a Physical Standby

by Eric Jenkinson on June 3, 2010

Categories: Data Guard,High Availability,Oracle Database
Tagged: Data Guard, primary, standby, switchover

A switchover can be used to reduce downtime for planned outages such as patching to the database or host OS and hardware
upgrades. In a switchover the primary database is transitioned to the standby role and the standby database is transitioned to
the primary role.

This document will detail the steps to perform a manual switchover.

Verify there is no log file gap between the primary and the standby database.

You can determine the status by querying V$ARCHIVE_DEST_STATUS.

1
SQL> select status, gap_status
2 2 from v$archive_dest_status
3 3 where dest_id = 2;
4
5 STATUS GAP_STATUS
6 --------- ------------------------
VALID NO GAP
7
8 SQL>
9
It is important that both the STATUS is VALID and that GAP_STATUS has the value NO GAP.
Verify that the standby database has temporary files that match the primary.

Primary

1 SQL> select file_name from dba_temp_files;

2
3 FILE_NAME
4 --------------------------------------------------------------------------------
5 /u01/app/oradata/proddb/temp01.dbf
6
SQL>
7
Standby

1 SQL> select name from v$tempfile;

2
3 NAME
4 --------------------------------------------------------------------------------
5 /u01/app/oracle/oradata/standby/temp01.dbf
6
SQL>
7
Verify there is no delay in effect for applying redo on standby. If there is a delay remove it.

You can determine if there is a delay in applying archive logs by looking at the DELAY_MINS column
of V$ARCHIVE_DEST.
1 SQL> select delay_mins from v$archive_dest where dest_id = 2;
2
3 DELAY_MINS
4 ----------
0
5
6 SQL>
7
If there is a delay you can use the following to disable the delay for the physical standby

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

Verify that the primary can be switched to the standby role.

The SWITCHOVER_STATUS of V$DATABASE indicates whether switchover is possible at this time.

1 SQL> select switchover_status from v$database;
2
3 SWITCHOVER_STATUS
4 --------------------
5 TO STANDBY
6
SQL>
7
The SWITCHOVER_STATUS should have the value of TO STANDBY or SESSIONS ACTIVE. If not then redo transport is
not functioning properly and you will not be able to perform the switchover.
If you received SESSIONS ACTIVE in the prior step you might have connections that may prevent the switchover. Verify
the active connections by querying V$SESSION.
1 SQL> select sid, process, program
2 2 from v$session where type = 'USER';
3
4 SID PROCESS PROGRAM
5 ---------- ------------------------ -------------------------------------------
-----
6 42 3536 emagent@prod.localdomain (TNS V1-V3)
7 47 3536 emagent@prod.localdomain (TNS V1-V3)
8 53 13544 sqlplus@prod.localdomain (TNS V1-V3)
9 61 3536 emagent@prod.localdomain (TNS V1-V3)
10 67 8266 oracle@dreco.localdomain (TNS V1-V3)
11
SQL>
12
You should verify the connected sessions even if the SWITCHOVER_STATUS is TO STANDBY.
Switch the Primary to the Standby Role

The command to switch the primary database to a standby database is ALTER DATABASE COMMIT TO SWITCHOVER
TO PHYSICAL STANDBY. If your database has a SWITCHOVER_STATUS of ACTIVE SESSIONS you will need to
append the WITH SESSION SHUTDOWN clause.
Note: the alter session statement is not required for switchover. I typically set the trace identifier prior to performing tasks
such as this to make identifying any trace file generated during the process easier.
SQL> alter session set tracefile_identifier='SWITCHOVERTEST_06032010';
1
2 Session altered.
3
4 SQL> alter database commit to switchover to physical standby;
5 alter database commit to switchover to physical standby
6 *
ERROR at line 1:
7 ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected
8
9
10 SQL>
11
12
If you get this error you have connected sessions that need to be shutdown. Re-issue the command with the WITH
SESSION SHUTDOWN clause.
1 SQL> alter database commit to switchover to physical standby with session
shutdown;
2
3 Database altered.
4
5 SQL>
If you still get the error run the query presented earlier to identify the connection sessions. Note: The connected sessions
reported in the output of the query against V$SESSION earlier were shutdown with the WITH SESSION
SHUTDOWN clause.
Next we need to shutdown and then mount the new standby (former primary).

1
2 SQL> shutdown immediate
3 ORA-01507: database not mounted
4
5
ORACLE instance shut down.
6 SQL> startup mount
7 ORACLE instance started.
8
9 Total System Global Area 830930944 bytes
10 Fixed Size 2217912 bytes
11 Variable Size 620759112 bytes
Database Buffers 205520896 bytes
12 Redo Buffers 2433024 bytes
13 Database mounted.
14 SQL>
15
After mounting the database notice that alert.log states that the database is now a Physical Standby database.

1 Thu Jun 03 11:12:34 2010

2 Successful mount of redo thread 1, with mount id 460768413
3 Physical Standby Database mounted.
At this time we have two standby databases. Next we need to prepare the original standby and convert it to the new primary.

Verify that the standby is ready to be switched to the primary role.

Again we look at SWITCHOVER_STATUS of V$DATABASE. This time we are looking for TO PRIMARY or SESSIONS
ACTIVE.
1 SQL> select switchover_status from v$database;
2
SWITCHOVER_STATUS
3 --------------------
4 SESSIONS ACTIVE
5
6 SQL>
7
Here we see that there are active sessions on the standby database. A quick check of V$SESSION will show us the active
sessions.
1 SQL> select sid, process, program
2 2 from v$session where type = 'USER';
3
4 SID PROCESS PROGRAM
---------- ------------------------ -------------------------------------------
5 -----
6 19 23147 sqlplus@dreco.localdomain (TNS V1-V3)
7 36 18592 oracle@prod.localdomain (TNS V1-V3)
8 42 1234 OMS
9
10 SQL>
As with the switchover to standby, some connected sessions may prevent the switchover to primary. Since we have
aSWITCHOVER_STATUS of SESSIONS ACTIVE we will need to apply the WITH SESSION SHUTDOWN clause.
The command to switch the standby database to a primary database is ALTER DATABASE COMMIT TO SWITCHOVER
TO PRIMARY. If your database has a SWITCHOVER_STATUS of ACTIVE SESSIONS you will need to append the WITH
SESSION SHUTDOWN clause.
1 SQL> alter session set tracefile_identifier='SWITCHOVERTEST_STBY_06032010';
2
3 Session altered.
4
5 SQL> alter database commit to switchover to primary with session shutdown;
6
7 Database altered.
8
SQL>
9
Next we open the new primary database.

1 SQL> alter database open;

2
3 Database altered.
4
5 SQL>
If you take a look in the alert.log you see that our former standby database has been mounted as the primary.

1 Standby became primary SCN: 3363769

2 Switchover: Complete - Database mounted as primary
3 Completed: alter database commit to switchover to primary with session shutdown
Note: Before going on you should check the LOG_ARCHIVE_DEST_n parameters. You may need to set up
aLOG_ARCHIVE_DEST_n parameter to write archive logs to the new primary.
1SQL> alter system set log_archive_dest_2='service="proddb" LGWR ASYNC NOAFFIRM delay=0
db_unique_name="proddb" net_timeout=30 valid_for=(all_logfiles,primary_role)' scope = b
2
3System altered.
4
5SQL>
Start Redo Apply on the new physical standby database
As the last step we will restart the Redo Apply services on the new standby. Below is an exampled of enabling real-time
apply. If for some reason you do not want to use real-time apply remove the USING CURRENT LOGFILE from the
command.
1 SQL> alter database recover managed standby database using current logfile
disconnect from session;
2
3 Database altered.
4
5 SQL>
Switch the log files a couple of times on the new primary and check the status.

1
2 SQL> alter system switch logfile;
3
4 System altered.
5
SQL> /
6
7
System altered.
8
9 SQL> /
10
11 System altered.
12
13 SQL>/
14
15 System altered.
16
SQL> select status, gap_status from v$archive_dest_status where dest_id = 2;
17
18 STATUS GAP_STATUS
19 --------- ------------------------
20 VALID NO GAP
21
22 SQL>
23
The switchover is complete.

Keep in mind that if your primary and standby database are being monitored through Enterprise Manager you will need to
reflect these changes manually. Enterprise Manager will not know about the switchover or that the primary is now the
standby and old standby is now the new primary. It will just report the blocked connection to the old primary.

Share this:

 Facebook
 Twitter
 Reddit
 Tumblr
 Print
 Email

 Comments
 Leonardo (August 23, 2012 3:59 pm)
pretty simple, I follow the steps and it works great, I just will be adding

Step 1: Identify and resolve any redo gaps

Query the V$ARCHIVE_GAP view to determine if there are any redo gaps on the target standby database

SQL> SELECT thread#

,low_sequence#
,high_sequence#
FROM v$archive_gap;