一条简单的报警信息发现的oracle bug

系统中有这样一条报警信息,看似比较简单,但是引起了我的注意,主要原因是因为这是一个10gR2的备库,备库如果出现这样的问题,看起来似乎是在归档删除上存在一些问题。
[DB监控系统]_ora_test_s2_yangjr@10.127.2.133_报警
ZABBIX-监控系统:
------------------------------------
报警内容: Free disk space is less than 20% on volume /opt
------------------------------------
报警级别: PROBLEM
------------------------------------
监控项目: Free disk space on /opt (percentage):9.99 %
------------------------------------
报警时间:2016.03.17-02:54:03
于是做了初步的检查,查看磁盘空间,发现数据分区的空间使用率已经剩下差不多9%了。
[@test.cyou.com arch]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             5.9G  1.5G  4.1G  27% /
/dev/sda6             459G  392G   44G  91% /opt
/dev/sda3             7.8G  1.2G  6.2G  17% /var
/dev/sda5              12G  2.6G  8.6G  23% /usr
tmpfs                  32G  8.0K   32G   1% /dev/shm
为了锻炼公司里的几个实习同学,于是我叫他们过来分析分析。他们噼里啪啦的敲了一会键盘,然后试探性的告诉我说,发现问题了,是一个磁盘空间里面存在大量的历史归档,细看那些归档文件,都是好几年以前的,而且不在归档路径下,简单做了确认,然后做了删除,问题的分析就告一段落。
再次查看空间,发现已经剩余近54%,看起来是达到了初步的效果。
[@test.cyou.com ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             5.9G  1.5G  4.1G  27% /
/dev/sda6             459G  197G  239G  46% /opt
/dev/sda3             7.8G  1.2G  6.2G  17% /var
/dev/sda5              12G  2.6G  8.6G  23% /usr
tmpfs                  32G  8.0K   32G   1% /dev/shm
实习的同学看着我,这个问题就这样了吧,我说稍等,仔细查看数据的使用情况。
目前空间使用大197G,如果单纯这样看,肯定发现不了问题,但是我的印象之中,这个库只有100G的样子,剩下的90多个G看起来还是有些可疑,于是我大手一挥,说这个问题还是有些蹊跷,再查查这近90G的空间消耗在哪儿了?
然后他们带着疑惑又开始在电脑上查找,当然也找到了一些线索。发现审计日志里面有大量的审计日志,大概占用几个G,做了简单确认,清了近4G的文件,那么这个问题似乎离根本又近了一步,但是根本问题还没有找到。继续让他们查看。其实这个时候我也不知道问题的根本原因,但是通过这些大体的数字告诉我,这应该是个问题。
他们最后发现归档文件占用了近60多G的空间,但是查看了各个脚本的情况,分析了各个目录的使用情况,也没有发现究竟是哪里出了问题。
于是我告诉他们这样来分析,既然归档目录占用了近60G的空间,为什么会有60G的空间。这个问题其实很好回答,日志文件大小是多大,每天的归档日志量是多少,归档的保留期限是多长时间。
带着这样的思路他们很快找到了答案,归档是100M,每天归档量大概在300~400M之间,归档保留3天,如此算来这个业务也不算繁忙,保留三天应该只占用1G左右的空间,为什么占用了60G的空间,带着这个问题,首先排除了备库是read-only的状态,即归档没有应用的潜在风险,然后进一步分析,发现归档的删除脚本是使用crontab的方式来触发,每天触发一次。
归档的删除策略主要的脚本内容为:
rman target / <<eof
backup current controlfile format '/home/oracle/backup_stage/ctl_%d_%T_%s.bak';
CONFIGURE ARCHIVELOG DELETION POLICY TO applied on all standby ;
crosscheck archivelog all;
delete noprompt expired archivelog all;
delete noprompt archivelog until time "sysdate-3";
exit
EOF

这个脚本看起来是没有任何问题,使用crosscheck这几个命令的时候都没有问题,那问题出在哪里了呢?
只有这两句了。
backup current controlfile format '/home/oracle/backup_stage/ctl_%d_%T_%s.bak';
CONFIGURE ARCHIVELOG DELETION POLICY TO applied on all standby ;
我们单独运行看看,发现果真报错了。
RMAN> backup current controlfile format '/home/oracle/backup_stage/ctl_%d_%T_%s.bak';
Starting backup at 17-MAR-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=2971 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
channel ORA_DISK_1: starting piece 1 at 17-MAR-16
channel ORA_DISK_1: finished piece 1 at 17-MAR-16
piece handle=/home/oracle/backup_stage/ctl_test_20160317_1914.bak tag=TAG20160317T181920 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00601: fatal error in recovery manager
RMAN-03004: fatal error during execution of command
RMAN-10006: error running SQL statement: select sofar, context, start_time     from v$session_longops    where (start_time > nvl(:1, sysdate-100)  or            start_time = nvl(:2, sysdate+100)) and          sid = :3 and          serial# = :4 and          opname like 'RMAN:%'    order by start_time desc, context desc
RMAN-10002: ORACLE error: ORA-00000: normal, successful completion
备份控制文件怎么出了问题了。那下面的配置有没有问题呢。
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO applied on all standby ;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "all": expecting one of: "standby"
RMAN-01007: at line 1 column 52 file: standard input
因为这是一个10gR2的备库,所以这个配置再10g中是没有那个all的,即CONFIGURE ARCHIVELOG DELETION POLICY TO applied on standby;
然后回到备份控制文件的部分,为什么这个步骤会出错呢。我们跳转到备份目录下,发现控制文件却是备份成功了。
[@test.cyou.com 20160317]$
-rw-r----- 1 oracle oinstall 7667712 Mar 12 08:40 ctl_test_20160312_1907.bak
-rw-r----- 1 oracle oinstall 7667712 Mar 13 08:40 ctl_test_20160313_1908.bak
-rw-r----- 1 oracle oinstall 7667712 Mar 14 08:40 ctl_test_20160314_1909.bak
-rw-r----- 1 oracle oinstall 7667712 Mar 15 08:40 ctl_test_20160315_1910.bak
-rw-r----- 1 oracle oinstall 7667712 Mar 16 08:40 ctl_test_20160316_1911.bak
-rw-r----- 1 oracle oinstall 7667712 Mar 17 08:40 ctl_test_20160317_1912.bak
-rw-r----- 1 oracle oinstall 7667712 Mar 17 18:16 ctl_test_20160317_1913.bak
-rw-r----- 1 oracle oinstall 7667712 Mar 17 18:19 ctl_test_20160317_1914.bak
drwxr-xr-x 2 oracle oinstall    4096 Nov  9  2011 standby
[@test.cyou.com backup_stage]$ pwd
/home/oracle/backup_stage
看到这里我已经明白了问题的基本原因,那就是在10gR2中,备库反复再read-only,online状态之间切换会触发一个bug(5583049),但是rman操作的结果返回ORA-00000: normal, successful completion,直接导致了后面的脚本没有运行。
这种情况一个解决方案就是重启备库。
所以简单做了确认,发现备库其实在去年年底重启过一次。按照问题的时间来算,似乎也正是从那个时候开始归档就一直没有成功删除。
idle> select startup_time from v$instance;

STARTUP_TIME
------------
09-NOV-15
重启之后,再次尝试删除,就会发现没有任何问题了。
MAN> backup current controlfile format '/home/oracle/backup_stage/ctl_%d_%T_%s.bak';
Starting backup at 17-MAR-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=2958 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
channel ORA_DISK_1: starting piece 1 at 17-MAR-16
channel ORA_DISK_1: finished piece 1 at 17-MAR-16
piece handle=/home/oracle/backup_stage/ctl_test_20160317_1915.bak tag=TAG20160317T182733 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 17-MAR-16
Starting Control File and SPFILE Autobackup at 17-MAR-16
piece handle=/U01/app/oracle/flash_recovery_area/Stest2/autobackup/2016_03_17/o1_mf_s_906705220_cgo1nptx_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 17-MAR-16
这个问题的进一步解决就是可以在删除归档的脚本里面去掉控制文件的这种备份方式,保证归档及时删除即可,可以通过主库生成,或者在主库备份控制文件即可。
所以如此一来,通过一个很简单的案例,一层一层分析,还是可以发现很多潜在的问题。

</eof

时间: 2024-10-03 21:54:53

一条简单的报警信息发现的oracle bug的相关文章

由一条报警信息发现的一系列问题

今天看到一条报警短信,提示是某个表空间的问题. ZABBIX-监控系统: ------------------------------------ 报警内容: Tablespace Usage warning ------------------------------------ 报警级别: PROBLEM ------------------------------------ 监控项目: showtsps:-->TS_NAME:UNDOTBS1 :4.8% Free -----------

两条报警信息的分析(第二篇)

还是继续分析报警信息的关联,下面两个看似没有直接联系的报警信息其实很有关联. 下面是主库的报警的信息,查看v$dataguard_status得到了最新的错误信息. ############################# [DB监控系统]_adb2_p@10.127.xx.19_报警 ZABBIX-监控系统:  ------------------------------------ 报警内容: DG_issue ------------------------------------ 报警

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

在主备库环境中,如果出现数据文件级的一些不一致,后期修复会很麻烦,所以这种情况可以提前规避,减少后期的隐患,我定制了一个数据库监控选项,即数据文件状态的检查. 最近几天,在半夜的时候,我总会收到这么一则报警信息,最开始没有留意,看报警信息是在备库中. [DB监控系统]_ora_stest2_s2_yangjr@10.127.xxxx_报警 ZABBIX-监控系统: ------------------------------------ 报警内容: datafile status issue -

由报警邮件分析发现的备库oracle bug

昨天到公司之后,收到两份封报警邮件,可以看到在早晨6:30左右主库的v$dataguard_status检查时发现了一个错误.然后再2分钟后就自动恢复了. 一般这种问题很自然想到可能是网络出现了一些问题.因为自动恢复了,所以也不同太着急处理,于是细细看了下.报警邮件如下: ZABBIX-监控系统: ------------------------------------ 报警内容: DG_issue ------------------------------------ 报警级别: PROBL

如何一次性删除所有VNX的报警信息?

故障现象: VNX系列,报警日志总是一条一条的出现,删一条再出一条,如何一次性删除所有VNX的报警信息? 解决方案: VNX for Block:如果在Unisphere界面告警信息多次无法删除,可以通过重启restart management server服务来解决: VNX for File:登录到命令行,到目录/nas/log/webui中,编辑alert_log文件,该文件就保存着Unisphere界面的告警信息,删除文件里面的内容就好了.

关于报警信息读取发送模式的设计问题

问题描述 在做一个平台,是这样的project项目出现报警,报警信息保存在alert报警信息表中.以前只要在pc上看就行了,现在要和手机端互联,也就是写脚本隔一段时间刷新表,每次发现数据库alert表中有新的记录时就推送表信息给手机端.如何保证alert表中每次有新的记录都推送给手机端,而不会把之前时间相近的信息重复推送出去呢? 问题补充:也就是说如何判断alert表中报警记录之前已经发送过,能不能不修改表结构,以添加中间表的方式如何设计呢? 解决方案 我以前的做法是加一张表,在里面记录下每次把

病毒式营销的六条简单原则

我不得不承认,"病毒式营销"这个词儿有点儿攻击性.自诩为病毒式营销者的人会让人望而生畏.但是,我就喜欢.你也许会问"人们有对付它的疫苗么?".作为一种险恶的东西,小小的病毒命运多舛,半死不活,只有在灾难电影或者恐怖电影里才能见到,乏人问津. 但是你不得不崇拜病毒.他深居简出,直到纯粹靠数量赢得优势之后人们才意识到他庞大数目.他寄生在其他宿主身上,并利用宿主的资源繁衍自己的后代.在合适的环境中,他会呈指数级增长.病毒甚至不用搞对象--他仅仅靠复制,通过一次次的几何级增

mysql-一条简单而又迷惑的MySql语句

问题描述 一条简单而又迷惑的MySql语句 有两个表person和ordersperson里存着顾客的名字name和身份证号id,orders里存着顾客的身份证号id.订单的oid和每笔订单所购的货物的清单list.如下person表 name id orders表id oid list SQL语句 select name(select count(*) from orders where orders.id=person.id) from person order by name;输出的结果正

c++里函数的简单问题,我发现这窟窿值得我再捅一捅

问题描述 c++里函数的简单问题,我发现这窟窿值得我再捅一捅 编写一个字符串连接函数str_cat(char s[],char s1[],char s2[]),完成s=s1+s2的字符串连接工作.具体要求为,先将字符串s1复制到s中,然后再将字符串s2连接到s后面.在主函数中定义三个字符串数组str[80].str1[40].str2[40],将两个字符串输入到str1与str2中,调用字符串连接函数str_cat(),将str1与str2连接到str中,最后输出连接后的字符串str.要求用两种