转载

一则报警信息所折射出来的诸多问题

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

报警时间:2016.05.29-02:13:56
正文到此结束
Loading...