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    所以說，任何看起來複雜的問題的原因都會很簡單，明確了問題，解決起來就會得心應手。