技术分享 | 某银行核心数据库无法归档，Oracle数据库hang问题分析

本文为墨天轮数据库管理服务团队第108期技术分享，内容原创，作者为技术顾问肖杰，如需转载请联系小墨（VX：modb666）并注明来源。如需查看更多文章可关注【墨天轮】公众号。

一、问题概述

在线日志无法归档，全为active状态。客户跑批任务受到严重影响，客户临时增加多组在线日志，用于临时支撑业务继续运行。

同时发现节点1大量等待日志切换，同时也在等待节点2的日志切换，6：00左右尝试用正常方式关闭节点2数据库，但未成功，7：30左右对节点2强行关闭(shutdown abort), 关闭后，节点1的日志可以正常切换，数据库恢复正常。

二、问题原因

1、alert日志分析

节点1的alert日志在故障前后显示如下：

2：46左右开始出现cannot allocate new log，checkpoint not complete信息，

2：52左右开始出现MMON进程超时错误：useg scan erroring out with error:12751

经过检查，节点二日志输出基本相同。

2、ASH分析

通过ASH数据，可以看到故障期间内有非常多的log file switch(checkpoint incomplete)和enq:KI-contention等待事件。

3、存储检查

经过检查，确认存储并没有性能问题。

4、OS日志检查

通过检查message log，可以看到磁盘dm-4全是directory index full，说明此磁盘里面有海量的小文件，导致OS层的inode已经达到峰值。

通过磁盘映射，确认dm-4正是oracle安装目录，经过检查，发现存在海量的trace文件，节点1达到了七百多万个，节点2达到了八百多万个。

三、问题总结

抽查数个trc文件，经过检查，内容几乎都是一样，怀疑是触发了BUG，通过MOS搜索到BUG 29039510（Doc ID 29039510.8）的版本信息，track信息等都完全匹配。

1、因BUG 29039510（Doc ID 29039510.8），产生了巨量的trace文件，导致dm-4即oracle安装目录的inode耗尽，directory index full，系统运行缓慢。

2、由于当时在执行跑批任务，产生大量redo，由于inode耗尽，系统运行缓慢，dbwr进程写的速度远跟不上redo产生的速度，从而导致checkpoint无法完成，redo log除了current全是active状态，无法切换。同时根据alert日志输出minact-scn:useg scan erroring out with error e:12751，suspending mmon action undo usage for 104400 seconds，MMON进程在进行undo scan的时候超时。(参考文档DOS ID: 1478691.1)

3、后台囤积大量的log file switch（checkpoint incomplete）相关事件，及enq：KI-contention（一个节点等待另一个节点checkpoint完成）等待，节点间在互相等待checkpoint完成，shutdown abort 节点2，节点1恢复正常。

四、解决方案

1、根据跑批时日志切换频率（几秒切换一次），建议增加redo log组及单个redo log文件的大小（已经处理）。

2、设置event临时解决BUG（已经处理，确认trace文件无异常增长情况）：

alter system set event ‘trace [rac_enq] disk disable’ scope=spfile;

注意：应将已经设置过的event加进来，否则会覆盖已经设置的event，语法示例如下：

alter system set event=“10949 trace name context forever: 28401 trace name context forever, level 1: 44951 trace name context forever, level 32: trace [rac_enq] disk disable” scope=spfile;

3、做好trace，adump，incident等目录及alert日志的监控或自动清理脚本。

---

墨天轮从乐知乐享的数据库技术社区蓄势出发，全面升级，提供多类型数据库管理服务。墨天轮数据库管理服务旨在为用户构建信赖可托付的数据库环境，并为数据库厂商提供中立的生态支持。
墨天轮数据库服务官网：https://www.modb.pro/service