Scribd
Upload
454 views

12c Data Guard Switchover Best Practices Using SQLPLUS

This document provides steps to perform a switchover from a physical standby database to a primary database using SQL*Plus. The key steps are: 1. Verify the target standby database is ready for switchover by checking log shipping and synchronization. 2. Enable tracing and tail logs on primary and standby databases. Switch over the standby to primary and open the new primary. 3. Restart the former primary as a new standby and verify log shipping from the new primary to standby.

Uploaded by

Ma Godfrey
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
454 views

12c Data Guard Switchover Best Practices Using SQLPLUS

This document provides steps to perform a switchover from a physical standby database to a primary database using SQL*Plus. The key steps are: 1. Verify the target standby database is ready for switchover by checking log shipping and synchronization. 2. Enable tracing and tail logs on primary and standby databases. Switch over the standby to primary and open the new primary. 3. Restart the former primary as a new standby and verify log shipping from the new primary to standby.

Uploaded by

Ma Godfrey
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

12c Data guard Switchover Best Practices using SQLPLUS (Doc ID

1578787.1)

To
Bottom

In this Document
Goal
*** Reviewed for Relevance 16-Jul-2015 ***
This Document describs step by step method to perform switchover on Physical Standby
Environment using SQLPLUS.
Solution

I. Pre-Switchover check
Verify that the target standby is ready for switchover.
Checks ORL status on target standby.
What to do?
Verify Primary and Standby tempfiles match
NOTE : For multiple Standby environment make sure all the standby in SYNC with primary.

II SWITCHOVER
Enable tracing on both primary and standby to diagnose in case of any issue.
Tail Alert Logs (optional) on all instances
Switchover the standby database to a primary
Open the new primary database
Restart the new standby

III. Post-Switchover Steps


Set Trace to Prior Value
Verify that the new primary shipping logs to standby and standby is applying.
APPLIES TO:
Oracle Database - Enterprise Edition - Version 12.1.0.1 to 12.1.0.2 [Release 12.1]
Information in this document applies to any platform.
GOAL
*** Reviewed for Relevance 16-Jul-2015 ***
This Document describs step by step method to perform switchover on Physical Standby
Environment using SQLPLUS.

SOLUTION

I. Pre-Switchover check
Verify that the target standby is ready for switchover.
Verify that the target standby is synchronous with primary and Redo shipping working fine from
primary.
SQL>alter database switchover to <target standby db_unique_name> verify;
The above command will verify following things,
a. Verifies that the release version is minimum 12.1
b. Primary REDO shipping.
c. Standby MRP recovery running and its synchronous with primary, else it will through below
error in SQLPROMPT and alert log as well.
For example,
SQL>alter database switchover to chicago verify;
ORA-16470: Redo Apply is not running on switchover target

------Primary alert log-----SQL>alter database switchover to chicago verify;


ORA-16470 signaled during: alter database switchover to chicago verify...

Checks ORL status on target standby.


If it is dirty then it will though the warning messages like
SQL> alter database switchover to chicago verify;

ERROR at line 1:
ORA-16475: succeeded with warnings, check alert log for more
details

-----Primary Alert log----------SWITCHOVER VERIFY WARNING: switchover target has dirty online redo logfiles that
require clearing.
It takes time to clear online redo logfiles. This may slow down switchover process.

What to do?
Make sure log_file_name_convert set properly on target standby.
SQL>show parameter log_file_name_convert;
NOTE: If not set set the value for example if directory structure changing only in
db_uniquq_name. for example,
Primary ORL location is /oradata/boston/<>
Standby logfile location is /oradata/chicago/logfiles>
Set the parameter like,
alter system set LOG_FILE_NAME_CONVERT=boston,chicago scope=spfile;
NOTE: Restart the standby and start the MRP. When you restart standby and start MRP then it
clears all the ORLs at standby provided log_file_name_convert set properly.
If Standby is synchronous with primary, we will get below messages,
SQL> alter database switchover to chicago verify;
Database altered.

--------- Primary Alert log -------

