【DataGuard】不能沒有你，我的Standby ——Oracle DataGuard最大保護模式 故障實驗

不能沒有你，我的Standby

——Oracle DataGuard最大保護模式 故障實驗

Data Guard 提供三種資料保護模式：最大保護（Maximum Protection），最大可用（Maximum Availability）和 最大效能（Maximum Performance）。
最大保護（Maximum Protection）能夠確保絕無資料丟失。但要實現這一步當然是有代價的，它要求所有的事務在提交前其REDO不僅被寫入到本地的Online Redologs，還要同時寫入到Standby資料庫的Standby Redologs，並確認REDO資料至少在一個Standby資料庫中可用（如果有多個的話）， 然後才會在Primary資料庫上提交事物 。為了確保資料不丟失，如果出現故障導致主庫不能將redo日誌寫入至少一個物理備庫中時，主庫會被關閉。

【Oracle11g官方文件中關於Dataguard 最大保護模式的介紹】

Maximum Protection
This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover a transaction must be written to both the online redo log and to the standby redo log on at least one synchronized standby database before the transaction commits.To ensure that data loss cannot occur, the primary database will shut down, rather than continue processing transactions, if it cannot write its redo stream to at least one synchronized standby database.




【實驗環境】
Red Hat Enterprise Linux Server release 5.4
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0

【主庫、物理備庫結構資訊】





【實驗過程】

一、查詢當前主庫、物理備庫保護模式

主庫Pirmary 

select database_role,open_mode,protection_mode,protection_level from v$database;

物理備庫Physical Standby

select database_role,open_mode,protection_mode,protection_level from v$database;

二、模擬故障（ 網路故障導致主庫與備庫通訊中斷 或 物理備庫當機 ）

首先在最大保護模式下，嘗試停止主庫的遠端歸檔，是不允許修改的。
alter system set log_archive_dest_state_2=deffer;


因為當前實驗環境只有一個物理備庫，可以通過down掉物理備庫網路卡，來模擬主庫與物理備庫之間網路故障或物理備庫當機等情況。
關閉物理備庫網路卡： ifconfig eth0 down



三、監測主庫狀態

關閉物理備庫網路卡時，跟蹤主庫告警日誌。
tail -f /u01/app/oracle/diag/rdbms/beijing/BJ/trace/alert_BJ.log 
告警日誌中開始有報錯資訊

1. Thu Jul 17 12:11:04 2014
   
2. ORA-16198: LGWR received timedout error from KSR
   
3. LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (16198)
   
4. ORA-16198: LGWR received timedout error from KSR
   
5. Thu Jul 17 12:11:14 2014
   
6. NSS2 started with pid=20, OS id=4477
   
7. Thu Jul 17 12:11:29 2014
   
8. 
   
9. 
   
10. ***********************************************************************
    
11. 
    
12. Fatal NI connect error 12543, connecting to:
    
13.  (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=shanghai.lxh.net)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=shanghai)(CID=(PROGRAM=oracle)(HOST=beijing.lxh.net)(USER=oracle))))
    
14. 
    
15.   VERSION INFORMATION:
    
16.         TNS for Linux: Version 11.2.0.3.0 - Production
    
17.         TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.3.0 - Production
    
18.   Time: 17-JUL-2014 12:11:29
    
19.   Tracing not turned on.
    
20.   Tns error struct:
    
21.     ns main err code: 12543
    
22.     
    
23. TNS-12543: TNS:destination host unreachable
    
24.     ns secondary err code: 12560
    
25.     nt main err code: 513
    
26.     
    
27. TNS-00513: Destination host unreachable
    
28.     nt secondary err code: 113
    
29.     nt OS err code: 0
    
30. 
    
31. 
    
32. ***********************************************************************

此時在主庫上模擬業務操作 會處於掛起狀態無發成功
create table scott.test2 as select * from scott.emp;
跟蹤日誌中不斷更新報錯資訊，主庫無法與物理備庫通訊，最終導致主庫被關閉。




主庫告警日誌顯示，所有Standby database不可達，需要關閉例項來保護主庫。

點選(此處)摺疊或開啟

1. Fatal NI connect error 12543, connecting to:
   
2.  (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=shanghai.lxh.net)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=shanghai)(CID=(PROGRAM=oracle)(HOST=beijing.lxh.net)(USER=oracle))))
   
3. 
   
4.   VERSION INFORMATION:
   
5.         TNS for Linux: Version 11.2.0.3.0 - Production
   
6.         TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.3.0 - Production
   
7.   Time: 17-JUL-2014 12:16:19
   
8.   Tracing not turned on.
   
9.   Tns error struct:
   
10.     ns main err code: 12543
    
11.     
    
12. TNS-12543: TNS:destination host unreachable
    
13.     ns secondary err code: 12560
    
14.     nt main err code: 513
    
15.     
    
16. TNS-00513: Destination host unreachable
    
17.     nt secondary err code: 113
    
18.     nt OS err code: 0
    
19. Error 12543 received logging on to the standby
    
20. Thu Jul 17 12:16:20 2014
    
21. LGWR: Error 12543 attaching to RFS for reconnect
    
22. Error 16198 for archive log file 1 to \'sh\'
    
23. Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
    
24. LGWR: All standby destinations have failed
    
25. ******************************************************
    
26. WARNING: All standby database destinations have failed
    
27. WARNING: Instance shutdown required to protect primary
    
28. ******************************************************
    
29. LGWR (ospid: 4337): terminating the instance due to error 16098
    
30. Thu Jul 17 12:16:20 2014
    
31. System state dump requested by (instance=1, osid=4337 (LGWR)), summary=[abnormal instance termination].
    
32. System State dumped to trace file /u01/app/oracle/diag/rdbms/beijing/BJ/trace/BJ_diag_4327.trc
    
33. Dumping diagnostic data in directory=[cdmp_20140717121620], requested by (instance=1, osid=4337 (LGWR)), summary=[abnormal instance termination].
    
34. Instance terminated by LGWR, pid = 4337

【實驗總結】
通過上述實驗模擬Oracle DataGuard在最大保護模式時，物理備庫當機或者網路故障導致所有物理備庫不可用的情況，可以看到備庫的不可達最終會導致主庫Shutdown。
因此最大保護模式可以絕對保證資料沒有丟失，但對主庫與備庫的網路連通情況、備庫的穩定性等也有非常高的要求。

Oracle 11g官方文件中，在對最大保護模式的描述中，也推薦至少使用兩個Standby database，來避免單個備庫故障導致主庫被關閉的情況。