第三篇物理standby之switchover 無損切換

一、switchover和failover

所謂switchover是針對failover而言的，它是一種無損切換，切換的過程中不會丟失資料。可以平滑的使主備互換並且2個庫都可以正常使用。

切換過程：主庫->切換->備庫->檢查狀態->原備庫->切換->主庫->再檢查狀態

應用場合：主庫需要調整升級，主庫效能不佳，這時可以切換後用新主庫對外提供服務

是否丟失資料：不會丟失資料

所謂failover，它是一種丟棄切換，直接把備庫切換成主庫，原主庫自動丟棄，也就是不在屬於DG架構的一部分了。

切換過程：備庫->切換->主庫->檢查狀態，原主庫脫離DG架構

應用場合：當主庫發生嚴重故障不可逆轉的時候可以使用failover，例如我們熟悉紐約雙子塔911事件，如果你的主庫在那裡，呵呵那麼你就不要在猶豫了，failover是你最佳之選擇 come on

是否丟失資料：極有可能丟失資料，我們的目標就是損失降到最低

如果在failure之前是maximum protection or maximum availability模式，會丟失資料

挽救措施：重建主庫使用原來備份恢復主庫

Switchover Role Transition 之前準備工作（標準流程，一般自己建的庫最瞭解就可以skip）

1.檢查主備庫引數檔案

2.主備庫必須為歸檔模式

3.RAC模式下備庫只能有一個例項為open，其他例項全部為shutdown，經過角色轉換後，重新啟動這些例項open

V$DATAGUARD_STATS可以評估備庫角色切換後redo日誌應用時間，只有備庫有內容，主庫沒有

SYS@OEL> set lines 110

SYS@OEL> column name format a22

SYS@OEL> column value format a16

SYS@OEL> column unit format a28

SYS@OEL> column time_computed format a25

SYS@OEL> select * from v$dataguard_stats;

NAME VALUE UNIT TIME_COMPUTED

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

apply finish time +00 00:18:35.5 day(2) to second(1) interval 04-JUN-2012 17:59:03

apply lag +06 21:28:29 day(2) to second(0) interval 04-JUN-2012 17:59:03

estimated startup time 27 second 04-JUN-2012 17:59:03

standby has been open N 04-JUN-2012 17:59:03

transport lag +00 00:00:00 day(2) to second(0) interval 04-JUN-2012 17:59:03

欄位解釋：

（1）apply lag：該值表示在透過在備庫上應用主庫傳遞過來的重做日誌與出庫同步所延遲的時間。APPLY LAG: Amount of time that the application of redo data on the standby database lags behind the primary database。

（2）transport lag：該值表示在單位時間內主庫上產生的重做日誌還沒有傳輸到備庫上，或者主庫上產生的重做日誌還沒有被備庫所應用

（3）apply finish time：該值表示在備庫上完成應用重做日誌所需要的時間

（4）estimated startup time：該值表示啟動和開啟物理備庫所需要的時間，該欄位不是適用於邏輯備庫。 An estimate of the time needed to start and open the database

（5）VALUE：給出各個引數的值。如第1個查詢中的，apply finish time值為+00 00:00:00.1，說明該物理備庫需要0.1秒的時間來完成應用剩餘的重做日誌資料。

（6）UNIT：各個引數的時間單元。

（7）TIME_COMPUTED：物理備庫上估算各個引數的本地時間。

（8）DATUM_TIME：在物理備庫上獲取後設資料來估算 APPLY LAG 和 TRANSPORT LAG 這兩個引數值的本地時間。如果從多次查詢中看到該時間值對應的APPLY LAG 和 TRANSPORT LAG 這兩個引數值保持不變的話，那麼就說明該物理備庫已經停止從主庫接收到重做資料！該欄位是11g中新出現的

官方文件上，關於V$DATAGUARD_STATS是這樣描述的：該動態效能檢視顯示出在主庫上產生了多少重做日誌資料，但是還沒有被備庫所應用。所以，透過查詢該檢視可以基本確定如果萬一主庫出現崩潰的話，備庫上將丟失多少重做日誌資料。我們可以在一套環境下的任一備庫的例項上從該檢視裡獲取相關資訊，然而，在主庫的例項上查詢該檢視返回的資訊都將是空。也就是說，只可以從備庫的例項上查詢V$DATAGUARD_STATS，從主庫例項上是看不到任何有用資訊的。

二、實操switchover無損切換

1.我們在主庫建立一個表空間test1，看看是否在備庫應用了

SYS@LEO> create tablespace test1 datafile '/u01/app/oracle/oradata/LEO/file1/test01.dbf' size 20m;

Tablespace created.

SYS@LEO> select * from v$tablespace; 已經建立好了

