DG standby_time 监控脚本优化测试

原创布衣 2022-11-09

1546

背景

当遇到DG 同步延迟之奇怪的经典报错：ORA-16191案例时，根据vdataguard_stats 的apply lag 值做同步时间监控，就会存在一定的报警延迟，为了解决这个问题，我想到了用主库与备库的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 状态值：

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
复制

多执行了几次，备库的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提高敏感度监控。
4、考虑到主库备库网络的情况，我采用的是通过tns远程连接主库与备库的scn时间比对验证同步情况，顺便可以验证下网络的连通性。