Dataguard环境V$DATAGUARD_STATS视图

jiawang

在官方文档上，关于V$DATAGUARD_STATS是这样描述的： 该动态性能视图显示出在主库上产生了多少重做日志数据，但是还没有被备库所应用。所以，通过查询该视图可以基本确定如果万一主库出现崩溃的话，备库上将丢失多少重做日志数据。我们可以在一套Dataguard环境下的任一备库的实例上从该视图里获取相关信息，然而，在主库的实例上查询该视图返回的信息都将是空。也就是说，只可以从备库的实例上查询V$DATAGUARD_STATS，从主库实例上是看不到任何有用信息的。

接下来，解释一下各个字段的值信息：

NAME：

    apply lag,该值表示在通过在备库上应用主库传递过来的重做日志与出库同步所延迟的时间。APPLY LAG: Amount of time that the application of redo data on the standby database lags behind the primary database.从查询中可以看到第1个延迟15秒，第2个延迟0秒。说明该11g的备库应用重做日志已经与该主库完全同步了。
    transport lag,该值表示在单位时间内主库上产生的重做日志还没有传输到备库上，或者主库上产生的重做日志还没有被备库所应用。从查询中看到第1个10g备库上的日志传输延迟7秒，而第2个11g备库的日志传输延迟为0。
    apply finish time,该值表示在备库上完成应用重做日志所需要的时间。从第1个查询中看到完成应用重做日志还需要0.1秒，第2个查询中则为0，因为已经完全同步。
    estimated startup time,该值表示启动和打开物理备库所需要的时间，该字段不是适用于逻辑备库。 An estimate of the time needed to start and open the database.
    standby has been open,该值表示物理备库自从上次启动以来，是否以OPEN READ ONLY方式打开过？该参数值如果是Y，现在需要做FAILOVER，那么就需要先将该物理备库shutdown然后以OPEN READ WRITE方式打开。从第1个查询中，看到该物理备库如果做FAILOVER，那么就需要shutdown--->startup open read write；第2个查询中则没有该记录，因为 11g的dataguard可以一边OPEN READ ONLY，一边执行redo apply,也就是11g 的ACTIVE Dataguard。

VALUE：给出各个参数的值。如第1个查询中的，apply finish time值为+00 00:00:00.1，说明该物理备库需要0.1秒的时间来完成应用剩余的重做日志数据。

UNIT：各个参数的时间单元。

TIME_COMPUTED：物理备库上估算各个参数的本地时间。

DATUM_TIME：在物理备库上获取元数据来估算  APPLY LAG 和 TRANSPORT LAG 这两个参数值的本地时间。如果从多次查询中看到该时间值对应的APPLY LAG 和 TRANSPORT LAG 这两个参数值保持不变的话，那么就说明该物理备库已经停止从主库接收到重做数据！ 该字段是11g中新出现的。