Step 1 Database verification

1. Verify the standby database and make sure standby database is in sync with primary database.
2. Tail the alert log on both primary and standby to monitor the database during the entire switch
over time. Use this command : tail -f alert_$ORACLE_SID.log
3. Make sure below data guard parameters(log_archive_dest, log_archive_dest_state,
log_archive_config, fal_client, fal_server etc) are correctly configured on standby site. This would help log
shipping go smooth after the switch over.
Let application team bring the application down. Now DBA start switching over the database!
Step 2 Database Active Connection Verification
Make sure, no application connection on the database.
select count(*),username from v$session group by v$session
To be safer side, run the below script to kill any non local process to complete our switch over
smoothly.
tokill=`ps -ef | grep LOCAL=NO | grep -v grep | awk '{print $2}'`; echo $tokill;
tokill=`ps -ef | grep LOCAL=NO | grep -v grep | awk '{print $2}'`; kill -9 $tokill;

Step 3 The primary and standby should show the status as below.
set linesize 200
col DB_UNIQUE_NAME form a30
col DATABASE_ROLE for a20
col OPEN_MODE for a30
col SWITCHOVER_STATU for a30
select DB_UNIQUE_NAME,Database_role,open_mode,switchover_status from v$database;

The Primary database SWITCHOVER_STATUS can be either TO STANDBY or SESSIONS ACTIVE.

The standby database SWITCHOVER_STATUS should be NOT ALLOWED.

Step 4: Convert Primary to Standby:

On Primary
Execute the below command on primary (devdb12)
alter database commit to switchover to physical standby with session shutdown;

At this stage, the primary database(devdb12) is not completely converted to standby. The primary
database is down and it is ready to covert for standby database. The standby database (devdb12_dg and
devdb12_dr) are ready to convert to primary. After completing Step 6, the primary(devdb12) will be
turned to standby. Step 6 can be executed on this step. But it is always good practice to start standby
after starting the primary to reduce the application down time. All three database status should show as
below after running the above command.

The devdb12 SWITCHOVER_STATUS should be RECOVERY NEEDED.The devdb12_dg,devdb12_dr

database SWITCHOVER_STATUS should be TO PRIMARY

Step 5: Convert Standby to Primary

We are converting devdb12_dg to primary database. Hence login as devdb12_dg and run the below
command.

alter database commit to switchover to primary with session shutdown;

alter database open;
After opening the database, the status should be as below. The switchover_status
is FAILED_DESTINATION.

Now devdb12_dg becomes primary and ready to take the transactions. Still it is not ready to ship the
archive log file. At this moment, DBA can ask application team to start the application. Now application is
pointing to new primary(devdb12_dg). The old primary(devdb12) and second standby(devdb12_dr)
status should be as below. The old primary(devdb12) switch over status is RECOVERY_NEEDED. The
second standby(devdb12_dr) switch over status is NOT ALLOWED.

Step 6: - Convert Original Primary(devdb12) to Standby

Login to old primary(devdb12) and run the below command.

shutdown immediate;
startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session;
-- Wait for few minutes and make sure archive logs are shipping to standby database
alter database recover managed standby database cancel;
alter database open;
alter database recover managed standby database using current logfile disconnect;
Step 7 Verify the database mode for both primary and standby. Now devdb12 is standby and
devdb12_dg is primary database. Devdb12_dr is still standby and no change on devdb12_dr.
Step 8 Verify that archive logs are shipping correctly.

Or

Steps to manually switch over database roles

Login to the Primary Database and Switch the Logs

SQL> alter system archive log current;

----

---- (Issue this command few times)

(In case of RAC database, shutdown all the nodes except the primary one. Perform log switch in primary
node again)

Login to primary and check the max generated sequences

SQL> select thread#,max(sequence#)

from v$archived_log group by thread# order by thread#;

Login to standby and check the applied sequences

SQL> select thread#,max(sequence#)

