文章摘要：通過實驗模擬DataGuard在最高可用模式下，模擬故障導致主庫不能向物理備庫（Physical Standby）傳輸日誌時，主備庫情況。

【Oracle11g官方文件中關於Dataguard 最高可用模式的介紹】

This protection mode provides the highest level of data protection that is possible without compromising the availability of a primary database. Transactions do not commit until all redo data needed to recover those transactions has been written to the online redo log and to the standby redo log on at least one synchronized standby database. If the primary database cannot write its redo stream to at least one synchronized standby database, it operates as if it were in maximum performance mode to preserve primary database availability until it is again able to write its redo stream to a synchronized standby database.

This mode ensures that no data loss will occur if the primary database fails, but only if a second fault does not prevent a complete set of redo data from being sent from the primary database to at least one standby database.

【實驗環境】

作業系統：Red Hat Enterprise Linux Server release 5.4
資料庫：Oracle Database 11g Enterprise Edition Release 11.2.0.3.0

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

【實驗過程】

主庫 Primary database：綠色
物理備庫 Physical standby database:黃色

1、查詢主、備庫角色和狀態

2、模擬故障，主庫停止向遠端傳歸檔

alter system set log_archive_dest_state_2=defer;

show parameter log_archive_dest_stat_2

 

 
3、檢視狀態和當前保護級別

主庫檢視發現，protection_mode仍然是最高可用模式，但當前protection_level顯示resynchronization
即保護模式的目標沒變，當前狀態變了，需要同步。此時相當於 【最大效能模式】
select database_role,protection_mode,protection_level from v$database;

 

4、主庫建立測試表，插入資料並提交

 

5、主、備庫檢視日誌，備庫一直在等待

 

6、主庫開啟遠端歸檔

主庫開啟遠端歸檔，檢視保護模式，protection_level已經變成 maximum availability 最高可用模式

alter system set log_archive_dest_stat_2=enable; 
select database_role,protection_mode,protection_level from v$database;

7、檢視跟蹤日誌、測試表

主庫已經開始將日誌傳向備庫，   FAL 挖 日誌代溝

備庫檢視測試表，已經可以查到

【實驗總結】

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29475508/viewspace-1256939/，如需轉載，請註明出處，否則將追究法律責任。