1. 程式人生 > >Oracle Data Guard延遲的原因

Oracle Data Guard延遲的原因

楊建榮的學習筆記 2017-02-08 22:41

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

所以說,任何看起來複雜的問題的原因都會很簡單,明確了問題,解決起來就會得心應手。