TS# NAME INC BIG FLA ENC

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

0 SYSTEM YES NO YES

1 UNDOTBS YES NO YES

2 SYSAUX YES NO YES

3 TEMPTS1 NO NO YES

4 USERS YES NO YES

6 TEMP1 NO NO YES

7 TEMP2 NO NO YES

8 EXAMPLE YES YES YES

9 TEST1 YES NO YES

2.我們看看備庫有沒有生成test1表空間

SYS@OEL> select * from v$tablespace; 我們在OEL庫上沒有看見test1表空間

TS# NAME INC BIG FLA ENC

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

0 SYSTEM YES NO YES

1 UNDOTBS YES NO YES

2 SYSAUX YES NO YES

3 TEMPTS1 NO NO YES

4 USERS YES NO YES

6 TEMP1 NO NO YES

7 TEMP2 NO NO YES

8 EXAMPLE YES YES YES

8 rows selected.

3.我們進行一次日誌切換（LEO庫）

SYS@LEO> alter system switch logfile; 日誌切換後才把redo資料傳到OEL庫

System altered.

我們檢視一下OEL的alert_OEL.log

RFS[1]: Archived Log: '/home/oracle/arch/OEL/log1_12_784052660.arc'

RFS程式已經獲取到了12號歸檔日誌

Mon Jun 4 19:46:42 2012

Media Recovery Log /home/oracle/arch/OEL/log1_12_784052660.arc

我們說過，如果不是實時應用，備庫是從歸檔日誌中獲取恢復日誌的（如果是實時應用我們是從standby logfile中獲取恢復日誌的）

Mon Jun 4 19:47:16 2012

Recovery created file /u01/app/oracle/oradata/OEL/file1/test01.dbf

Successfully added datafile 6 to media recovery

恢復表空間test1成功

Datafile #6: '/u01/app/oracle/oradata/OEL/file1/test01.dbf'

Mon Jun 4 19:47:27 2012

Media Recovery Waiting for thread 1 sequence 13 (in transit)

介質恢復等待13號歸檔日誌

SYS@OEL> select * from v$tablespace; 此時test1表空間建立完畢

TS# NAME INC BIG FLA ENC

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

0 SYSTEM YES NO YES

1 UNDOTBS YES NO YES

2 SYSAUX YES NO YES

3 TEMPTS1 NO NO YES

4 USERS YES NO YES

6 TEMP1 NO NO YES

7 TEMP2 NO NO YES

8 EXAMPLE YES YES YES

9 TEST1 YES NO YES

上面我們做了一個同步資料的小實驗為了讓我們感性認識DG的強大

下面進行switchover切換

（1）主庫狀態

作用：檢查主庫切換的可能性，如果“TO STANDBY”值表示主庫可以順利切換到備庫

如果SWITCHOVER_STATUS=sessions active 表示當前仍然活動會話在進行，這是你可以新增“WITH SESSION SHUTDOWN”關鍵字在ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY語句之後進行強制關閉會話

SYS@LEO> select database_role,switchover_status,open_mode from v$database;

DATABASE_ROLE SWITCHOVER_STATUS OPEN_MODE

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

PRIMARY TO STANDBY READ WRIT

（2）LEO主庫->OEL備庫注意看alert_LEO.log 是否有報錯資訊以便定位問題

SYS@LEO> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

Database altered.

這是alert_LEO.log日誌顯示的資訊

Resetting standby activation ID 1558334580 (0x5ce24c74)

Mon Jun 4 20:16:30 2012

MRP0: Background Media Recovery process shutdown (LEO) MRP程式關閉

Mon Jun 4 20:16:30 2012

Switchover: Complete - Database shutdown required (LEO) 現在資料庫（資料檔案）為shutdown狀態

Mon Jun 4 20:16:30 2012

Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN

SYS@LEO> select status from v$instance; 當前雖顯示例項為開啟狀，但此時資料庫為一個未知狀態

STATUS

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

STARTED

注：在switchover之前有一個自動備庫控制檔案的動作，以便以後重建之用

（3）重啟LEO庫

SYS@LEO> shutdown immediate

ORACLE instance shut down.

SYS@LEO> startup mount

ORACLE instance started.

Database mounted.

（4）檢查OEL庫狀態

SYS@OEL> select database_role,switchover_status,open_mode from v$database;

DATABASE_ROLE SWITCHOVER_STATUS OPEN_MODE

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

PHYSICAL STANDBY TO PRIMARY MOUNTED

如果SWITCHOVER_STATUS= TO PRIMARY備庫可以順利切換到主庫

