某日中午，有用户陆续反映系统问题，说流程送出异常、待办不消失、待办打不开等等。维护工程师开始分析问题，后台较为清晰的现象是流转日志记录插入数据失败，人工测试表插入成功，其它现象五花八门，没有规律，经过多位维护工程师的努力，终于由Oracle数据库管理工程师在16：01排除故障，系统基本恢复“正常”。
故障原因是“应用系统Oracle数据库中Cordys用户所对应的表空间”满了，导致应用无法正常向数据库写入数据，造成业务数据不完整。
第二日，维护人员根据用户反馈，逐个流程处理，并公告所有用户，在故障时间段内容发起、处理的业务如有异常，请尽量重新发起流程办理，尽管这样，维护人员的电话也打爆了。
不幸的、担心的事情还是发生了，有用户反馈，新启动的流程有的也有异常！
了解这些情况后，我建议维护负责人，把Cordys服务停了，重启Oracle数据库。当晚下班，维护人员就按此方案操作。第三日系统恢复正常，维护人员继续处理故障数据，维护工程师研究故障数据范围。
经过上述过程，在规范IT运维管理环境下（分工明确：分一线、二线、三线人员及专业线分工），维护系统总结如下：
1、在一个上线多年，而且没有改动的情况下，出现了无规律异常现象，基本上可以定位是应用软件以外的问题，例如数据库系统、操作系统等，做为直接面对用户的软件维护人员在上报的同时，及时建议联系应用软件以往的维护人员；
2、对于此应用系统，如果出现表空间满了，出现数据写入故障时，特别是定位到是Cordys用户所对应的表空间满了的情况下，为了避免事态扩大，减少故障数据，需要立即做的工作如下：
1）、停止应用服务；
2）、处理数据库故障，例如扩表空间；
3）、重启数据库；
4）、启动应用服务（按重启处理）；
5）、测试、验证系统是否正常。
附：故障严重性说明
如附图所示，这是相关性3天的数据，统计工作时间内，按每整点、半点统计汇总，此前间隔30分钟时段内的待办任务处理量，非人工节点、特殊情况未统计在内。统计最近1周的11点到16点间的流程业务操作频次为3000-3500笔之间（还好，避开了高峰点），因此可估算出大致的故障数据范围。
基于Cordys C3版平台应用系统维护经验一则——Oracle数据库表空间满了,布布扣,bubuko.com
基于Cordys C3版平台应用系统维护经验一则——Oracle数据库表空间满了
原文：http://blog.csdn.net/xiaoyw71/article/details/26553267
