一.切换前检查
1.检查备库已经全部接收到主库的redo
如果是最大可用性、最大保护性模式，可以在primary端查看v$archive_dest_status，确认是否所有的redo已经传送到备库
#在主库执行
SQL> select db_unique_name,protection_mode,synchronization_status,synchronized from v$archive_dest_status; DB_UNIQUE_NAME PROTECTION_MODE SYNCHRONIZATION_STATUS SYN ------------------------------ -------------------- ---------------------- --- NONE MAXIMUM PERFORMANCE CHECK CONFIGURATION NO dgs MAXIMUM PERFORMANCE DESTINATION HAS A GAP NO SQL>
可以看出主备未同步且是最大性能保护模式，还要执行更多检查操作(如果是最大可用性、最大保护性模式但未同步，同样需要执行更多检查操作)：
#在主库执行
SQL> select thread#,sequence#,status from v$log;
THREAD# SEQUENCE# STATUS
---------- ---------- ----------------
1 46 INACTIVE
1 47 CURRENT
1 45 INACTIVE
SQL>
#在备库执行
SQL> select client_process,process,sequence#,status from v$managed_standby; CLIENT_P PROCESS SEQUENCE# STATUS -------- --------- ---------- ------------ ARCH ARCH 46 CLOSING ARCH ARCH 0 CONNECTED ARCH ARCH 0 CONNECTED ARCH ARCH 0 CONNECTED ARCH ARCH 44 CLOSING ARCH RFS 0 IDLE UNKNOWN RFS 0 IDLE UNKNOWN RFS 0 IDLE LGWR RFS 47 IDLE N/A MRP0 47 WAIT_FOR_LOG 10 rows selected. SQL>
从结果可以看出，当前主库发送来的sequence是47
2.检查备库已经将所有redo应用到备库
2.1 physical standby环境
SQL> select client_process,process,sequence#,status from v$managed_standby; CLIENT_P PROCESS SEQUENCE# STATUS -------- --------- ---------- ------------ ... N/A MRP0 48 WAIT_FOR_LOG ... 10 rows selected. SQL>
如果MRP0的状态是"wait_for_gap",则不能进行switchover。"wait_for_log"表示要么没有开启实时应用、要么开启了delay设置。如果是设置了delay，要停止redo apply，使用nodelay重启redo apply，否则无法switchover。
2.2 logical standby环境
SQL> select applied_scn, latest_scn, mining_scn from v$logstdby_progress; SQL> select status from v$logstdby_process where type='READER';
3.停掉主库上的job、rman操作等
SQL> select process, operation, r.status, mbytes_processed pct, s.status from v$rman_status r, v$session s where r.sid=s.sid;
二、正式切换
1.主库查看
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS -------------------- TO STANDBY SQL> SELECT PROGRAM, TYPE FROM V$SESSION WHERE TYPE='USER'; PROGRAM TYPE ------------------------------------------------ ---------- sqlplus@dgp.example.com (TNS V1-V3) USER SQL>
2.备库查看
SQL> SELECT PROGRAM, TYPE FROM V$SESSION WHERE TYPE='USER'; PROGRAM TYPE ------------------------------------------------ ---------- sqlplus@dgs.example.com (TNS V1-V3) USER oracle@dgp.example.com (TNS V1-V3) USER oracle@dgp.example.com (TNS V1-V3) USER oracle@dgp.example.com (TNS V1-V3) USER oracle@dgp.example.com (TNS V1-V3) USER SQL>
3.主库执行switchover操作
SQL> alter database commit to switchover to physical standby with session shutdown;
对应的主库alert日志内容：
Thu Apr 21 05:24:25 2016 alter database commit to switchover to physical standby with session shutdown ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [Process Id: 2796] (dgp) Waiting for all non-current ORLs to be archived... All non-current ORLs have been archived. Waiting for all FAL entries to be archived... All FAL entries have been archived. Waiting for potential Physical Standby switchover target to become synchronized... Active, synchronized Physical Standby switchover target has been identified Switchover End-Of-Redo Log thread 1 sequence 48 has been fixed Switchover: Primary highest seen SCN set to 0x0.0x110542 ARCH: Noswitch archival of thread 1, sequence 48 ARCH: End-Of-Redo Branch archival of thread 1 sequence 48 ARCH: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2 ARCH: Standby redo logfile selected for thread 1 sequence 48 for destination LOG_ARCHIVE_DEST_2 Archived Log entry 83 added for thread 1 sequence 48 ID 0x664ffa3a dest 1: ARCH: Archiving is disabled due to current logfile archival Primary will check for some target standby to have received alls redo Final check for a synchronized target standby. Check will be made once. LOG_ARCHIVE_DEST_2 is a potential Physical Standby switchover target Active, synchronized target has been identified Target has also received all redo Backup controlfile written to trace file /p01/app/oracle/diag/rdbms/dgp/dgp/trace/dgp_ora_2796.trc Clearing standby activation ID 1716517434 (0x664ffa3a) The primary database controlfile was created using the 'MAXLOGFILES 16' clause. There is space for up to 13 standby redo logfiles Use the following SQL commands on the standby database to create standby redo logfiles that match the primary database: ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800; Archivelog for thread 1 sequence 48 required for standby recovery Switchover: Primary controlfile converted to standby controlfile succesfully. Switchover: Complete - Database shutdown required USER (ospid: 2796): terminating the instance Instance terminated by USER, pid = 2796 Completed: alter database commit to switchover to physical standby with session shutdown Shutting down instance (abort) License high water mark = 5 Thu Apr 21 05:24:28 2016 Instance shutdown complete
对应备库alert日志：
Thu Apr 21 05:24:24 2016 RFS[3]: Possible network disconnect with primary database Thu Apr 21 05:24:27 2016 RFS[4]: Assigned to RFS process 2841 RFS[4]: Selected log 5 for thread 1 sequence 48 dbid 1716485690 branch 909194174 Thu Apr 21 05:24:27 2016 Archived Log entry 41 added for thread 1 sequence 48 ID 0x664ffa3a dest 1: Thu Apr 21 05:24:27 2016 RFS[1]: Possible network disconnect with primary database Thu Apr 21 05:24:27 2016 RFS[5]: Assigned to RFS process 2843 RFS[5]: Possible network disconnect with primary database Thu Apr 21 05:24:27 2016 RFS[2]: Possible network disconnect with primary database Thu Apr 21 05:24:28 2016 Media Recovery Log /s01/app/oracle/arch/1_48_909194174.dbf Identified End-Of-Redo (switchover) for thread 1 sequence 48 at SCN 0x0.110542 Resetting standby activation ID 1716517434 (0x664ffa3a) Media Recovery End-Of-Redo indicator encountered Media Recovery Continuing Media Recovery Waiting for thread 1 sequence 49
4.备库切换成主库
SQL> alter database commit to switchover to primary with session shutdown;
切换过程对应的alert日志：
Thu Apr 21 05:26:59 2016 ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN ALTER DATABASE SWITCHOVER TO PRIMARY (dgs) Maximum wait for role transition is 15 minutes. Switchover: Media recovery is still active Role Change: Canceling MRP - no more redo to apply Thu Apr 21 05:27:01 2016 MRP0: Background Media Recovery cancelled with status 16037 Errors in file /s01/app/oracle/diag/rdbms/dgs/dgs/trace/dgs_mrp0_2377.trc: ORA-16037: user requested cancel of managed recovery operation Recovery interrupted! MRP0: Background Media Recovery process shutdown (dgs) Role Change: Canceled MRP All dispatchers and shared servers shutdown CLOSE: killing server sessions. CLOSE: all sessions shutdown successfully. Thu Apr 21 05:27:02 2016 SMON: disabling cache recovery Backup controlfile written to trace file /s01/app/oracle/diag/rdbms/dgs/dgs/trace/dgs_ora_2755.trc SwitchOver after complete recovery through change 1115458 Online log /s01/app/oracle/oradata/dgs/redo01.log: Thread 1 Group 1 was previously cleared Online log /s01/app/oracle/oradata/dgs/redo02.log: Thread 1 Group 2 was previously cleared Online log /s01/app/oracle/oradata/dgs/redo03.log: Thread 1 Group 3 was previously cleared Standby became primary SCN: 1115456 AUDIT_TRAIL initialization parameter is changed back to its original value as specified in the parameter file. Switchover: Complete - Database mounted as primary Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN
5.打开新主库
SQL> alter database open;
对应alert日志：
Thu Apr 21 05:27:52 2016
idle dispatcher 'D000' terminated, pid = (17, 1)
Thu Apr 21 05:28:01 2016
ARC1: Becoming the 'no SRL' ARCH
Thu Apr 21 05:28:39 2016
alter database open
Thu Apr 21 05:28:39 2016
Assigning activation ID 1717040723 (0x6657f653)
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
Thread 1 advanced to log sequence 50 (thread open)
Thread 1 opened at log sequence 50
Current log# 2 seq# 50 mem# 0: /s01/app/oracle/oradata/dgs/redo02.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Thu Apr 21 05:28:39 2016
SMON: enabling cache recovery
Thu Apr 21 05:28:39 2016
***********************************************************************
Fatal NI connect error 12514, connecting to:
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dgp.example.com)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=dgp)(CID=(PROGRAM=oracle)(HOST=dgs.example.com)(USER=oracle))))
VERSION INFORMATION:
TNS for Linux: Version 11.2.0.4.0 - Production
TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
Time: 21-APR-2016 05:28:39
Tracing not turned on.
Tns error struct:
ns main err code: 12564
TNS-12564: TNS:connection refused
ns secondary err code: 0
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0
***********************************************************************
6.打开新的备库
SQL> shutdown immediate SQL> startup mount SQL> alter database recover managed standby database using current logfile disconnect;
7.新的主库查看
SQL> select open_mode,PROTECTION_MODE,PROTECTION_LEVEL, DATABASE_ROLE from v$database; OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE -------------------- -------------------- -------------------- ---------------- READ WRITE MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PRIMARY SQL>
8.新的备库查看
SQL> select open_mode,PROTECTION_MODE,PROTECTION_LEVEL, DATABASE_ROLE from v$database; OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE -------------------- -------------------- -------------------- ---------------- MOUNTED MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PHYSICAL STANDBY SQL>