一则报警信息所折射出来的诸多问题(r9笔记第14天)

在主备库环境中，如果出现数据文件级的一些不一致，后期修复会很麻烦，所以这种情况可以提前规避，减少后期的隐患，我定制了一个数据库监控选项，即数据文件状态的检查。 最近几天，在半夜的时候，我总会收到这么一则报警信息，最开始没有留意，看报警信息是在备库中。 [DB监控系统]_ora_stest2_s2_yangjr@10.127.xxxx_报警 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 看来今天不会再收到这类的报警信息了，感觉心里还是踏实了许多。