在Data Guard環境中，Standby Redo Log是一個比較特殊的日誌型別。從最新的DG安裝指導中，都推薦在Primary和Standby端，都配置Standby Redo Log。

簡單的說，Standby Redo Log就是在Standby端應用傳遞Redo Log過程中，逐步執行的online redo log。Standby端雖然也有online redo log，但是在redo apply應用的過程中，是不使用online redo log的。即使是11g Active Data Guard支援apply中讀取standby資料，這個操作也是read-only的，並不涉及當前例項redo log的生成（注意是生成）。所以，如果一直是在Standby角色，online redo log是不需要的。

Primary傳遞過來的redo log資訊，是存放在standby redo log組內進行apply的。並且隨著主庫Primary日誌的切換動作而切換。這也就是為什麼推薦standby redo log的大小和Primary online redo log的大小保持一致的原因。

下面會從維護角度，討論Standby Redo log維護過程中的方法。

1、環境介紹

資料庫版本為11.2.0.4，已經構建好DG環境。Primary資料庫例項名ora11g。

SQL> select name, DATABASE_ROLE from v$database;

NAME DATABASE_ROLE

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

ORA11G PRIMARY

Primary上也是需要配置standby redo log的。但是，這個redo log和Standby端的online redo log一樣，都是在角色switch/failover之後，才會發揮作用。

SQL> col dbid for a20;

SQL> select group#, dbid, sequence#, archived, status from v$standby_log;

GROUP# DBID SEQUENCE# ARCHIVED STATUS

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

4 UNASSIGNED 0 YES UNASSIGNED

5 UNASSIGNED 0 YES UNASSIGNED

6 UNASSIGNED 0 YES UNASSIGNED

檔案自動管理引數設定為Auto。

SQL> show parameter standby_file

NAME TYPE VALUE

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

standby_file_management string AUTO

2、Primary端Standby Redo Log配置

Primary角色下，Standby Redo Log是不使用的。原則上也沒有什麼特殊的用途。所以，我們檢視v$standby_log檢視時檢視到的Primary端狀態都是unsigned，也就是沒有使用。

在Primary正常Read Write狀態下，我們是可以新增standby log group的。

SQL> alter database add standby logfile group 8 size 100m;

Database altered

SQL> select group#, dbid, sequence#, archived, status from v$standby_log;

GROUP# DBID SEQUENCE# ARCHIVED STATUS

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

4 UNASSIGNED 0 YES UNASSIGNED

5 UNASSIGNED 0 YES UNASSIGNED

6 UNASSIGNED 0 YES UNASSIGNED

8 UNASSIGNED 0 YES UNASSIGNED

在v$logfile中，可以看到對應的新增檔案。由於使用的OMF特性，建立成員組為兩個，在recovery area中有對應映象。

SQL> select group#, type, member from v$logfile;

GROUP# TYPE MEMBER

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

（篇幅原因，有省略……）

7 ONLINE /u01/app/fast_recovery_area/ORA11G/onlinelog/o1_mf_7_9pclt1lt_.log

8 STANDBY /u01/app/oradata/ORA11G/onlinelog/o1_mf_8_9pgqt9hg_.log

8 STANDBY /u01/app/fast_recovery_area/ORA11G/onlinelog/o1_mf_8_9pgqtcgj_.log

16 rows selected

在standby端，我們檢視是否有對應standby redo log自動新增。

SQL> select group#, sequence#, dbid,status from v$standby_log;

GROUP# SEQUENCE# DBID STATUS

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

4 34 4239941846 ACTIVE

5 0 UNASSIGNED UNASSIGNED

6 0 UNASSIGNED UNASSIGNED

Primary端刪除standby redo log。

SQL> alter database drop standby logfile group 8;

Database altered

SQL> select group#, dbid, sequence#, archived, status from v$standby_log;

GROUP# DBID SEQUENCE# ARCHIVED STATUS

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

4 UNASSIGNED 0 YES UNASSIGNED

5 UNASSIGNED 0 YES UNASSIGNED

6 UNASSIGNED 0 YES UNASSIGNED

從實驗情況看：在Primary端，我們進行standby redo log的管理是比較方便的。沒有過多的限制。

3、Standby端Standby Redo Log維護

當前Primary端的Online Redo Log情況。

SQL> select group#, sequence#, bytes, status from v$log;

GROUP# SEQUENCE# BYTES STATUS

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

1 32 104857600 INACTIVE

2 34 52428800 INACTIVE

3 35 52428800 CURRENT

7 33 10485760 INACTIVE

此時，standby端的standby redo log情況如下：

SQL> select group#, sequence#, dbid,status from v$standby_log;

GROUP# SEQUENCE# DBID STATUS

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

4 35 4239941846 ACTIVE

5 0 UNASSIGNED UNASSIGNED

6 0 UNASSIGNED UNASSIGNED

standby redo log對應的是當前Primary的online current redo log。反映在sequence#相同。我們嘗試直接新增standby日誌。

SQL> alter database add standby logfile group 8 size 100m;

alter database add standby logfile group 8 size 100m

ORA-01156: 進行中的恢復或閃回可能需要訪問檔案

當前standby處在apply過程，終止apply動作。

SQL> alter database recover managed standby database cancel;

Database altered

SQL> alter database add standby logfile group 8 size 100m;

Database altered

standby redo log日誌情況。

SQL> select group#, dbid, sequence#, archived, status from v$standby_log;

GROUP# DBID SEQUENCE# ARCHIVED STATUS

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

