问题时的错误记录，部分记录情况如下：
FriJul182210182010Errorsi
fileu01apporacleadmi
orclbdumporcl2_arc1_13762trcORA19502Message19502
otfou
dNomessagefileforproductRDBMSfacilityORAargume
tsu01apporaclearchive2_24046_698868487dbf22529512ORA27072Message27072
otfou
dNomessagefileforproductRDBMSfacilityORALi
uxx86_64Error9Badfiledescriptor
fAdditio
ali
formatio
4Additio
ali
formatio
22529Additio
ali
formatio
507392ORA19502Message19502
otfou
dNomessagefileforproductRDBMSfacilityORAargume
tsu01apporaclearchive2_24046_698868487dbf22529512FriJul182210182010ARCHArchivalstoppederroroccurredWillco
ti
ueretryi
gFriJul182210182010ORACLEI
sta
ceorcl2ArchivalError从日志记录的时间可以看出，真正出问题应该是在22点多钟，只是系统管理员凌晨才得到问题反馈，可以看出自己查看日志是多么的重要，不过从来错误的记录看，确实是由于无法归档，导致该节点出现问题，这个判断到是准确的。首先检查了下日志的增长速度，发现每个节点平均每13分钟就产生一个50M的归档日志，一天的归档日志就接近30G，而医院的日志放在本地磁盘，磁盘剩余空间也就100多G，按照这种日志的增长速度，空间被日志撑爆也就理所当然了。但是以该院的规模和业务量来看，产生这么多的日志肯定是不正常的，所以找到日志增长过快的原因，是解决问题的根本。
首先观察下归档日志产生的频率，我们取当天24小时产生日志的频率数，如下图：
f发现除了在上午业务高峰期（89点），其他时间段没有明显的曲线变化，而且凌晨时分（07点）的日志也切换频繁，这就肯定有问题，于是我生成今天2点3点的AWR报告进行分析，分析情况如下：
首先看该时间段的会话不多，只有60多个会话，除去系统自带的几个会话，真正应用ZLHIS的会话肯定不多，证明当时医院的业务肯定不繁忙。
f但是每秒钟的处理事务却有2382比很多三甲医院业务高峰期的事务都要大，肯定有问题，进一步分析执行sql：
发现即使在凌晨时分，居然也会如此频繁的执行大量的sql语句，其中涉及到update等DML语句，势必会产生大量归档日志，从表名看，应该是与体检系统有直接关系，通过分析，发现是zl_体检任务结果_Tra
satio
过程中的语句。该过程是实现把体检病人的检验结果更新到体检系统里面，我们程序有2种方式进行更新：1后台每天晚上定时对全院未完成体检的病人集中更新一次，通过调用zl_体检任务结果_Tra
satio
All实现，其中zl_体检任务结果_Tra
satio
All过程里面，又循环调用了zl_体检任务结r