首页 > 代码库 > 基于Cordys C3版平台应用系统维护经验一则——Oracle数据库表空间满了

基于Cordys C3版平台应用系统维护经验一则——Oracle数据库表空间满了

        某日中午,有用户陆续反映系统问题,说流程送出异常、待办不消失、待办打不开等等。维护工程师开始分析问题,后台较为清晰的现象是流转日志记录插入数据失败,人工测试表插入成功,其它现象五花八门,没有规律,经过多位维护工程师的努力,终于由Oracle数据库管理工程师在16:01排除故障,系统基本恢复“正常”。

        故障原因是“应用系统Oracle数据库中Cordys用户所对应的表空间”满了,导致应用无法正常向数据库写入数据,造成业务数据不完整。

        第二日,维护人员根据用户反馈,逐个流程处理,并公告所有用户,在故障时间段内容发起、处理的业务如有异常,请尽量重新发起流程办理,尽管这样,维护人员的电话也打爆了。

        不幸的、担心的事情还是发生了,有用户反馈,新启动的流程有的也有异常!

        了解这些情况后,我建议维护负责人,把Cordys服务停了,重启Oracle数据库。当晚下班,维护人员就按此方案操作。第三日系统恢复正常,维护人员继续处理故障数据,维护工程师研究故障数据范围。

         经过上述过程,在规范IT运维管理环境下(分工明确:分一线、二线、三线人员及专业线分工),维护系统总结如下:

         1、在一个上线多年,而且没有改动的情况下,出现了无规律异常现象,基本上可以定位是应用软件以外的问题,例如数据库系统、操作系统等,做为直接面对用户的软件维护人员在上报的同时,及时建议联系应用软件以往的维护人员;

         2、对于此应用系统,如果出现表空间满了,出现数据写入故障时,特别是定位到是Cordys用户所对应的表空间满了的情况下,为了避免事态扩大,减少故障数据,需要立即做的工作如下:

         1)、停止应用服务;

         2)、处理数据库故障,例如扩表空间;

         3)、重启数据库;

         4)、启动应用服务(按重启处理);

         5)、测试、验证系统是否正常。


        附:故障严重性说明

        如附图所示,这是相关性3天的数据,统计工作时间内,按每整点、半点统计汇总,此前间隔30分钟时段内的待办任务处理量,非人工节点、特殊情况未统计在内。统计最近1周的11点到16点间的流程业务操作频次为3000-3500笔之间(还好,避开了高峰点),因此可估算出大致的故障数据范围。