4 4239941846 35 YES ACTIVE

5 UNASSIGNED 0 NO UNASSIGNED

6 UNASSIGNED 0 NO UNASSIGNED

8 UNASSIGNED 0 YES UNASSIGNED

之後可以啟動redo apply過程。

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered

刪除redo log的方法也比較簡單，都是首先終止redo apply過程，之後刪除。

SQL> alter database recover managed standby database cancel;

Database altered

SQL> alter database drop standby logfile group 8;

Database altered

SQL> select group#, dbid, sequence#, archived, status from v$standby_log;

GROUP# DBID SEQUENCE# ARCHIVED STATUS

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

4 4239941846 35 YES ACTIVE

5 UNASSIGNED 0 NO UNASSIGNED

6 UNASSIGNED 0 NO UNASSIGNED

注意：這裡面我們處理的是非active狀態日誌。如果是active狀態，可能就需要與online redo log的策略相同，進行重建過程。

4、standby redo log usage實驗

這裡考慮一個問題。在primary和standby工作過程中，redo log entry從Primary的online redo log中傳遞，傳遞到standby端的standby redo log等待進行redo apply。

如果apply之後，redo log就進入歸檔狀態了。那麼，如果當前日誌積壓很多，甚至primary端多次進行切換。那麼這些日誌在哪兒呢？我們透過實驗去證明。

在primary端，當前日誌編號為38。

（primary）

SQL> select group#, sequence#, archived, status from v$log;

GROUP# SEQUENCE# ARCHIVED STATUS

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

1 36 YES INACTIVE

2 38 NO CURRENT

3 35 YES INACTIVE

7 37 YES INACTIVE

前一個sequence#的編號日誌已經傳遞到standby端。

SQL> select recid, name, sequence#, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log where sequence#=37;

RECID NAME SEQUENCE# STANDBY_DEST ARCHIVED APPLIED

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

53 /u01/app/fast_recovery_area/ORA11G/archivelog/2014_05_06/o1_mf_1_37_9pjrr6jg_.ar 37 NO YES NO

54 ora11gsy 37 YES YES NO

注意：57號記錄apply狀態為NO。standby端，standby redo log的current為38，與Primary相匹配。

SQL> col dbid for a20;

SQL> select group#, dbid, sequence#, archived, status from v$standby_log;

GROUP# DBID SEQUENCE# ARCHIVED STATUS

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

4 4239941846 38 YES ACTIVE

5 UNASSIGNED 0 NO UNASSIGNED

6 UNASSIGNED 0 NO UNASSIGNED

同樣的37號日誌已經在歸檔空間。

SQL> select recid, name, sequence#, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log where sequence#=37;

RECID NAME SEQUENCE# STANDBY_DEST ARCHIVED APPLIED

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

11 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_05_06/o1_mf_1_37_9pjrr6y0_. 37 NO YES NO

在Primary端進行多次的switch動作。

SQL> alter system switch logfile;

System altered

（多次切換，篇幅原因，有省略……）

SQL> alter system switch logfile;

System altered

Primary日誌情況如下，當前sequence為43。

SQL> select group#, sequence#, archived, status from v$log;

GROUP# SEQUENCE# ARCHIVED STATUS

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

1 40 YES INACTIVE

2 42 YES INACTIVE

3 43 NO CURRENT

7 41 YES INACTIVE

當前為43，進入歸檔空間。

SQL> select recid, name, sequence#, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log where sequence#>=37;

RECID NAME SEQUENCE# STANDBY_DEST ARCHIVED APPLIED

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

（篇幅原因，有省略……）

60 ora11gsy 40 YES YES NO

61 /u01/app/fast_recovery_area/ORA11G/archivelog/2014_05_06/o1_mf_1_41_9pjs7os5_.ar 41 NO YES NO

62 ora11gsy 41 YES YES NO

63 /u01/app/fast_recovery_area/ORA11G/archivelog/2014_05_06/o1_mf_1_42_9pjs7pvn_.ar 42 NO YES NO

64 ora11gsy 42 YES YES NO

12 rows selected

在standby端，standby redo log的切換到sequence#=43。

SQL> select group#, dbid, sequence#, archived, status from v$standby_log;

GROUP# DBID SEQUENCE# ARCHIVED STATUS

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

4 4239941846 43 YES ACTIVE

5 UNASSIGNED 0 NO UNASSIGNED

6 UNASSIGNED 0 NO UNASSIGNED

沒有被應用的日誌，並沒有積壓在standby redo log中。而是進入archive空間。

SQL> select recid, name, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log where sequence#>=37;

RECID SEQUENCE# STANDBY_DEST ARCHIVED APPLIED

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

11 37 NO YES NO

12 38 NO YES NO

13 39 NO YES NO

14 40 NO YES NO

15 41 NO YES NO

16 42 NO YES NO

6 rows selected

注意，他們的apply狀態都是NO。啟動standby端的應用之後，檢視效果。

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered

SQL> select recid, sequence#, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log where sequence#>=37;

RECID SEQUENCE# STANDBY_DEST ARCHIVED APPLIED

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

11 37 NO YES YES

12 38 NO YES YES

13 39 NO YES YES

14 40 NO YES YES

15 41 NO YES YES

16 42 NO YES IN-MEMORY

6 rows selected

5、結論

對standby而言，standby redo log就是online redo log。Oracle推薦standby redo log大小要與Primary上redo log size相匹配的。

Oracle Dataguard Standby Redo Log的兩個實驗

相關文章