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