DG standby_time 監(jiān)控腳本優(yōu)化測試

原創(chuàng) 布衣 2022-11-09

2046

背景

??當遇到DG 同步延遲之奇怪的經典報錯：ORA-16191案例時，根據vdataguard_stats 的apply lag 值做同步時間監(jiān)控，就會存在一定的報警延遲，為了解決這個問題，我想到了用主庫與備庫的scn 時間比較來確定同步是否延遲。

測試

主庫報錯： ORA-01031

SQL> select dest_name,status,error from v$archive_dest where dest_id=1 or dest_id=2;

DEST_NAME            STATUS               ERROR
-------------------- -------------------- ------------------------------------------------------------
LOG_ARCHIVE_DEST_1   VALID
LOG_ARCHIVE_DEST_2   ERROR                ORA-01031: insufficient privileges

主庫scn時間：

SQL> select to_char(scn_to_timestamp(current_scn),'yyyy-mm-dd hh24:mi:ss') from v$database;

TO_CHAR(SCN_TO_TIME
-------------------
2022-11-08 11:38:11

備庫scn時間及apply lag 狀態(tài)值：

SQL> select to_char(scn_to_timestamp(current_scn),'yyyy-mm-dd hh24:mi:ss') from v$database;

TO_CHAR(SCN_TO_TIME
-------------------
2022-11-08 11:38:18
SQL>  select value from v$dataguard_stats where NAME='apply lag';
VALUE
--------------------
+00 00:00:00

以上操作可以看出，雖然主備同步異常，但是scn 號還在同步更新，apply lag 值：+00 00:00:00

主庫切歸檔

SQL> alter system switch logfile;
System altered.

主庫scn時間：

SQL>  select to_char(scn_to_timestamp(current_scn),'yyyy-mm-dd hh24:mi:ss') from v$database;
TO_CHAR(SCN_TO_TIME
-------------------
2022-11-08 11:45:52

查看備庫scn時間

SQL>  select to_char(scn_to_timestamp(current_scn),'yyyy-mm-dd hh24:mi:ss') from v$database;

TO_CHAR(SCN_TO_TIME
-------------------
2022-11-08 11:45:21
SQL> /

TO_CHAR(SCN_TO_TIME
-------------------
2022-11-08 11:45:21

SQL> /

TO_CHAR(SCN_TO_TIME
-------------------
2022-11-08 11:45:21

多執(zhí)行了幾次，備庫的scn時間不再更新
查看同步時間，apply lag時間依然： +00 00:00:00 ，這就失去了同步延遲報警的意義了

SQL> select * from v$dataguard_stats where NAME='apply lag';

NAME       VALUE                UNIT                           TIME_COMPUTED                  DATUM_TIME
---------- -------------------- ------------------------------ ------------------------------ ------------------------------
apply lag  +00 00:00:00         day(2) to second(0) interval   11/08/2022 11:51:27            11/08/2022 11:45:23

結論

1、apply lag 的VALUE值依然：+00 00:00:00
2、TIME_COMPUTED:11:51:27 DATUM_TIME:11:45:23 已經看到延遲了。
3、從這就可以看出VALUE：+00 00:00:00 ，并不是很敏感。可以TIME_COMPUTED與DATUM_TIME提高敏感度監(jiān)控。
4、考慮到主庫備庫網絡的情況，我采用的是通過tns遠程連接主庫與備庫的scn時間比對驗證同步情況，順便可以驗證下網絡的連通性。