檢視V$DATAGUARD_STATS

在官方文件上，關於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中新出現的。