dgbroker校验失败的一个奇怪问题(r8笔记第50天)前几天碰到一个看起来有些奇怪的例子，今天抽空把分析过程整理了一下。有一主一备的一套测试环境，之前环境在我手里，交给另外一个同事之后，重新搭建了dataguard，我检查了一圈，发现都没有问题，然后过了一个星期的样子，无意中再次查看的时候，发现这个备库竟然在dgbroker中的状态是disable，当然我也不能看到这个现象就反问同事，说当时dataguard怎么有这种低级操作问题。我想了想，根据我的印象，当时也确实是搭建成功了。这些天这个主库也从来没有任何的操作，zabbix也一直没有相关的报警，这个问题引起了我的兴趣，我们来查一查。大体的架构环境是这样的，有两台独立的测试环境，目前因为schema有一些重合，没有整合到一起，因为平时的负载极小，而且存在单点故障，就把原来的逻辑备份方式改成了dataguard。这样我们基本就从这些逻辑备份校验中解放出来了。因为平时负载小，使用率不高，所以就把备库都搭建到了同一个台服务器上。这次dgbroker校验出问题的是test1的主库现象就是：DGMGRL>showconfiguration;Configuration-testdb_dgProtectionMode:MaxPerformanceDatabases:sactvdb-Primarydatabases2actvdb-Physicalstandbydatabase(disabled)Fast-StartFailover:DISABLEDConfigurationStatus:SUCCESS当时的处理思路是尝试enable，结果抛错了。DGMGRL>enabledatabases2actvdb;Error:ORA-16631:operationrequiresshutdownofdatabaseorinstance''Failed.DGMGRL>showdatabaseverboses2actvdb;Database-s2actvdbRole:PHYSICALSTANDBYIntendedState:OFFLINETransportLag:(unknown)ApplyLag:(unknown)RealTimeQuery:OFFInstance(s):actvdbProperties: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)'DatabaseStatus:SHUTDOWN然后尝试设置备库为onlineDGMGRL>editdatabases2actvdbsetstate='ONLINE';Error:ORA-16525:theDataGuardbrokerisnotyetavailableFailed.这个时候虽然抛错，dgbroker的校验结果却发生了变化。DGMGRL>showconfiguration;Configuration-testdb_dgProtectionMode:MaxPerformanceDatabases:sactvdb-Primarydatabases2actvdb-PhysicalstandbydatabaseError:ORA-16525:theDataGuardbrokerisnotyetavailableFast-StartFailover:DISABLEDConfigurationStatus:ERROR然后折腾了一番，发现原因是log_archive_dest_state_2的值为RESET,重新置为ENABLE之后就没有问题了。那么问题就来了，为什么这个地方的值变为了reset。经过一番排查，发现这台服务器中的备库1在本周重启了，而且还是在nomount阶段。当然这个问题还是很好定位，最后发现是同事搭建test2的备库的时候，无意中碰到了test1的备库，做了重启的操作。那么就问题而言，就更奇怪了，先不说重启备库的操作失误，就技术角度而言，重启备库会直接导致log_archive_dest_state_2为reset，到底是什么原因导致这种情况发生。于是开始翻找日志的一些痕迹。RESET相关的日志为：TNS-12564:TNS:connectionrefusednssecondaryerrcode:0ntmainerrcode:0ntsecondaryerrcode:0ntOSerrcode:0TueMar2217:53:592016ALTERSYSTEMSETlog_archive_dest_state_2='RESET'SCOPE=BOTH;在置为RESET之前出现了网络连接问题，时间点就是备库重启的时间，看起来确实是备库重启导致的，为什么会有这个特殊的内部操作呢。准备再次复现这个问题，但是重启之后再就没有出现这个问题。问题虽然解决了。但是这个问题就一直在脑海中萦绕，因为我还没有找到问题的根本原因。为了进一步验证，我开始准备急需查看更多的日志，尝试复现这个问题。