Oracle9iR2 Data Guard的保護模式(ZT)

本文只涉及Oracle9iR2 Data Guard的physical standby

一、三種保護模式
最大效能(maximize performance):這是data guard預設的保護模式。primay上的事務commit前不需要從standby上收到反饋資訊，該模式在primary故障時可能丟失資料，但standby對primary的效能影響最小。
IXDBA.NET技術社群
最大可用(maximize availability):在正常情況下，最大可用模式和最大保護模式一樣；在standby不可用時，最大可用模式會自動降低成最大效能模式，所以standby故障不會導致primay不可用。只要至少有一個standby可用的情況下，即使primary down機，也能保證不丟失資料。
最大保護(maximize protection):最高階別的保護模式。primay上的事務在commit前必須確認redo已經傳遞到至少一個standby上，如果所有standby不可用，則primary會掛起。該模式能保證零資料丟失。

二、檢視當前保護模式
SQL> select DATABASE_ROLE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;

DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL
---------------- -------------------- --------------------
PRIMARY MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE

三、兩種日誌傳輸方式
Arch：傳統的日誌傳送方式。現在只有在最大效能模式時才能採用。歸檔日誌透過primary上的arch程式傳送給standby的RFS程式。
LGWr：oracle9i開始可以使用LGWR即時將日誌傳送到standby，而不再需要等到歸檔操作時才傳送，已減少可能的資料丟失。在三種保護模式下都可以使用該方式傳送日誌。使用LGWR方式傳送，在standby庫上必須先建立standby redo logfile

四、檢視日誌傳送方式
SQL> select dest_name,archiver from v$archive_dest;

DEST_NAME ARCHIVER
-------------------- ----------
LOG_ARCHIVE_DEST_1 ARCH
LOG_ARCHIVE_DEST_2 LGWR
LOG_ARCHIVE_DEST_3 ARCH
LOG_ARCHIVE_DEST_4 ARCH
LOG_ARCHIVE_DEST_5 ARCH
LOG_ARCHIVE_DEST_6 ARCH
LOG_ARCHIVE_DEST_7 ARCH
LOG_ARCHIVE_DEST_8 ARCH
LOG_ARCHIVE_DEST_9 ARCH
LOG_ARCHIVE_DEST_10 ARCH

10 rows selected.

五、新增standby redo logfile

首先停止standby的自動恢復狀態
SQL> alter database recover managed standby database finish;

Database altered.

如果沒有停止自動恢復狀態就新增standby logfile，會報錯：
ORA-01156: recovery in progress may need access to files

