背景
??當遇到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時間比對驗證同步情況,順便可以驗證下網絡的連通性。

文章推薦
《Oracle_索引重建—優(yōu)化索引碎片》
《Oracle 自動收集統(tǒng)計信息機制》
《Oracle 腳本實現簡單的審計功能》
《oracle 監(jiān)控表空間腳本 每月10號0點至06點不報警》
《DBA_TAB_MODIFICATIONS表的刷新策略測試》
《FY_Recover_Data.dbf》
《Oracle RAC 集群遷移文件操作.pdf》
《Oracle Date 字段索引使用測試.dbf》
《Oracle 診斷案例 :因應用死循環(huán)導致的CPU過高》
《Oracle 慢SQL監(jiān)控腳本》
《Oracle 慢SQL監(jiān)控測試及監(jiān)控腳本.pdf》
《記錄一起索引rebuild與收集統(tǒng)計信息的事故》
《RAC DG刪除備庫redo時報ORA-01623》
《ASH報告發(fā)現:os thread startup 等待事件分析》
《問答榜上引發(fā)的Oracle并行的探究(一)》
《問答榜上引發(fā)的Oracle并行的探究(二)》
– 安裝系列
文章推薦
《ORACLE_19C_linux安裝.pdf》
《Oracle 19c-手工建庫.pdf》
《19c單庫升級19.11補丁.pdf
19c_rac補丁《19.11-p32841500》.pdf
《oracle_圖形-單實例11.2.0.4升級19.3.pdf
《oracle_11.2.0.3升級11.2.0.4–單實例升級.pdf
《oracle_靜默-單實例 11.2.0.4升級19.3.pdf
《CentOS_6.7系統(tǒng)一步一步 RAC 11.2.0.4升級19.3.pdf
《整理后_RAC_11.2.0.4升級19c.pdf
歡迎贊賞支持或留言指正




