http://blog.itpub.net/17203031/viewspace-1821550/

Data Guard是Oracle高可用性HA的重要解決方案。針對不同的系統保護需求，DG提供了三種不同型別的保護模式（Protection Mode），分別為：最大保護（Maximum Protection）、最大可用（Maximum Availability）和最大效能（Maximum performance）。在實際應用場景下，我們需要根據不同的業務場景和資料可用性需求，來設定DG環境的保護型別。

1、三種保護模式Protection Mode

三種保護模式是DG的核心概念。

在DG環境中，無論採用何種初始化方法，都是確保一個Primary和Standby的初始化資料一致，之後Primary一端接收的事務型別操作，均會以歸檔日誌串列的方式傳遞到Standby端的standby redo log

Primary和Standby是相互為備份的冗餘結構，Standby跟隨Primary的情況，反映了HA結構的可用性級別。理論上，最保險的策略是一個事務要保證在Primary和Standby上都提交了，才返回給使用者說已經完成。這樣是可以保證主備庫完全一致的最保險做法。另一個極端情況，就是主庫“自顧自”進行事務處理，獨立將日誌進行傳輸，也不用管日誌是否傳輸到或者應用到。

針對不同的傳輸情況，DG區分為三種保護型別：

ü最大可用模式Maximum Availability

在官方文件中，對這種模式的描述如下：

“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.”

Maximum Availability模式下，事務只有在所有相關日誌都被傳輸到至少一個Standby端日誌的時候，才可以正式提交。但是，如果Primary在傳輸日誌的過程中，發現所有standby端都不能進行傳輸，模式會退化到最大效能模式（Maximum Performance）工作方式。應該說，Maximum Availability是一種自適應的保護模式，當出現問題的時候，DG會退而求其次，確保Primary主庫事務進行。

ü最大效能模式（Maximum Performance）

官方文件中介紹如下：“This protection mode provides the highest level of data protection that is possible without affecting the performance of a primary database. This is accomplished by allowing transactions to commit as soon as all redo data generated by those transactions has been written to the online log. Redo data is also written to one or more standby databases, but this is done asynchronously with respect to transaction commitment, so primary database performance is unaffected by delays in writing redo data to the standby database(s).

This protection mode offers slightly less data protection than maximum availability mode and has minimal impact on primary database performance.

This is the default protection mode.”

最大效能模式是在不影響主庫工作情況下，可以提供的最高資料保護級別。當事務進行提交的時候，主庫不會去確認日誌是否寫入到備庫中，更不會確認是否被apply。這種方式下，主庫的工作效能是不會收到備庫提交應用的影響的。當然，這種保護模式會有一定的事務資料丟失，但是絕對不會出現資料誤提交的情況。

對DG而言，最大效能模式是預設的保護模式。當我們完成了DG安裝之後，就自動進入了Maximum Performance模式。

ü最大保護模式（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.

Transactions on the primary are considered protected as soon as Data Guard has written the redo data to persistent storage in a standby redo log file. Once that is done, acknowledgment is quickly made back to the primary database so that it can proceed to the next transaction. This minimizes the impact of synchronous transport on primary database throughput and response time. To fully benefit from complete Data Guard validation at the standby database, be sure to operate in real-time apply mode so that redo changes are applied to the standby database as fast as they are received. Data Guard signals any corruptions that are detected so that immediate corrective action can be taken.”

最大保護模式是完全HA架構理想中的事務模式。如果Primary資料庫進行一個事務，連帶Standby資料庫也要同步進行操作。如果由於網路、執行模式等原因，Standby不能夠跟上主庫的操作，那麼主庫會放棄事務，並且強制停庫。

保護模式的三種和資料庫之間傳輸日誌的機制是密切相關的。主要體現是否同步傳輸Redo日誌和對日誌進行確認兩個方面。我們配置三種日誌模式，一定要以Log_Archive_Config引數配置為基礎。

下面通過一系列的測試，來分析三種保護模式的工作行為方式。

2、環境介紹

筆者使用環境為Oracle 11gR2，具體版本為11.2.0.4。主備庫環境已經搭建完成，同步保護模式是採用預設方式。

主庫資訊：

SQL> select name, open_mode, database_role, protection_mode from v$database;

NAMEOPEN_MODEDATABASE_ROLEPROTECTION_MODE

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