SWITCHOVER VERIFY: Send VERIFY request to switchover target CHICAGO


SWITCHOVER VERIFY COMPLETE
Completed: alter database switchover to chicago verify

Verify Primary and Standby tempfiles match


Tempfiles created after standby creation will not be propagated to standby. Check the TEMP files
using below query and add new TEMP files at standby is required.
SQL> col name for a45
SQL> select ts#,name,ts#,status from v$tempfile;
NOTE : For multiple Standby environment make sure all the standby in SYNC with primary.

II SWITCHOVER
Enable tracing on both primary and standby to diagnose in case of any issue.
SQL>alter system set log_archive_trace=8191 sid=*;
Tail Alert Logs (optional) on all instances
@primary and standby,
SQL>show parameter background_dump_dest
$tail -600f background_dump_dest/alert*

* NOTE : In RAC environment no need to shutdown all instances apart from one instanc.
Switchover(SQLPLUS) comand itself shutdown all the nodes.

Switchover the standby database to a primary


Primary-Boston,

SQL>alter database switchover to chicago;


Database altered.
.
Sample output from primary (BOSTON) and standby (CHICAGO),
--------------Primary Alert log "alert_boston.log"-------------Fri Aug 23 11:05:23 2013
ALTER SYSTEM SET log_archive_trace=8191 SCOPE=BOTH;
alter database switchover to chicago
Fri Aug 23 11:05:43 2013
Starting switchover [Process ID: 3340]
Fri Aug 23 11:05:43 2013
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [Process Id:
3340] (boston)
.
Fri Aug 23 11:05:44 2013
Active, synchronized Physical Standby switchover target has been identified
Preventing updates and queries at the Primary
Generating and shipping final logs to target standby
Switchover End-Of-Redo Log thread 1 sequence 11 has been fixed <---------Sequence 11 is
End-Of-Redo
Switchover: Primary highest seen SCN set to 0x0.0x229306
ARCH: Noswitch archival of thread 1, sequence 11
.

Switchover: Primary controlfile converted to standby controlfile succesfully.


Switchover: Complete - Database shutdown required
Sending request (convert to primary database) to switchover target CHICAGO
OCISessionBegin with PasswordVerifier succeeded
Switchover complete. Database shutdown required
USER (ospid: 3340): terminating the instance
Fri Aug 23 11:05:51 2013
Instance terminated by USER, pid = 3340
Completed: alter database switchover to chicago

-------------------alert log "alert_chicago.log"-----------------Fri Aug 23 11:05:47 2013


SWITCHOVER: received request 'ALTER DATABASE COMMIT TO SWITCHOVER TO
PRIMARY' from primary database.
Fri Aug 23 11:05:47 2013
ALTER DATABASE SWITCHOVER TO PRIMARY (chicago)
Maximum wait for role transition is 15 minutes.
.
Standby became primary SCN: 2265860
Switchover: Complete - Database mounted as primary
SWITCHOVER: completed request from primary database.

NOTE: At standby side we wait only for 15 minutes for the standby to synchronous with

primary.
Open the new primary database
SQL>alter database open;
Restart the new standby
SQL>shut abort
SQL>startup
SQL>alter database recover managed standby database disconnect;

III. Post-Switchover Steps


Set Trace to Prior Value
SQL> alter system set log_archive_trace=0;
System altered.
Verify that the new primary shipping logs to standby and standby is applying.
@primary,
SQL>alter system switch logfile;
SQL>select dest_id,error,status from v$archive_dest where
dest_id=<your remote log_archive_dest_<n>>;
SQL>select max(sequence#),thread# from v$log_history group by
thread#;
If remote log_Archive_destination is 2 i.e log_archive_dest_2.
SQL>select max(sequence#)
dest_id=2;

from v$archived_log where applied='YES' and

@standby,
SQL>select process,sequence#,thread#,status from
v$managed_standby;
SQL>select max(sequence#),thread# from v$archived_log group by

thread#;

Use gv$managed_standby for RAC.

You might also like