1.

STEPS for switchover from primary to standby database: 

This document only talks about switchover involving physical standby database.
In this example, the 
original primary data is called PRIM and the original standby database is called
STBY. 

I. Checks before Switchover: 

1. Verify the primary database instance is open and the standby database
instance is mounted. 

2. Verify there are no active users connected to the databases. 

3. Make sure the last redo data transmitted from the Primary database was
applied on the standby 
database. Issue the following commands on Primary database and Standby
database to find out: 
SQL>select sequence#, applied from v$archvied_log; 
Perform SWITCH LOGFILE if necessary. 

In order to apply redo data to the standby database as soon as it is received, use
Real-time apply. 

II. Quick Switchover Steps 

1. Initiate the switchover on the primary database PRIM: 

SQL>connect /@PRIM as sysdba 
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY
WITH SESSION 
SHUTDOWN; 

2. After step 1 finishes, Switch the original physical standby db STBY to primary
role; 
Open another prompt and connect to SQLPLUS: 
SQL>connect /@STBY as sysdba 
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 

3. Immediately after issuing command in step 2, shut down and restart the
former primary instance 
PRIM: 
SQL>SHUTDOWN IMMEDIATE; 
SQL>STARTUP MOUNT; 
 4. After step 3 completes: 
- If you are using Oracle Database 10g release 1, you will have to Shut down
and restart the new 
primary database STBY. 
SQL>SHUTDOWN IMMEDIATE; 
SQL>STARTUP; 

- If you are using Oracle Database 10g release 2, you can open the new Primary
database STBY: 
SQL>ALTER DATABASE OPEN; 

STBY is now transitioned to the primary database role. 

5. On the new primary database STBY, perform a SWITCH LOGFILE to start

sending redo data to the 
standby database PRIM. 
SQL>ALTER SYSTEM SWITCH LOGFILE;
Check the primary database instance must be open and the standby database instance
is mounted. 

No one should be connected to the database. 

Check the current archived log and last archived log on both primary and standby
databases. 

You can use the below command to check....... 

SQL> select thread#,max(sequence#) from v$archived_log where applied='YES' 

SQL>connect /@PRIM as sysdba 

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH

SESSION 
SHUTDOWN; 

After that, Switch the original physical standby db to primary role; 

first connect to your standby database and execute the following command...... 

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 

3. Immediately after issuing command in step 2, shut down and restart the former
primary instance 
PRIM: 
SQL>SHUTDOWN IMMEDIATE; 
SQL>STARTUP MOUNT; 

4. After step 3 completes: 

Now open the new Primary database 

SQL>ALTER DATABASE OPEN; 

STANDBY is now transitioned to the primary database role. 

5. On the new primary database STANDBY, perform a SWITCH LOG FILE to start
sending redo data to the 
standby database PRIM 
. 
SQL>ALTER SYSTEM SWITCH LOGFILE;

========= MANUAL SWITCHOVER============== 

If the primary is a RAC database, you must shut down all instances but one. 

Step 1: On the primary database, query the V$database view to verify that the
SWITCHOVER_STATUS column indicates that a switchover is possible. 

SQL> select switchover_status from v$database; 

If SWITCHOVER_STATUS returns a value of TO_STANDBY, everything is good. If the

query returns SESSION ACTIV, you should perform the SWITCHOVER command with
the SESSION SHUTDOWN clause. 

Step 2: Convert the primary database into a physical standby. 

SQL>alter database commit to switchover to physical standby; 

If the SWITCHOVER_STATUS column in step 1 returned SESSION ACTIVE, issue the

following command: 

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

Step 3: Shut down and restart the old primary as a new standby. 

SQL> shutdown immediate; 

SQL> startup mount; 
Step 4: When we converted the primary to a standby, we generated a marker in the
redo stream and sent that market to the standby. The market states that no more redo
has been generated. As soon as the standby receives and recovers that marker, it is
eligible to become a primary database. Query the SWITCHOVER_STATUS column of
V$DATABASE on the standby to ensure that the marker has been recovered and it is
ready for the switchover to primary. 

SQL>select switchover_status from v$database; 

If SWITCHOVER_STATUS returns TO_PRIMARY, the marker has been recovered and

