前幾天碰到一個看起來有些奇怪的例子，今天抽空把分析過程整理了一下。 有一主一備的一套測試環境，之前環境在我手裡，交給另外一個同事之後，重新搭建了dataguard，我檢查了一圈，發現都沒有問題，然後過了一個星期的 樣子，無意中再次檢視的時候，發現這個備庫竟然在dg broker中的狀態是disable，當然我也不能看到這個現象就反問同事，說當時dataguard怎麼有這種低階操作問題。我想了想，根據我的印 象，當時也確實是搭建成功了。這些天這個主庫也從來沒有任何的操作，zabbix也一直沒有相關的報警，這個問題引起了我的興趣，我們來查一查。 大體的架構環境是這樣的，有兩臺獨立的測試環境，目前因為schema有一些重合，沒有整合到一起，因為平時的負載極小，而且存在單點故障，就把原來的邏 輯備份方式改成了dataguard。這樣我們基本就從這些邏輯備份校驗中解放出來了。因為平時負載小，使用率不高，所以就把備庫都搭建到了同一個臺服務 器上。 這次dg broker校驗出問題的是test1的主庫 現象就是： DGMGRL> show configuration; Configuration - testdb_dg Protection Mode: MaxPerformance Databases: sactvdb - Primary database s2actvdb - Physical standby database (disabled) Fast-Start Failover: DISABLED Configuration Status: SUCCESS

當時的處理思路是嘗試enable，結果拋錯了。 DGMGRL> enable database s2actvdb; Error: ORA-16631: operation requires shutdown of database or instance "" Failed. DGMGRL> show database verbose s2actvdb; Database - s2actvdb Role: PHYSICAL STANDBY Intended State: OFFLINE Transport Lag: (unknown) Apply Lag: (unknown) Real Time Query: OFF Instance(s): actvdb Properties: DGConnectIdentifier = 's2actvdb' ObserverConnectIdentifier = '' LogXptMode = 'ASYNC' DelayMins = '0' Binding = 'optional' MaxFailure = '0' MaxConnections = '1' ... InconsistentProperties = '(monitor)' InconsistentLogXptProps = '(monitor)' SendQEntries = '(monitor)' LogXptStatus = '(monitor)' RecvQEntries = '(monitor)' SidName = 'actvdb' StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxx)(PORT=1528))(CONNECT_DATA=(SERVICE_NAME=s2actvdb_DGMGRL)(INSTANCE_NAME=actvdb)(SERVER=DEDICATED)))' StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST' AlternateLocation = '' LogArchiveTrace = '0' LogArchiveFormat = '%t_%s_%r.dbf' TopWaitEvents = '(monitor)' Database Status: SHUTDOWN 然後嘗試設定備庫為online DGMGRL> edit database s2actvdb set state='ONLINE'; Error: ORA-16525: the Data Guard broker is not yet available Failed. 這個時候雖然拋錯，dg broker的校驗結果卻發生了變化。 DGMGRL> show configuration; Configuration - testdb_dg Protection Mode: MaxPerformance Databases: sactvdb - Primary database s2actvdb - Physical standby database Error: ORA-16525: the Data Guard broker is not yet available Fast-Start Failover: DISABLED Configuration Status: ERROR 然後折騰了一番，發現原因是log_archive_dest_state_2的值為RESET,重新置為ENABLE之後就沒有問題了。 那麼問題就來了，為什麼這個地方的值變為了reset。 經過一番排查，發現這臺伺服器中的備庫1在本週重啟了，而且還是在nomount階段。 當然這個問題還是很好定位，最後發現是同事搭建test2的備庫的時候，無意中碰到了test1的備庫，做了重啟的操作。 那麼就問題而言，就更奇怪了，先不說重啟備庫的操作失誤，就技術角度而言，重啟備庫會直接導致log_archive_dest_state_2為reset，到底是什麼原因導致這種情況發生。 於是開始翻找日誌的一些痕跡。 RESET相關的日誌為： TNS-12564: TNS:connection refused ns secondary err code: 0 nt main err code: 0 nt secondary err code: 0 nt OS err code: 0 Tue Mar 22 17:53:59 2016 ALTER SYSTEM SET log_archive_dest_state_2='RESET' SCOPE=BOTH; 在置為RESET之前出現了網路連線問題，時間點就是備庫重啟的時間，看起來確實是備庫重啟導致的，為什麼會有這個特殊的內部操作呢。 準備再次復現這個問題，但是重啟之後再就沒有出現這個問題。問題雖然解決了。但是這個問題就一直在腦海中縈繞，因為我還沒有找到問題的根本原因。為了進一步驗證，我開始準備急需檢視更多的日誌，嘗試復現這個問題。