from v$archived_log where applied='YES' group by thread#;

(Go to to the next step when all Standby Sequences = Primary Sequences or are different by not more
than 1)

Disable the transport of archives from the Primary Database

----

SQL> alter system set log_archive_dest_state_2=defer scope=both sid='*';

Check the conversion status of the Standby database

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS

-----------------

SESSIONS ACTIVE
During normal operations it is acceptable to see the following values for SWITCHOVER_STATUS on the
primary to be SESSIONS ACTIVE or TO STANDBY.

Convert the primary database to the new standby:

10

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

Database altered.

-----

----- shut down the new standby database

SQL> shut immediate;

-----

----- Mount the new standby database

SQL> startup mount;

Converting standby database to new Primary database

Stop managed recovery on old standby database

1

SQL> alter database recover managed standby database cancel;

Database altered.

Check the conversion status

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS

-----------------

NOT ALLOWED

During normal operations on the standby it is acceptable to see the values of NOT ALLOWED or
SESSIONS ACTIVE.

Perform Conversion Step

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

Database altered.
Check the status of Database Role to confirm the conversion from Standby to Primary

SQL> select name,database_role,protection_mode from v$database;

NAME DATABASE_ROLE PROTECTION_MODE

---------- ------------- ----------------

[db_name] PRIMARY MAXIMUM PERFORMANCE

Perform a clean shutdown and startup of database

SQL> shutdown immediate;

SQL> startup;

Enable the transport of archives from the New Primary Database

SQL> alter system set log_archive_dest_state_2=ENABLE scope=both sid='*';

Start managed recovery on the new standby database

3
SQL> alter database recover managed standby database disconnect;

Media Recovery Complete.

Start remaining instances in case of RAC database

srvctl start instance -d [database name] -i [instance_name]

or
Data Guard Switchover to a Physical
Standby
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
NAME
3
4 --------------------------------------------------------------------------------
5 /u01/app/oracle/oradata/standby/temp01.dbf
6
7 SQL>
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 ----------
5 0
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 from v$session where type = 'USER';
2
3
4 SID PROCESS PROGRAM
5 ---------- ------------------------ ------------------------------------------------
6 42 3536 emagent@prod.localdomain (TNS V1-V3)
47 3536 emagent@prod.localdomain (TNS V1-V3)
7 53 13544 sqlplus@prod.localdomain (TNS V1-V3)
8 61 3536 emagent@prod.localdomain (TNS V1-V3)
9 67 8266 oracle@dreco.localdomain (TNS V1-V3)
10
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.

1
SQL> alter session set tracefile_identifier='SWITCHOVERTEST_06032010';
2
3 Session altered.
4
5 SQL> alter database commit to switchover to physical standby;
6 alter database commit to switchover to physical standby
7 *
ERROR at line 1:
8 ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected
9
10
11 SQL>
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
Variable Size 620759112 bytes
11 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
3 SWITCHOVER_STATUS
4 --------------------
5 SESSIONS ACTIVE
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)
36 18592 oracle@prod.localdomain (TNS V1-V3)
7 42 1234 OMS
8
9 SQL>
10
As with the switchover to standby, some connected sessions may prevent the
switchover to primary. Since we have a SWITCHOVER_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 a LOG_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 op

db_unique_name="proddb" net_timeout=30 valid_for=(all_logfiles,primary_role)' scope = bot
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
2
3 Database altered.
4
5 SQL>
Switch the log files a couple of times on the new primary and check the status.

1 SQL> alter system switch logfile;

2
System altered.
3
4 SQL> /
5
6 System altered.
7
8 SQL> /
9
10 System altered.
11
12 SQL>/
13
System altered.
14
15 SQL> select status, gap_status from v$archive_dest_status where dest_id = 2;
16
17 STATUS GAP_STATUS
18 --------- ------------------------
19 VALID NO GAP
20
21 SQL>
22
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.