SQL> alter database add standby logfile group 4 ('d:/oracle/oradata/test/standby
04.redo') size 10m;

Database altered.

SQL> alter database add standby logfile group 5 ('d:/oracle/oradata/test/standby
05.redo') size 10m;

Database altered.

SQL> alter database add standby logfile group 6 ('d:/oracle/oradata/test/standby
06.redo') size 10m;

Database altered.

注意standby logfile的group名不能和primary的redo logfile group重複，因為我的primay已經有3組日誌了，這裡新增的三組standby logfile從group 4開始。同時standby redo logfile的大小和primary的redo logfile保持一致。

六、設定standby的歸檔路徑
log_archive_dest_1='location=/free/oracle/orabak '

standby_archive_dest='/free/oracle/orabak '

七、在primary上修改為用LGWR傳送日誌
SQL> alter system set log_archive_dest_2='service=standby lgwr async affirm';

System altered.

在primary上swith logfile
SQL> alter system switch logfile;

System altered.

在primary的alter中可以看到成功的記錄
Thu Nov 23 12:41:28 2006
ALTER SYSTEM SET log_archive_dest_2='service=standby lgwr async' SCOPE=BOTH;
Thu Nov 23 12:43:12 2006
***********************************************************

LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
***********************************************************
Creating archive destination LOG_ARCHIVE_DEST_2: 'standby'
LNS0 started with pid=13
Thu Nov 23 12:43:16 2006
LGWR: Beginning to archive log 3 thread 1 sequence 102
Thread 1 advanced to log sequence 102
Current log# 3 seq# 102 mem# 0: D:ORACLEORADATANINGREDO03.LOG
Thu Nov 23 12:43:16 2006
ARC0: Evaluating archive log 2 thread 1 sequence 101
ARC0: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2
ARC0: Beginning to archive log 2 thread 1 sequence 101
Creating archive destination LOG_ARCHIVE_DEST_2: 'standby'
Creating archive destination LOG_ARCHIVE_DEST_1: 'D:ORACLEARCHNINGARC00101.001'
ARC0: Completed archiving log 2 thread 1 sequence 101

八、切換standby的保護模式
切換保護模式的操作必須在primay執行，且primay必須處於mount狀態
IXDBA.NET社群論壇
如果在open狀態執行，則報錯：
ORA-01126: database must be mounted EXCLUSIVE and not open for this operation

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area 134814580 bytes
Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 143360 bytes
Database mounted.
SQL> alter database set standby database to maximize protection;

Database altered.

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel

注意，這時需要先修改日誌傳送方式為lgwr同步方式，否則，資料庫是無法open
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.

Total System Global Area 134814580 bytes
Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 143360 bytes
Database mounted.

SQL> alter system set log_archive_dest_2='service=standby lgwr sync' affirm;

System altered.

SQL> alter database open;

Database altered.

再來看看當前保護模式
SQL> select DATABASE_ROLE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;

DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL
---------------- -------------------- --------------------
PHYSICAL standby maximize protection maximize protection

切換成maximize availability也需要類似的步驟，不再演示。

注：在10gR2的data guard中，按照上述步驟切換保護模式的時候卻不成功。主庫完成切換語句後再open就報錯：ORA-03113: end-of-file on communication channel。看alert檔案，報錯ORA-16072: a minimum of one standby database destination is required。但實際上備庫的standby logfile都已經建好了，解決方法如下：

解決方法：

將主備庫的flashback開啟：
啟動到mount
SQL> select FLASHBACK_ON from v$database;
FLASHBACK_ON
------------------------------------
NO
SQL> alter database flashback on;
資料庫已更改。
       然後再切換到最大可用或者最大保護模式就ok了,切換前注意備庫已經處於mount狀態，並且主庫原有的歸檔日誌都已經全部複製到備庫對應的歸檔目錄下了，否則傳送方式由arch改成lgwr後這些差異日誌就無法自動傳過去了。

 

今天在做10gR2試驗，將主庫切換到maximize availability正常open，但是如果切換到Maximum protection就直接報錯ORA-03113: end-of-file on communication channel，檢查歸檔日誌主備庫都已經同步了，FLASHBACK_ON也已經是yes，但是就是不能open主資料庫。

IXDBA.NET社群論壇

後來檢視資料發現 Maximum protection模式必須滿足以下條件

Redo Archival Process: LGWR

Network Tranmission mode: SYNC

Disk Write Option: AFFIRM

Standby Redo Logs: Yes

standby database type: Physical Only

但是我的主庫引數設定為：

*.LOG_ARCHIVE_DEST_2= 'SERVICE=STANDBY VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=STANDBY LGWR SYNC REOPEN=10'
缺少了AFFIRM引數：增加後，如下

*.LOG_ARCHIVE_DEST_2= 'SERVICE=STANDBY VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=STANDBY LGWR SYNC AFFIRM REOPEN=10'

這樣，切換到Maximum protection就ok了。

在最大保護模式下，直接關閉備庫是不行的，如果在備庫上關閉資料庫，會有如下提示：
SQL> shutdown immediate
ORA-01154: database busy. Open, close, mount, and dismount not allowed now
SQL>
看來在最大保護模式下，備庫是不允許關閉的，此時首先關閉主庫，然後備庫就可以順利關閉了。