一则报警信息所折射出来的诸多问题(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 看来今天不会再收到这类的报警信息了,感觉心里还是踏实了许多。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2016-05-29

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

巧用外部表备份历史数据(r5笔记第62天)

在很多的系统中,随着时间的推移,都会沉淀大量的历史数据。一般数据量达到一定程度都会考虑使用分区表来处理。根据业务规则,可能有些历史数据隔一段时间就需要做清理了,...

378120
来自专栏张善友的专栏

MongoDB核心贡献者:不是MongoDB不行,而是你不懂!

近期MongoDB在Hack News上是频繁中枪。许多人更是声称恨上了MongoDB,David mytton就在他的博客中揭露了MongoDB许多现存问题。...

250100
来自专栏GopherCoder

专栏:010:SQL VS No SQL

16230
来自专栏web编程技术分享

【php增删改查实例】第十一节 - 部门管理模块(编辑功能)

16980
来自专栏向治洪

mqtt推送介绍

方案1、使用GCM服务(Google Cloud Messaging) 简介:Google推出的云消息服务,即第二代的C2DM。 优点:Google提供的服务、...

61580
来自专栏张善友的专栏

zookeeper 分布式锁服务

分布式锁服务在大家的项目中或许用的不多,因为大家都把排他放在数据库那一层来挡。当大量的行锁、表锁、事务充斥着数据库的时候。一般web应用很多的瓶颈都在数据库上,...

22580
来自专栏大数据

Kafka详细的设计和生态系统

Kafka 的核心是经纪人,主题,日志,分区和集群。核心也包括像 MirrorMaker 这样的相关工具。前面提到的是 Kafka,因为它存在于 Apache ...

1.1K10
来自专栏IT大咖说

TiDB 原理与实战|架构师实践日

摘要 本篇文章出自七牛云和 PingCAP 联合主办的架构师实践日上,来自 PingCAP 的开发工程师李霞分享的《 TiDB 原理与实战》的演讲,介绍了目前分...

48170
来自专栏杨建荣的学习笔记

MySQL中的binlog和redo浅析(r12笔记第5天)

有一个小问题可能很多人都想起过,那就是MySQL中既然已经有了binlog,为什么还需要redo,这个问题看起来好像很简单,但是细细品来,还是有不少值得注...

376110
来自专栏微信终端开发团队的专栏

微信 iOS SQLite 源码优化实践

本文将分享在 SQLite 源码上进行的多线程并发、I/O性能优化等,并介绍优化相关的 SQLite 原理。

54700

扫码关注云+社区

领取腾讯云代金券