VLIFEREAD WRITEPRIMARYMAXIMUM PERFORMANCE

SQL> select instance_name from v$instance;

INSTANCE_NAME

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

vlife

主庫與備庫連線方式，採用預設的非同步非確認方式。

SQL> select dest_id, dest_name, TRANSMIT_MODE, ASYNC_BLOCKS, AFFIRM TYPE, VALID_NOW, VALID_TYPE, VALID_ROLE, DB_UNIQUE_NAME from v$archive_dest where status<>'INACTIVE';

DEST_ID DEST_NAMETRANSMIT_MODE ASYNC_BLOCKS TYPE VALID_NOWVALID_TYPEVALID_ROLEDB_UNIQUE_NAME

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

1 LOG_ARCHIVE_DEST_1SYNCHRONOUS0 NOYESALL_LOGFILESALL_ROLESNONE

2 LOG_ARCHIVE_DEST_2ASYNCHRONOUS61440 NOYESONLINE_LOGFILEPRIMARY_ROLE vlifesb

此時，傳輸通道配置。

SQL> show parameter LOG_ARCHIVE_DEST_2;

NAMETYPEVALUE

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

log_archive_dest_2stringSERVICE=vlifesb valid_for=(online_logfiles,primary_role) db_unique_name=vlifesb

log_archive_dest_20string

log_archive_dest_21string

備庫資訊如下：

SQL> select name, open_mode, database_role, protection_mode from v$database;

NAMEOPEN_MODEDATABASE_ROLEPROTECTION_MODE

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

VLIFEREAD ONLY WITH APPLY PHYSICAL STANDBY MAXIMUM PERFORMANCE

SQL> select instance_name from v$instance;

INSTANCE_NAME

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

vlifesb

SQL> col dest_name for a20;

SQL> select dest_id, dest_name, TRANSMIT_MODE, ASYNC_BLOCKS, AFFIRM TYPE, VALID_NOW, VALID_TYPE, VALID_ROLE, DB_UNIQUE_NAME from v$archive_dest where status<>'INACTIVE';

DEST_ID DEST_NAMETRANSMIT_MODE ASYNC_BLOCKS TYPE VALID_NOWVALID_TYPEVALID_ROLEDB_UNIQUE_NAME

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

1 LOG_ARCHIVE_DEST_1SYNCHRONOUS0 NOYESALL_LOGFILESALL_ROLESNONE

2 LOG_ARCHIVE_DEST_2ASYNCHRONOUS61440 NOWRONG VALID_TYPE ONLINE_LOGFILEPRIMARY_ROLE vlife

32 STANDBY_ARCHIVE_DEST SYNCHRONOUS0 NOYESALL_LOGFILESALL_ROLESNONE

SQL> show parameter LOG_ARCHIVE_DEST_2;

NAMETYPEVALUE

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

log_archive_dest_2stringSERVICE=vlife valid_for=(online_logfiles,primary_role) db_unique_name=vlife

log_archive_dest_20string

log_archive_dest_21string

3、最大可用模式Maximum Availability Mode測試

當前從預設的最大效能切換到最大可用模式，首先需要滿足將日誌傳輸模式進行修改。

SQL> alter system set log_archive_dest_2='SERVICE=vlifesb sync affirm net_timeout=30 valid_for=(online_logfiles,primary_role) db_unique_name=vlifesb';

System altered

SQL> select dest_id, dest_name, TRANSMIT_MODE, ASYNC_BLOCKS, AFFIRM TYPE, VALID_NOW, VALID_TYPE, VALID_ROLE, DB_UNIQUE_NAME, NET_TIMEOUT from v$archive_dest where status<>'INACTIVE';

DEST_ID DEST_NAMETRANSMIT_MODE ASYNC_BLOCKS TYPE VALID_NOWVALID_TYPEVALID_ROLEDB_UNIQUE_NAMENET_TIMEOUT

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

1 LOG_ARCHIVE_DEST_1SYNCHRONOUS0 NOYESALL_LOGFILESALL_ROLESNONE0

2 LOG_ARCHIVE_DEST_2PARALLELSYNC0 YESYESONLINE_LOGFILEPRIMARY_ROLE vlifesb30

此時，將保護模式使用alter database進行設定。

SQL> alter database set standby database to maximize availability;

Database altered

