归档日志增长过快处理解决

上传人:ldj****22 文档编号:39547241 上传时间:2018-05-17 格式:DOCX 页数:10 大小:283.12KB
返回 下载 相关 举报
归档日志增长过快处理解决_第1页
第1页 / 共10页
归档日志增长过快处理解决_第2页
第2页 / 共10页
归档日志增长过快处理解决_第3页
第3页 / 共10页
归档日志增长过快处理解决_第4页
第4页 / 共10页
归档日志增长过快处理解决_第5页
第5页 / 共10页
点击查看更多>>
资源描述

《归档日志增长过快处理解决》由会员分享,可在线阅读,更多相关《归档日志增长过快处理解决(10页珍藏版)》请在金锄头文库上搜索。

1、处理归档日志增加过快一例(2010-08-25 20:03:47) 转载 标签: oracle归档日志增加过快分类: 原创文章 处理归档日志增加过快一例处理归档日志增加过快一例摘要摘要本文介绍了不久前作者是如何彻底解决一家医院数据库由于归档日志增长过快,导致磁盘剩余空间占满,引起宕机全过程。通过本案例的描述,我们可以了解到当遇到数据库宕机问题时,应该如何分析现象、找到问题关键、最终彻底解决该问题的一个总体思路,最后还应该深入思考该问题产生的原因,总结出避免以后再出现该问题的建议。关键字: ORACLE、归档日志、宕机、DML 语句初步了解初步了解早上一来到公司,XZH 就告诉我接到 CQ 公司

2、的有一个技术申请,大致情况为一家三甲医院,采用 Rac+Linux 环境,启用了归档模式,但是由于日志增长过快,我们的技术人员设虽然置自动删除归档的任务,但是还是没有避免磁盘空间被占满,已经引起医院 2次全院无法使用,虽然 CQ 公司也安排多名技术人员去现场处理,但是医院认为一直没有解决彻底,因此信息主管对此意见较大,希望公司安排技术支持部现场彻底解决该问题。通过申请描述,我大致了解到以下几个关键点:1.医院启用了归档,也做了定期自动删除归档日志的任务。2.由于归档日志增加过快,已经导致医院 2 号节点宕机。3.我们的技术人员去了几次,都未彻底解决,用户已经意见很大了。这只是个初步情况,往往只

3、能了解问题的大概,具体的问题产生的原因还是得到用户那里去才能真正了解,于是立即出发,前往用户处处理问题。现场分析问题现场分析问题到达医院,同系统管理员互相寒暄了几句,了解大体情况是医院昨天凌晨部分科室反映不能登录导航台,于是系统管理员深夜被叫到医院,查看服务器发现数据库已经宕机,检查磁盘空间,发现其中一个节点的剩余空间为 0,于是立即删除部分过去的归档日志,重新启动服务器,下面科室才能够正常登录,谈话间不断听见系统管理员抱怨深夜到医院是如何如何不情愿,看来意见是比较大。而且同样的问题不久前才出现过一次,当时是中午,询问同去的同事,了解到确实不久前也出现过一次同样的情况,当时认为是归档日志的定期

4、删除保留的日志时间太长,当时保留的是 30 天的日志,后来改为保留 5 天的日志,心想不会再出现该问题,没想到还是无法避免。接下来,该我们自己着手分析问题了,因为毕竟用户描述的只是他的主观判断,而且真正要想了解到时发生的真实情况,看是应该看下 Oracle 的日志才能确认,这也是我们处理问题必须遵守的原则,首先看下该节点的 alter.ora 在出现问题时的错误记录,部分记录情况如下:Fri Jul 18 22:10:18 2010Errors in file /u01/app/oracle/admin/orcl/bdump/orcl2_arc1_13762.trc:ORA-19502: Me

5、ssage 19502 not found; No message file for product=RDBMS, facility=ORA; arguments: /u01/app/oracle/archive/2_24046_698868487.dbf 22529 512ORA-27072: Message 27072 not found; No message file for product=RDBMS, facility=ORALinux-x86_64 Error: 9: Bad file descriptorAdditional information: 4Additional i

6、nformation: 22529Additional information: 507392ORA-19502: Message 19502 not found; No message file for product=RDBMS, facility=ORA; arguments: /u01/app/oracle/archive/2_24046_698868487.dbf 22529 512Fri Jul 18 22:10:18 2010ARCH: Archival stopped, error occurred. Will continue retryingFri Jul 18 22:10

7、:18 2010ORACLE Instance orcl2 - Archival Error从日志记录的时间可以看出,真正出问题应该是在 22 点多钟,只是系统管理员凌晨才得到问题反馈,可以看出自己查看日志是多么的重要,不过从来错误的记录看,确实是由于无法归档,导致该节点出现问题,这个判断到是准确的。首先检查了下日志的增长速度,发现每个节点平均每 13 分钟就产生一个 50M 的归档日志,一天的归档日志就接近30G,而医院的日志放在本地磁盘,磁盘剩余空间也就 100 多 G,按照这种日志的增长速度,空间被日志撑爆也就理所当然了。但是以该院的规模和业务量来看,产生这么多的日志肯定是不正常的,所以

