dgbroker校验失败的一个奇怪问题(r8笔记第50天)

dgbroker校验失败的一个奇怪问题(r8笔记第50天) 前几天碰到一个看起来有些奇怪的例子，今天抽空把分析过程整理了一下。有一主一备的一套测试环境，之前环境在我手里，交给另外一个同事之后，重新搭建了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: DISABLEDConfiguration 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然后尝试设置备库为onlineDGMGRL edit database s2actvdb set state=ONLINE;Error: ORA-16525: the Data Guard broker is not yet availableFailed.这个时候虽然抛错，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 availableFast-Start Failover: DISABLEDConfiguration 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: 0Tue Mar 22 17:53:59 2016ALTER SYSTEM SET log_archive_dest_state_2=RESET SCOPE=BOTH;在置为RESET之前出现了网络连接问题，时间点就