SQL> select name, open_mode, database_role, protection_mode from v$database;

NAMEOPEN_MODEDATABASE_ROLEPROTECTION_MODE

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

VLIFEREAD WRITEPRIMARYMAXIMUM AVAILABILITY

在切換動作的時候，主庫日誌情況如下：

Wed Oct 21 15:13:48 2015

alter database set standby database to maximize availability

Completed: alter database set standby database to maximize availability

Wed Oct 21 15:13:49 2015

Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED –發現沒有同步，需要補充。

******************************************************************

LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2

******************************************************************

Wed Oct 21 15:13:49 2015

NSS2 started with pid=34, OS id=9186

LGWR: Standby redo logfile selected to archive thread 1 sequence 82

LGWR: Standby redo logfile selected for thread 1 sequence 82 for destination LOG_ARCHIVE_DEST_2

Thread 1 advanced to log sequence 82 (LGWR switch)

Current log# 3 seq# 82 mem# 0: /u01/app/oracle/oradata/VLIFE/onlinelog/o1_mf_3_c1kb1c24_.log

Current log# 3 seq# 82 mem# 1: /u01/app/oracle/fast_recovery_area/VLIFE/onlinelog/o1_mf_3_c1kb1c43_.log

Wed Oct 21 15:13:53 2015

Archived Log entry 104 added for thread 1 sequence 81 ID 0xfad4f44b dest 1:

Wed Oct 21 15:13:54 2015

ARC3: Archive log rejected (thread 1 sequence 81) at host 'vlifesb'

FAL[server, ARC3]: FAL archive failed, see trace file.

ARCH: FAL archive failed. Archiver continuing

ORACLE Instance vlife - Archival Error. Archiver continuing.

Wed Oct 21 15:14:42 2015

Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED

LGWR: Standby redo logfile selected to archive thread 1 sequence 83

LGWR: Standby redo logfile selected for thread 1 sequence 83 for destination LOG_ARCHIVE_DEST_2

Thread 1 advanced to log sequence 83 (LGWR switch)

Current log# 1 seq# 83 mem# 0: /u01/app/oracle/oradata/VLIFE/onlinelog/o1_mf_1_c1kb19q4_.log

Current log# 1 seq# 83 mem# 1: /u01/app/oracle/fast_recovery_area/VLIFE/onlinelog/o1_mf_1_c1kb19sb_.log

Wed Oct 21 15:14:42 2015

Archived Log entry 107 added for thread 1 sequence 82 ID 0xfad4f44b dest 1:

在Primary端，在進行切換之後，Oracle發現傳輸狀態不是同步情況。於是自動加快進行日誌傳輸和同步動作。在Standby端，也可以看到後續追趕動作。

SQL> select name, open_mode, database_role, protection_mode from v$database;

NAMEOPEN_MODEDATABASE_ROLEPROTECTION_MODE

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

VLIFEREAD ONLY WITH APPLY PHYSICAL STANDBY MAXIMUM AVAILABILITY

Standby端上的日誌追趕動作。

Wed Oct 21 08:27:05 2015

Primary database is in MAXIMUM PERFORMANCE mode

Re-archiving standby log 4 thread 1 sequence 80

Wed Oct 21 08:27:05 2015

Media Recovery Waiting for thread 1 sequence 81

RFS[14]: Assigned to RFS process 31500

RFS[14]: Selected log 5 for thread 1 sequence 81 dbid -87496857 branch 892734889

Wed Oct 21 08:27:05 2015

Archived Log entry 76 added for thread 1 sequence 80 ID 0xfad4f44b dest 1:

Recovery of Online Redo Log: Thread 1 Group 5 Seq 81 Reading mem 0

Mem# 0: /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_5_c265gqd8_.log

Mem# 1: /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_5_c265gqj0_.log

Wed Oct 21 15:13:52 2015

Primary database is in MAXIMUM AVAILABILITY mode

Changing standby controlfile to MAXIMUM AVAILABILITY mode

Changing standby controlfile to RESYNCHRONIZATION level

Standby controlfile consistent with primary

RFS[15]: Assigned to RFS process 969

RFS[15]: Selected log 4 for thread 1 sequence 82 dbid -87496857 branch 892734889

Wed Oct 21 15:13:53 2015

Archived Log entry 77 added for thread 1 sequence 81 ID 0xfad4f44b de