如果SWITCHOVER_STATUS=sessions active 表示當前仍然活動會話在進行，這是你可以新增“WITH SESSION SHUTDOWN”關鍵字在ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY語句之後進行強制關閉會話，如果不加alert_LEO.log裡有If media recovery active, switchover will wait 900 seconds

你需要等待900秒的時間，這只是一個估計值，實際上時間會更長

（5）OEL備庫->LEO主庫注意看alert_OEL.log 是否有報錯資訊以便定位問題

SYS@OEL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

SwitchOver after complete recovery through change 169677

Online log /u01/app/oracle/oradata/OEL/file1/redo01.log: Thread 1 Group 1 was previously cleared

Online log /u01/app/oracle/oradata/OEL/file2/redo1_2.log: Thread 1 Group 1 was previously cleared

Online log /u01/app/oracle/oradata/OEL/file1/redo02.log: Thread 1 Group 2 was previously cleared

Online log /u01/app/oracle/oradata/OEL/file2/redo2_2.log: Thread 1 Group 2 was previously cleared

Online log /u01/app/oracle/oradata/OEL/file1/redo03.log: Thread 1 Group 3 was previously cleared

Online log /u01/app/oracle/oradata/OEL/file2/redo3_2.log: Thread 1 Group 3 was previously cleared

切換成主庫之後要使用redo logfile

Standby became primary SCN: 169675

備庫生成主庫

Converting standby mount to primary mount.

轉換備庫mount狀態->主庫mount狀態

Mon Jun 4 20:49:35 2012

Switchover: Complete - Database mounted as primary (OEL)

Mon Jun 4 20:49:35 2012

ARC0: STARTING ARCH PROCESSES

啟動歸檔程式

Mon Jun 4 20:49:35 2012

Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY

Mon Jun 4 20:49:35 2012

（6）OEL完成無損切換並開啟

SYS@OEL> alter database open; 如果當初是mount狀態，我們可以直接開啟

Database altered.

SYS@OEL> SHUTDOWN IMMEDIATE; 如果當初是open狀態，你就必須shutdown之後在startup

SYS@OEL> STARTUP;

注：如果你有多個備庫，沒有必要關閉->重啟其他備庫，這些備庫在switchover之後會繼續正常執行

（7）檢查新主備庫日誌是否同步

SYS@OEL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# APP

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

16 NO

SYS@LEO> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# APP

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

16 NO

已經同步，但LEO還沒有應用日誌，現在設定LEO庫開始應用日誌

（8）設定LEO庫開始應用日誌

SYS@LEO> alter database recover managed standby database disconnect from session parallel 2;

Database altered.

我們使用2個MRP程式恢復日誌，檢視alert_LEO.log日誌

alter database recover managed standby database disconnect from session parallel 2

Mon Jun 4 21:24:14 2012

Attempt to start background Managed Standby Recovery process (LEO)

嘗試啟動介質恢復程式MRP

MRP0 started with pid=18, OS id=4046

Mon Jun 4 21:24:14 2012

MRP0: Background Managed Standby Recovery process started (LEO)

介質恢復程式MRP已經啟動

Managed Standby Recovery not using Real Time Apply

沒有使用實時應用，我們從歸檔日誌中獲取恢復日誌

parallel recovery started with 2 processes

啟動2個MRP程式

Mon Jun 4 21:24:21 2012

Completed: alter database recover managed standby database disconnect from session parallel 2

Mon Jun 4 21:24:22 2012

Clearing online redo logfile 1 /u01/app/oracle/oradata/LEO/file1/redo01.log

Clearing online log 1 of thread 1 sequence number 17 這是redo日誌對應歸檔日誌序號

開始清空所有redo日誌，騰出空間便於重新使用，

小結：到此我們進行了一次完美的Switchover無損切換，大家都應該能看的明白吧，我把前後臺所有內部變化都一一詳細解析出來，再次強調一下所謂的無損就是要保持2邊的日誌必須有效同步，這樣才能not data loss。下集請看 -> 第四篇物理standby之failover 丟失切換

PS:ITPUB2012年的第二季度“技術新星”提名為候選人11http://www.itpub.net/thread-1615587-1-1.html

希望大家多多支援

候選人參選感言：

這是我職業生涯中第一個論壇榮譽，在這裡得到了大家的支援與鼓勵，不管結果如何，能夠得到大家的認可是我最大的動力，我會繼續努力，不辜負大家的期望！我會繼續不斷學習，不斷的分享！

寄語：理論與實踐需要互動進行，每一點汗水都是成功的階梯，心有多大舞臺就有多大，與大家共勉！

座右銘：分享技術收穫快樂

Leonarding

2012.6.04

於天津&summer

Blog：http://space.itpub.net/26686207

盛哥學習 Data Guard 第三篇《物理standby之switchover 無損切換》

相關文章