专栏首页杨建荣的学习笔记一个备库中ORA错误信息的分析 (r6笔记第69天)

一个备库中ORA错误信息的分析 (r6笔记第69天)

最近也在处理一些遗留的问题,所以对于使用orabbix的报警还是心怀敬畏之心,一方面是我们让它能够做全方位的监控,另一方面也让我发现我们还是存在不少的小问题,小问题虽小,但是放大了,就是大麻烦,甚至数据库事故。 自从上次在社群分享了DB time的抖动案例之后,有不少的朋友似乎对这个工具很感兴趣,我做这个分享的一个主要原因就是希望大家在有些细节中发现问题,至于我分享的问题原因,都是各种各样的小问题,有些朋友也纳闷这种错误似乎还是比较低级的,通过一般的监控都应该解决,但是确实存在,发现了解决了,就是我们的最终目的。 前几天又收到一条报警短信,提示某个备库报了ora错误,但是短信中也没有提到更多的ora信息,首先连接到主库看看是否dg出了问题,使用dgmgrl进行验证,没有发现任何问题。 然后登录到备库,查看ora日志,发现了这么一段错误内容。 Redo Shipping Client Connected as PUBLIC -- Connected User is Valid RFS[1873]: Assigned to RFS process 3095 RFS[1873]: Identified database type as 'physical standby' RFS[1873]: Archived Log: '/opt/app/oracle/fra/SEXTDB3/archivelog/2015_09_22/o1_mf_1_2997_c016jv19_.arc' Tue Sep 22 08:00:31 2015 Media Recovery Log /opt/app/oracle/fra/SEXTDB3/archivelog/2015_09_22/o1_mf_1_2997_c016jv19_.arc Media Recovery Waiting for thread 1 sequence 2998 Tue Sep 22 09:18:01 2015 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL Tue Sep 22 09:18:06 2015 MRP0: Background Media Recovery cancelled with status 16037 Tue Sep 22 09:18:06 2015 Errors in file /opt/app/oracle/admin/extradb/bdump/extdb_mrp0_3067.trc: ORA-16037: user requested cancel of managed recovery operation Recovery interrupted! Tue Sep 22 09:18:08 2015 Errors in file /opt/app/oracle/admin/extradb/bdump/extdb_mrp0_3067.trc: ORA-16037: user requested cancel of managed recovery operation Tue Sep 22 09:18:08 2015 MRP0: Background Media Recovery process shutdown (extdb) Tue Sep 22 09:18:09 2015 Managed Standby Recovery Canceled (extdb) Tue Sep 22 09:18:09 2015 Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL Tue Sep 22 09:18:11 2015 ALTER DATABASE OPEN READ ONLY Tue Sep 22 09:18:11 2015

从错误信息来看,似乎是日志应用的mrp终止了,但是查看后面的日志发现最新的日志已经成功应用了,如果没有其他人的操作,那么这个操作就是自动触发的了。 首先可以排除人为的操作。 我通过下面的脚本从alert日志中抓取最近几天的ORA错误情况,发现每天早晨的8点,9点左右,数据库都会启动到read only状态,然后稍过几分钟,又会切换回日志应用状态。 tail -10000 alert_extradb.log| grep -A1 -B1 "READ ONLY" -- Sun Sep 20 09:18:05 2015 ALTER DATABASE OPEN READ ONLY Sun Sep 20 09:18:05 2015 -- Physical standby database opened for read only access. Completed: ALTER DATABASE OPEN READ ONLY Sun Sep 20 09:18:05 2015 -- Sun Sep 20 16:00:05 2015 ALTER DATABASE OPEN READ ONLY Sun Sep 20 16:00:05 2015 -- Physical standby database opened for read only access. Completed: ALTER DATABASE OPEN READ ONLY Sun Sep 20 16:00:05 2015 -- Mon Sep 21 08:00:10 2015 ALTER DATABASE OPEN READ ONLY Mon Sep 21 08:00:10 2015 -- Physical standby database opened for read only access. Completed: ALTER DATABASE OPEN READ ONLY Mon Sep 21 08:00:11 2015 -- Mon Sep 21 09:18:10 2015 ALTER DATABASE OPEN READ ONLY Mon Sep 21 09:18:10 2015 -- Physical standby database opened for read only access. Completed: ALTER DATABASE OPEN READ ONLY Mon Sep 21 09:18:10 2015

