归档志增长过快处理解决.docxVIP

处理归档日志增加过快一例(2010-08-25 20:03:47) 转载▼标签： oracle归档日志增加过快分类： 原创文章 处理归档日志增加过快一例摘要 本文介绍了不久前作者是如何彻底解决一家医院数据库由于归档日志增长过快,导致磁盘剩余空间占满，引起宕机全过程。通过本案例的描述,我们可以了解到当遇到数据库宕机问题时，应该如何分析现象、找到问题关键、最终彻底解决该问题的一个总体思路，最后还应该深入思考该问题产生的原因，总结出避免以后再出现该问题的建议。关键字: ORACLE、归档日志、宕机、DML语句初步了解 早上一来到公司，XZH就告诉我接到CQ公司的有一个技术申请，大致情况为一家三甲医院，采用Rac+Linux环境，启用了归档模式，但是由于日志增长过快，我们的技术人员设虽然置自动删除归档的任务，但是还是没有避免磁盘空间被占满，已经引起医院2次全院无法使用，虽然CQ公司也安排多名技术人员去现场处理，但是医院认为一直没有解决彻底，因此信息主管对此意见较大，希望公司安排技术支持部现场彻底解决该问题。 通过申请描述，我大致了解到以下几个关键点： 1.医院启用了归档，也做了定期自动删除归档日志的任务。 2.由于归档日志增加过快，已经导致医院2号节点宕机。 3.我们的技术人员去了几次，都未彻底解决，用户已经意见很大了。 这只是个初步情况，往往只能了解问题的大概，具体的问题产生的原因还是得到用户那里去才能真正了解，于是立即出发，前往用户处处理问题。现场分析问题 到达医院，同系统管理员互相寒暄了几句，了解大体情况是医院昨天凌晨部分科室反映不能登录导航台，于是系统管理员深夜被叫到医院，查看服务器发现数据库已经宕机，检查磁盘空间，发现其中一个节点的剩余空间为0，于是立即删除部分过去的归档日志，重新启动服务器，下面科室才能够正常登录，谈话间不断听见系统管理员抱怨深夜到医院是如何如何不情愿，看来意见是比较大。而且同样的问题不久前才出现过一次，当时是中午，询问同去的同事，了解到确实不久前也出现过一次同样的情况，当时认为是归档日志的定期删除保留的日志时间太长，当时保留的是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: Message 19502 not found; No message file for product=RDBMS, facility=ORA; arguments: [/u01/app/oracle/archive/2_24046_698868487.dbf] [22529] [512]ORA-27072: Message 27072 not found; No message file for product=RDBMS, facility=ORALinux-x86_64 Error: 9: Bad file descriptorAdditional information: 4Additional information: 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] [512]Fri Jul 18 22:10:18 2010ARCH: Archival stopped, error occurred. Will continue retryingFri Jul 18 22:10:18 2010ORACLE Instance orcl2 - Archival Error 从日志记录的时间可以看出，真正出问题应该是在22点多钟，只是系统管理员凌晨才得到问题反馈，可以看出自己查看日志是多么的重要，不过从来错误的记录看，确实是由于无法归档，导致该节点出现问题，这个判断到是准确的。首先检查了下日志的增长速度，发现每个节点平均每1~3分钟就产生一个50M的归档日志，一天的归档日志就接近30G，而医院的日志放在本地磁盘，磁盘剩余