在主備庫環境中，如果出現數據檔案級的一些不一致，後期修復會很麻煩，所以這種情況可以提前規避，減少後期的隱患，我定製了一個數據庫監控選項，即資料檔案狀態的檢查。 最近幾天，在半夜的時候，我總會收到這麼一則報警資訊，最開始沒有留意，看報警資訊是在備庫中。 [DB監控系統][email protected]_報警 ZABBIX-監控系統: ------------------------------------ 報警內容: datafile status issue ------------------------------------ 報警級別: PROBLEM ------------------------------------ 監控專案: dbf_status：datafile status issue:+DATA/sgstatdb3/datafile/tlserlog_data_20160704.659.909619203:RECOVER ------------------------------------ 報警時間:2016.05.29-02:13:56

今天想起來這個問題，還是有些奇怪，決定好好檢查一番。 在檢查過程中，發現了不少的小問題。 首先，這其實是一個主庫，上週五以前是一個備庫，做了主備切換之後，監控系統中的資訊沒有更新及時，所以這是一個問題。 當然這個問題說大也大，說下也小，怎麼理解呢，如果對這個問題進一步分析，就會發現，報警資訊中的提示是在ASM儲存的資料檔案狀態顯示為RECOVER,而目前的主庫中沒有ASM儲存，所以由此可以判斷這個資料的結果還是來自於備庫，那麼為什麼會出現這種情況呢。 簡單查看了一下Orabbix的配置發現，配置資訊中已經修改了JDBC連線資訊，但是實際上後臺還是在連線原來的主庫，而這種情況該如何修復呢，其實就 是在Orabbix中重新初始化一番，即從當前的資料配置列表中刪除現在的主庫，然後略作停頓，等Orabbix能夠識別出刪除配置的操作，然後重新新增 即可。 Orabbix中會出現類似下面的資訊，意味著這個刪除配置已經被系統識別了。 2016-05-29 20:38:49,366 [main] WARN Orabbix - Database stest2 removed from configuration file 2016-05-29 20:38:49,370 [main] WARN Orabbix - Database stest2 conections closed 然後重新新增即可。 這樣根本性的問題就解決了。 我們可以進一步思考，主備庫的監控問題已經修復了。現在的問題是如果是在監控原來的備庫，為什麼備庫會出現資料檔案的狀態為RECOVER？ 在11g ADG的環境中，備庫資料檔案出現這種狀態看起來還是有些奇怪，正常狀態已經是AVAILABLE. 每天都會定時報警，提示資料檔案狀態為RECOVER,我們來看看那個時間段裡會有什麼樣的操作，經過分析發現那個時間段附近有幾個Scheduler Job執行失敗，和TNS的配置有關，簡單修復即可。 另外注意到一個問題，就是主備庫存在延遲，這是一個11g的環境，出現這類問題實在是太不應該了。 使用verbose檢視備庫的資訊，延遲還是有的。 DGMGRL> show database verbose stest3; Database - stest3 Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 15 minutes 28 seconds

Apply Lag: 15 minutes 28 seconds Real Time Query: ON Instance(s): stest2 而且稍等一會，繼續檢視延遲就繼續變大。 DGMGRL> DGMGRL> show database verbose stest3; Database - stest3 Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 48 minutes 30 seconds Apply Lag: 48 minutes 30 seconds

Real Time Query: ON Instance(s): stest2 而檢視備庫的狀態為： SQL> select open_mode from v$database; OPEN_MODE -------------------- READ ONLY WITH APPLY 由此可見，這也是一種誤區，備庫狀態為open_mode為READ ONLY WITH APPLY，主備庫還是可能出現較大的延遲。 而在備庫排查了日誌檔案，也沒有發現任何問題。這個時候問題就看起來陷入了僵局。 迅速在自己的知識庫中進行搜尋，這種不一致，如果排除了日誌檔案還有什麼可能呢，時間可能是一個問題，在主備伺服器段查看了系統時間，發現存在3分鐘的一個誤差，看起來問題就應該是如此了。 我使用ntpdate重新同步了時間之後，檢視DG Broker還是顯示延遲，這個時候不能慌亂，我們可以重新配置一些備庫的資訊，刪除原來DG Broker的配置，重新新增備庫即可。 檢視主備延遲，這個時候就沒有任何問題了。再過了許久，就沒有出現此類問題。 DGMGRL> DGMGRL> show database verbose stest3; Database - stest3 Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 0 seconds Apply Lag: 0 seconds Real Time Query: ON Instance(s): stest2 看來今天不會再收到這類的報警資訊了，感覺心裡還是踏實了許多。