Oracle Data Guard延遲的原因(r11筆記第69天)
Oracle Data Guard中很可能出現延遲的情況，而資料一旦出現延遲就意味著丟資料。退一步來說丟資料總比資料亂了好，但是回過頭來，能不丟資料但是丟了，這就有些說不過去了。
因為預防人為誤操作等，可能有些環境中會特意設定一個延遲，基本就是下面的設定方法：
方法1：
alter database recover managed standby database delay 120 disconnect from session;方法2：
alter system set log_archive_dest_3='service=db3 lgwr async delay=120 valid_for=(all_logfiles,all_roles)
db_unique_name=db3'; 我們這裡所說的延遲是計劃外的延遲，比如一個ADG的環境，案例應該是實時同步，但是卻有資料同步出現延遲的情況。我自己碰到一些，還幫網友處理過幾次。
大體來說，10g和11g中的資料同步延遲場景還不大一樣。
在10g中如果一主兩備的架構下，如果備1是在read only狀態，則整個資料同步還是會延遲，需要手工切換日誌才能增量同步。
在11g中，倒不存在這樣的限制了，因為是Active Data Guard的方式，所以可以在read only的基礎上接收應用增量資料變化。但是延遲的問題依舊可能存在。
我一個例子來說明,簡單來說，如何判斷一個Data Guard是Active Data Guard呢，可以用一個SQL語句來判定。
10:27:21 SQL>select current_scn from v$database;
CURRENT_SCN
232913508003
10:27:22 SQL> /
CURRENT_SCN
232913508005隨著時間的變化，SCN會發生變化，這和10g是一個鮮明的對比。
而如果Data Guard環境出現延遲，如果通過DG Broker來檢視，基本就是下面的顯示情況。
DGMGRL> show database verbose sol;
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 3 minutes 37 seconds
Apply Lag: 3 minutes 37 seconds
Real Time Query: ON 同時在備庫的alert日誌中檢視卻似乎看不出什麼特別之處。我碰到一個環境，資料延遲時好時壞，很不穩定，聽起來很棘手，我們來簡單看看。
日誌如下：
RFS[1]: Opened log for thread 1 sequence 476185 dbid 1210367666 branch 622336050
Wed Feb 08 11:55:23 2017
Media Recovery Log /U01/app/oracle/oradata/sol/arch/SOL/archivelog/2017_02_08/o1_mf_1_476184_d9o2rzdc_.arc
Media Recovery Waiting for thread 1 sequence 476185 (in transit) 出現這種情況，基本可以斷定是差一個歸檔。
我們看看主備庫的日誌檔案的情況。 檢視備庫的standby log情況：
SQL> select group#,bytes from v$standby_log;
GROUP# BYTES
---------- ----------
21 524288000
22 524288000
。。。
主庫的online log情況：
SQL> select group#,bytes,status from v$log
GROUP# BYTES STATUS
---------- ---------- ----------------
1 209715200 INACTIVE
2 209715200 INACTIVE
3 209715200 INACTIVE
4 209715200 INACTIVE
5 209715200 INACTIVE
6 209715200 INACTIVE
7 524288000 INACTIVE
8 629145600 INACTIVE
9 1073741824 CURRENT
10 1073741824 INACTIVE 如果到了這裡，想必就會清晰很多了，主庫中的online log大小不一，看起來是經過了多次設定，估計最開始設定為200M，感覺有些小了，後面改進，設定成了500M,估計還是差強人意，就改成了1G。其實這個日誌是可以做調整設定的，而不是一錘子買賣，肯定能修改。
如果出現延遲，很可能就是和日誌的大小情況有關，主庫的小，備庫的大，暫時不會出現問題，如果主庫的大，備庫的小，那就有問題，或者備庫沒有standby log，也是如此。
一個較為正常的備庫的alert日誌情況如下，假設歸檔設定是預設的情況下。會有下面的額外兩行尤其需要關注，你可以看到standby log被引用。
RFS[1]: Selected log 23 for thread 1 sequence 476186 dbid 1210367666 branch 622336050
Media Recovery Log /U01/app/oracle/oradata/sol/arch/SOL/archivelog/2017_02_08/o1_mf_1_476185_d9o5ocmt_.arc
Wed Feb 08 14:14:06 2017
Media Recovery Waiting for thread 1 sequence 476186 (in transit)
Recovery of Online Redo Log: Thread 1 Group 23 Seq 476186 Reading mem 0
Mem# 0: /U01/app/oracle/oradata/sol/arch/SOL/onlinelog/o1_mf_23_d9ofo81j_.log 所以說，任何看起來複雜的問題的原因都會很簡單，明確了問題，解決起來就會得心應手。