最近也在处理一些遗留的问题，所以对于使用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报警了，想想心里又会少咯噔几下。
