你真会判断DataGuard的延迟吗？

这是一个比较细节的知识点，但必须要理解这个才能准确判断Oracle ADG的延迟情况。

以前做运维工作时，记得是要同时重点关注v$dataguard_stats视图中的几个字段的值，分别是：NAME、VALUE、TIME_COMPUTED、DATUM_TIME。

本文先不考虑v$dataguard_stats视图没有数值显示的特殊情况，只针对当v$dataguard_stats视图正常显示的情况，如何准确判断Oracle ADG的延迟情况。

其实绝大部分管理过ADG的同学都知道，要重点关注NAME列中的transport lag和apply lag，看这两项在VALUE列中的取值，如果都是0，那基本没问题。

经验多些的同学还会在此基础上多关注TIME_COMPUTED、DATUM_TIME这两列的时间，是否近乎相同，和系统时间有无差异。

曾经遇到有用户在巡检ADG延迟时，只简单关注了前者，看都是0就判断没问题，可实际情况已经有很大的gap，这就是没有同时关注TIME_COMPUTED、DATUM_TIME的结果。

而若只关注TIME_COMPUTED、DATUM_TIME，却忽略掉NAME列中的transport lag和apply lag取值，这样也同样会可能造成误判。

如果说给建议就是要都关注，当然，有经验的DBA还会各种查其他信息加以证明，但这也不在本文讨论范围。如果只谈v$dataguard_stats视图，很多用户心里是没底的，因为不清楚细节，为什么会有各种表现情况呢？

通过查阅官方文档，其实在这些字段的描述上也不够精确，容易造成误解。

所以，本文就构建这样的动手实验环境，来帮助大家通过上手实践来具体观察典型场景，加深理解。

场景1: TIME_COMPUTED、DATUM_TIME二者时间近似，且都随系统时间变化

这种情况，无法判定ADG是否延迟。
ADG的传输链路正常，但是ADG备库的MRP进程很可能出现问题，或者不是实时应用导致ADG延迟。

下面开始动手实践构造这类场景的测试用例：

MRP进程异常crash，这里使用kill进程的命令来模拟，一段时间后再去查看ADG延迟的情况：

PHYSICAL STANDBY @DB0913_DG -> SYS @CDB$ROOT> set time on
03:04:32 PHYSICAL STANDBY @DB0913_DG -> SYS @CDB$ROOT> @dg

SOURCE_DBID SOURCE_DB_UNIQU NAME		   VALUE	    UNIT			   TIME_COMPUTED		  DATUM_TIME			     CON_ID
----------- --------------- ---------------------- ---------------- ------------------------------ ------------------------------ ------------------------------ ----------
 2984003235 DB0913_9df_iad  transport lag	   +00 00:00:00     day(2) to second(0) interval   04/09/2024 03:04:35		  04/09/2024 03:04:34			  0
 2984003235 DB0913_9df_iad  apply lag		   +00