好了,基本可以定位问题不是人为触发。应该是crontab或者scheduler来触发的了。 查看crontab,查看时间点相近的配置,就发现了两条相关的记录,时间戳和ORA的时间戳是一致的。 0 8,16 * * * (/bin/bash /home/oracle/dbadmin/scripts/query/query_for_xxxxx.sh 2>&1 > /dev/null) 18 9 * * * . $HOME/.extradbprofile;$HOME/dbadmin/scripts/query_data/query_mail.sh 6563 本来问题到此就基本明白了,是因为crontab触发的查询报出的ora错误,那么为什么查询还会需要一次又一次的read only呢,还是因为这是一个10gR2的库。 有时候应用部门有这种查询的需求,但是又不能人工每天去查,就让系统每天定时触发,然后发送邮件即可。 那么我们就默认保持现状吧,查看了一下这几个脚本 dgmgrl / "edit database sextdb3 set state='READ-ONLY'" 查询部分 发送邮件 dgmgrl / "edit database sextdb3 set state='online'" 查看这几个脚本已经有好些年头了。是否业务部门还需要这样的查询,本来想联系一下他们,顺着脚本中的邮箱去查看,但是发现这几个人已经不在通讯录中了,那么这就意味着这种查询可能不再需要了。 简单的讨论和核查后,确认这两个job已经不再需要了,这样这个问题就基本解决了,早上再也没有这两个ORA报警了,想想心里又会少咯噔几下。

本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes),作者:杨建荣

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2015-09-25

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • EM agent无法启动的原因及分析 (r6笔记第75天)

    昨天收到一条报警短信,短信内容大体如下: Agent is Unreachable(REASON=javax.net.ssl.SSLPeerUnverified...

    jeanron100
  • 数据库日志中一条"异常"信息所包含的细节(r6笔记第18天)

    今天在梳理服务器的信息的时候,发现有一台服务器没有设置crontab作业,一般的服务器中可能会需要一些定时的任务来触发一些备份,清理等等工作。 因为这是一台备库...

    jeanron100
  • 大量redo生成的问题原因及改进(r6笔记第50天)

    接着上次分享的关于数据库无法登录的原因http://blog.itpub.net/23718752/viewspace-1791089/ 其实最终还是因为在短期...

    jeanron100
  • 希拉里竞选团队CTO:如何让工程师团队的沟通更高效

    大数据文摘
  • 华为oj之质数因子

    功能:输入一个正整数,按照从小到大的顺序输出它的所有质数的因子(如180的质数因子为2 2 3 3 5 )

    Enjoy233
  • JDBC原理浅析,当达到一定层级后,回头看这些当初的细节

    JDBC,你还记得她的全称是啥么?中文几个意思? 今儿咱再回来拉练一把当初的JDBC! JDBC原理浅析,当达到一定层级后,回头看这些当初的细节,真的入门后,也...

    企鹅号小编
  • Java多线程之CAS

    CAS字面意思为比较并交换.CAS 有 3 个操作数,分别是:内存值 M,期望值 E,更新值 U。当且仅当内存值 M 和期望值 E 相等时,将内存值 M 修改为...

    Java宝典
  • Chrome谷歌浏览器下不支持css字体小于12px的解决办法

    当我们进行编程时发现,谷歌浏览器对于12px以下的字体大小均解释为12px,而在其他浏览器中可以实现。

    OECOM
  • Git实战(四)| Git分支管理实操,搞定在线合并和本地合并

    类似于SVN这种集中式版本管理,三年前刚来上海工作时候,在华为驻场上班,华为用的就是SVN,印象最深的就是那个小乌龟的图标;后来到外面工作,渐渐发现用Git的非...

    霍格沃兹测试学院
  • H3C SR6604 session 优

    由于业务流量不断增大,导致 6604的内存占用不断升高,为避免由路由器内存占用过大影响设备整体性能,对路由器的会话参数做了以下调整。

    py3study

扫码关注云+社区

领取腾讯云代金券