you can proceed with the SWITCHOVER TO PRIMARY command. If the status is
SESSION ACTIVE, you should either disconnect active sessions or issue the
SWITCHOVER command with the SESSION SHUTDOWN clause. If the status states NOT
ALLOWED, the market has not been received and recovered bye the standby,and
switchover cannot proceed. 

Step 5: Convert the standby to a primary database. 

SQL> alter database commit to switchover to primary; 

Or, if the SWITCHVOER_STATUS returned SESSION ACTIVE; 

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

Step 6: Shut down and restart the new primary database. 

SQL> shutdown immediate; 

SQL> startup; 

=====SWITCHOVER USING DATAGUARD BROKER========= 

Step 1: Set the LogXptMode property appropriately. 

Suppose we want to switchover to LSD site. 

If primary server is in maximum protection or maximum availability mode, execute

following. 

DGMGRL>EDIT DATABASE 'LSD’ SET PROPERTY 'LogXptMode'='SYNC'; 

Property "LogXptMode" updated. 

Step 2: Check the primary database. 

DGMGRL> SHOW DATABASE VERBOSE 'orc1’; 

Step 3: Check the standby database that is the target of the switchover. 
DGMGRL> SHOW DATABASE VERBOSE ‘LSD’; 

Step 4: If primary database has multiple instances. Shutdown all instances except one. 

DGMGRL> SWITCHOVER TO ‘LSD’; 

Performing Switchover Now. Please wait… 

Once the broker completes the switchover process, we are given the following
response. 

Switchover succeeded. New primary is “LSD”. 

NOTE: LSD= local physical standby database ORC1= Primary 

========= Switchover using 11g OEM Grid Control ======== 

To perform a switchover, navigate to the “Setup and Manage” screen, select the
standby server you wish to become the new primary server, then click the “Switchover”
button. 

-Regards, 
Sandeep

Oracle dataguard
What are the things that a DBA needs to take care of before performing switchover
from Production DB to physical standby which is at remote location in Data guard
environment?
Oracle 10g on AIX
Sandeep Mohanty • CHECKLIST BEFORE SWITCHOVER OPERATION 
===================================== 
Please note 

log_archive_dest_state_3 :(archive dest for standby database) 

log_archive_dest_state_1 :(archive dest for primary database) 

SELECT PROTECTION_MODE FROM V$DATABASE; 

SQL> select name,value from v$parameter where name in
('log_archive_dest_1','log_archive_dest_state_1','log_archive_dest_3','log_archive_dest
_state_3); 

Make sure 'lgwr' and not 'arch' is mentioned here, otherwise new primary database will
not open after switchover (if the protection_mode is Maximum availability). 
-- on standby database-- 
SQL> select database_role from v$database; 

DATABASE_ROLE 
---------------- 
PHYSICAL STANDBY 

-- on primary -- 
SQL> select database_role from v$database; 

DATABASE_ROLE 
---------------- 
PRIMARY 

SQL>select name,value from v$parameter where name in

('log_archive_dest_1','log_archive_dest_state_1',
'log_archive_dest_3','log_archive_dest_state_3); 
log_archive_dest_state_3 
------------------ 
DEFER --->DO NOT PROCEED. 
issue this command : sql> alter system set log_archive_dest_state_3='ENABLE'
scope=both; 

---- on primary ---- 

SQL> select distinct status from v$datafile; 

STATUS 
——- 
ONLINE 
SYSTEM 

If any file(s) are in RECOVER status, DO NOT PROCEED with the switchover 

-- on standby database-- 
SQL> select distinct open_mode from v$database; 

OPEN_MODE 
———- 
MOUNTED --->PROCEED with switchover. 
SQL> select distinct open_mode from v$database; 

OPEN_MODE 
———- 
READ ONLY --->DO NOT PROCEED with switchover. 

To confirm that logs are being shipped and more importantly the LAST LOG archived
has been applied… 

---- on primary ---- 

SQL> select max(SEQUENCE#) “LAST_LOG_GENERATED” FROM V$ARCHIVED_LOG
WHERE THREAD# =1 and ARCHIVED=’YES’; 

LAST_LOG_GENERATED 
—————— 
3988 

-- on standby database-- 
SQL> select max(SEQUENCE#) “LAST_LOG_APPLIED” FROM V$ARCHIVED_LOG
WHERE THREAD# = 1 and APPLIED=’YES’; 

LAST_LOG_APPLIED 
—————- 
3988 

---> PROCEED 

-Regards, 
Sandeep