8、找到日志增长过快的原因,是解决问题的根本。首先观察下归档日志产生的频率,我们取当天 24 小时产生日志的频率数,如下图:发现除了在上午业务高峰期(89 点),其他时间段没有明显的曲线变化,而且凌晨时分(07 点)的日志也切换频繁,这就肯定有问题,于是我生成今天 2 点3 点的 AWR报告进行分析,分析情况如下:首先看该时间段的会话不多,只有 60 多个会话,除去系统自带的几个会话,真正应用 ZLHIS 的会话肯定不多,证明当时医院的业务肯定不繁忙。但是每秒钟的处理事务却有 23.82,比很多三甲医院业务高峰期的事务都要大,肯定有问题,进一步分析执行 sql:发现即使在凌晨时分,居然也会如此频繁

9、的执行大量的 sql 语句,其中涉及到update 等 DML 语句,势必会产生大量归档日志,从表名看,应该是与体检系统有直接关系,通过分析,发现是 zl_体检任务结果_Transation 过程中的语句。该过程是实现把体检病人的检验结果更新到体检系统里面,我们程序有 2 种方式进行更新:1.后台每天晚上定时对全院未完成体检的病人集中更新一次,通过调用 zl_体检任务结果_TransationAll 实现,其中 zl_体检任务结果_TransationAll 过程里面,又循环调用了 zl_体检任务结果_Transation 过程。2.是由操作人员在程序上操作,单独更新某一指定病人,只调用 zl

10、_体检任务结果_Transation 过程。后一种情况肯定不会频繁执行该过程,目标锁定在第一种,后台作业方式,于是查看系统后台作业,发现问题作业,如下:该后台作业中该过程的执行频率被调整 3 分钟,通过对 zl_体检任务结果_TransationAll 过程分析我们知道,只要体检病人没有完成体检,都会对其检验结果进行更新,而该医院当时正好进行大量体检,有上千病人没有完成体检,每次执行该过程,都会对这些病人进行更新,可想而知肯定会产生大量日志,所以如此频繁的执行该过程,肯定是不现实的,定位了问题,接下来就该处理该问题。现场处理问题现场处理问题询问相关人员,了解到由于该院体检科想实时得到体检病人的

11、检验结果,所以我们的同事按医院的要求对作业执行频率进行了调整所致,说明了问题的严重性,经过和医院协商,阐述利弊,得到医院的同意,按医院要求最后把该后台作业修改为每天执行 2 次,中午一次,晚上一次。处理方法如下:1.1.1.1. 删除原来的删除原来的 jobjob由于知道 job 号为 107,所以调用 dbms_job 包删除exec dbms_job.remove(107);2.2.2.2. 创建创建 2 2 个的个的 job,job,一个是中午一个是中午 1313 点执行,一个晚上点执行,一个晚上执行执行 1 1 点点-1 点的 jobvariable job number;beginb

12、eginsyssys.dbms_job.submit(job = :job,what = zl_体检任务结果_TransationAll;,next_date = to_date(20-07-2010 01:00:00, dd-mm-yyyy hh24:mi:ss),intervalinterval = trunc(Sysdate)+1+01/24+00/(24*60)+00/(24*60*60);commitcommit;endend;/-13 点的 jobvariable job number;beginbeginsyssys.dbms_job.submit(job = :job,what

13、 = zl_体检任务结果_TransationAll;,next_date = to_date(20-07-2010 13:00:00, dd-mm-yyyy hh24:mi:ss),intervalinterval = trunc(Sysdate)+1+13/24+00/(24*60)+00/(24*60*60);commitcommit;endend;/3.3.3.3. 后续处理后续处理通过上面的修改,马上可以观察到 2 个节点的日志产生速度明显下降了,观察了 1个小时,才产生了 1 个归档日志,由于是在下午时分,本身医院业务不是太忙,这种归档日志的产生速度应该是正常的。然后,再对每个节点

14、的备份和归档日志的删除策略进行下检查,1,2 号机都改为每天晚上 12 点定时删除 30 天前的归档日志,standby 的机器由于空间比较大,调整为每天 12 点定时删除 60 天前的归档日志,最后要求医院近期观察下日志的生成速度,经过医院的确认,得到医院的认可。(另:第二天,要求医院提供日志切换的次数统计,如下图,可以看到确实归档日志切换已经恢复正常,看到问题得到解决,医院的管理员也相当高兴。)后续总结后续总结通过本次问题的处理,可以看出,彻底解决该问题其实不困难,但是我们前面去的技术人员没有根本解决,以致于认为是个高级技术问题,需要申请技术支持才能彻底解决,我们可以得到两点总结:4.4.

15、1.1. 在满足医院要求的情况下,调整在满足医院要求的情况下,调整 ZLHISZLHIS 原有设计时,原有设计时,没有充分考虑可能会带来的隐患。没有充分考虑可能会带来的隐患。如本次案例中,为满足医院体检科想即时得到体检结果的要求,而手工修改提取体检结果 job 的间隔时间,表面上看是满足了医院的要求,但是其后带来的隐含却是比较大的,我们在处理这些事的时候,应该想想他的后续可能引起的问题,再做操作。5.5.2.2. 解决问题时,没有从问题产生的根本去分析问题解决问题时,没有从问题产生的根本去分析问题我们前面的同事在处理过程中,发现了是由于日志增长过快导致医院宕机,但是当时处理的方式是调整日志的删除计划,把删除 30 天的以前的归档日志,该为删除 5 天前的归档日志,当时看好像是解决了问题,但是问题的根本隐患并没有排除,我前面用了大量篇幅介绍了分析问题的过程,就是想说明分析问题的重要性。通过本次问题的描述,希望给以后处理该类似问题的同事予以借鉴,一起共勉。

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 行业资料 > 其它行业文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号