一、故障背景
本次故障涉及一套 Oracle 11g RAC 双实例环境。以下内容已对实例名、主机名、库名、IP、路径中的业务库名做脱敏处理。
- 数据库名称：PRODDB
- 实例 1：proddb1，运行在 dbnode1
- 实例 2：proddb2，运行在 dbnode2
- 数据库版本：Oracle Database 11.2.0.4.0 RAC
- 存储方式：ASM
- 数据文件与 redo：位于 +DATA_DG 磁盘组
- 审计目录：/opt/oracle/admin/PRODDB/adump
业务侧现象：业务程序无法正常使用。
从表现上看，最直接的怀疑方向是数据库异常或性能问题，因此运维人员做了重启操作。但复盘后发现，重启是不可用发生后的应急动作，并非故障起点。
二、故障现象
业务不可用期间，数据库 alert log 中持续出现以下错误：
ORA-09925: Unable to create audit trail file
Linux-x86_64 Error: 28: No space left on device
ORA-15055: unable to connect to ASM instance
ORA-17503: ksfdopn:2 Failed to open file +DATA_DG/PRODDB/onlinelog/group_3.xxxxx.xxxxx
Master archival failure: 313
在 proddb2 重启过程中，alert log 还记录了：
ORA-01013: user requested cancel of current operation
Shutting down instance (immediate)
Shutting down instance: further logons disabled
kkjcre1p: unable to spawn jobq slave process, slot 2, error 1089
USER (ospid: xxxxx): terminating the instance
ORA-1092 : opitsk aborting process
Starting ORACLE instance (normal)
这两批日志混在一起，容易产生误判。拆开来看：
第一类——故障本身的异常：
ORA-09925 / Linux Error 28 / ORA-15055 / ORA-17503 / Master archival failure
第二类——重启过程的伴随现象：
ORA-01013 / shutdown immediate / error 1089 / ORA-1092 / Instance terminated by USER
复盘的核心原则是：先把这两类分开，再找初始原因。
三、是否是数据库性能问题？
业务不可用的第一反应往往是数据库慢、CPU 高、IO 高、锁等待、RAC 互联抖动之类。但这个方向很快被排除了。
分别拉了 dbnode1/proddb1 和 dbnode2/proddb2 的 AWR/ADDM，两个实例表现相近：平均活跃会话低，DB Time 低，CPU、Network、Cluster、User I/O 均不突出，集群互联延迟也在正常范围。
结论：本次业务不可用与数据库性能无关，可以跳过这个方向，重点看可用性和基础环境。
四、关键线索：ORA-09925 与 Linux Error 28
日志里反复出现的这两行是本次故障的核心：
ORA-09925: Unable to create audit trail file
Linux-x86_64 Error: 28: No space left on device
ORA-09925 说明 Oracle 无法创建审计文件。Linux Error 28 是操作系统返回的 ENOSPC，即"设备上没有剩余空间"。
这里需要注意，ENOSPC 不一定是磁盘容量满了，还可能是：
- inode 耗尽
- 某个文件系统短时写满
- 删除的文件仍被进程持有，空间未实际释放
- 故障后经过处置或重启，现场已恢复正常
Oracle 本地审计目录是 /opt/oracle/admin/PRODDB/adump。即便参数配置了 audit_trail=DB，SYSDBA 登录、后台进程等场景仍会写 OS 审计文件，adump 必须始终可写且能持续创建新文件。
一旦审计文件写不进去，后续问题就是连锁的：
Oracle 创建审计文件失败
↓
ORA-09925 / Linux Error 28
↓
数据库进程访问 ASM 失败
↓
ORA-15055: unable to connect to ASM instance
↓
打开 +DATA_DG 上的 online redo log 失败
↓
ORA-17503
↓
归档异常 / 后台进程异常
↓
业务连接断，业务不可用
五、数据库重启日志不是初始根因
业务不可用后，运维对 proddb2 做了重启。
Shutting down instance: further logons disabled 说明进入 shutdown immediate 后新登录已被禁止。
kkjcre1p: unable to spawn jobq slave process, slot 2, error 1089 中的 1089 是关闭过程中禁止新操作的正常表现，job queue slave 在这个阶段创建不了是预期行为。
最后 shutdown immediate 没有快速完成，由用户进程强制终止实例，随后重启。
简单说，这条时间线是：
业务已不可用
↓
人工执行 shutdown immediate
↓
shutdown 未快速结束
↓
强制终止实例
↓
数据库重新启动并恢复
这批日志记录的是处置过程，不应作为根因分析的起点。
六、现场排查过程
1. 检查磁盘容量
两台节点执行 df -h：
- dbnode1 根分区使用率约 44%
- dbnode2 根分区使用率约 43%
当前磁盘块空间未满。
2. 检查 inode
两台节点执行 df -i：
- dbnode1 根分区 inode 使用率约 33%
- dbnode2 根分区 inode 使用率约 46%
当前 inode 也未满。
3. 检查系统日志
在故障节点执行：
grep -iE "No space left|ENOSPC|inode|EXT4-fs|XFS|read-only|I/O error" /var/log/messages*
grep -iE "No space left|ENOSPC|inode|EXT4-fs|XFS|read-only|I/O error" /var/log/dmesg*
dmesg | grep -iE "No space left|ENOSPC|inode|EXT4-fs|XFS|read-only|I/O error"
未发现文件系统只读、I/O error 或系统层 ENOSPC 记录。
这不等于否定 Oracle 日志里的 ENOSPC——普通文件创建失败通常不会写到 /var/log/messages，而是由应用自己记录。Oracle alert/trace 里已经有明确的 ORA-09925 和 Linux Error 28。
4. 检查 deleted open files
两台节点执行 lsof +L1，确实存在部分已删除但仍被进程持有的文件，主要是 Grid Infrastructure 日志和少量 trace 文件，单个约 10MB 或更小。
这个量级不足以造成大规模空间耗尽，"删除文件未释放"这个方向没有强证据。
5. 检查 adump 目录是否可写
两台节点分别测试：
touch /opt/oracle/admin/PRODDB/adump/test_write_$(date +%s).aud namei -l /opt/oracle/admin/PRODDB/adump
均成功，目录链路权限正常，当前可写。
6. 检查 adump 文件数量
发现文件数量明显偏多：
- dbnode1：约 33 万个文件，占用约 1.3G
- dbnode2：约 42 万个文件，占用约 1.7G
这是长期未清理的结果。进一步按日期统计：
cd /opt/oracle/admin/PRODDB/adump
find . -type f -name "*.aud" -printf "%TY-%Tm-%Td\n" \
| sort | uniq -c | sort -k2
统计显示两台节点每天稳定产生 640–760 个 .aud 文件，故障日前后没有异常暴增：
dbnode1:
2026-04-28 685
2026-04-29 671
2026-04-30 315
dbnode2:
2026-04-28 702
2026-04-29 689
2026-04-30 320
因此，adump 确实存在运维隐患，但不能简单认定为"当天暴增导致 inode 瞬时耗尽"。
七、根因判断
已确认的直接触发点
故障时 Oracle 反复无法创建本地审计文件，操作系统返回 ENOSPC：
ORA-09925: Unable to create audit trail file
Linux-x86_64 Error: 28: No space left on device
由此引发 ASM 连接失败、online redo log 打开失败、归档异常，最终导致业务访问失败。
已排除或证据不足的方向
- 数据库 CPU/内存/IO 性能瓶颈
- RAC Cluster 互联异常
- SQL 性能问题
- 当前磁盘块空间耗尽
- 当前 inode 耗尽
- 当前 adump 目录权限异常
- 大型 deleted 文件占用
- 故障日审计文件异常暴增
更准确的根因表述
本次故障的直接触发点是 Oracle 创建本地 audit trail 文件时收到操作系统 ENOSPC，引发 ORA-09925，并连锁导致 ASM 连接失败、online redo log 打开失败和归档异常，最终造成业务访问不可用。
事后检查显示磁盘、inode、目录权限、deleted open files 均无持续异常；adump 存在历史文件堆积，但故障日无暴增。ENOSPC 的具体来源——是短时空间异常、其他目录增长、临时文件占用，还是处置过程中已释放——需结合故障时的监控数据和整机目录增长趋势进一步追踪。
八、处置过程
应急处置
业务不可用后，对 proddb2 执行了重启。重启过程中的 ORA-01013、ORA-01089、ORA-1092 是停启库的伴随现象，不是初始根因。
审计目录清理
已清理 365 天以前的历史审计文件：
find /opt/oracle/admin/PRODDB/adump -mtime +365 -name "*.*" -exec rm -rf {} \;
后续建议改为更精确的形式，只清理 .aud 文件：
find /opt/oracle/admin/PRODDB/adump -type f -name "*.aud" -mtime +365 -delete
也可根据留存要求缩短到 180 天或 90 天：
find /opt/oracle/admin/PRODDB/adump -type f -name "*.aud" -mtime +180 -delete
九、整改建议
1. 建立 adump 定期清理机制
两台节点都配置 crontab，每周清理一次，例如保留 180 天：
30 2 * * 0 find /opt/oracle/admin/PRODDB/adump -type f -name "*.aud" -mtime +180 -delete
如果留存要求允许，也可以缩短到 90 天：
30 2 * * 0 find /opt/oracle/admin/PRODDB/adump -type f -name "*.aud" -mtime +90 -delete
2. 增加磁盘与 inode 监控
建议覆盖以下指标：
- /、/opt、/opt/oracle 使用率
- inode 使用率
- adump 文件数量及日增长量
- diag 目录大小
- Grid 日志目录大小
- deleted open files 总大小
告警阈值建议：
- 磁盘/inode 使用率 > 80% 告警，> 90% 严重告警
- adump 文件数 > 50 万告警
- adump 单日增长超历史均值 3 倍告警
3. 定期巡检 adump 增长趋势
每日查看最近 7 天增长量：
find /opt/oracle/admin/PRODDB/adump -type f -name "*.aud" -mtime -7 \
-printf "%TY-%Tm-%Td\n" | sort | uniq -c | sort -k2
小时级分析：
find /opt/oracle/admin/PRODDB/adump -type f -name "*.aud" -mtime -3 \
-printf "%TY-%Tm-%Td %TH\n" | sort | uniq -c | sort -k2
4. 扩大到整机 Oracle/Grid 目录排查
由于 PRODDB/adump 故障日没有突增，后续还需要排查整机其他目录：
du -xhd2 /opt/oracle/diag | sort -h | tail -30 du -xhd2 /opt/grid | sort -h | tail -30
检查所有数据库实例的 adump：
find /opt/oracle/admin -type d -name adump -exec sh -c '
for d do
echo "==== $d ===="
du -sh "$d"
find "$d" -type f | wc -l
done
' sh {} +
重点关注：其他数据库实例、ASM、Grid Infrastructure、listener、CRS/OHASD/oraagent 日志。
5. 将审计目录独立挂载
如果条件允许，建议将 /opt/oracle/admin/PRODDB/adump 单独挂载到独立文件系统。这样审计文件就算异常增长，也不会波及 /opt/oracle、trace 目录或 Grid 组件。
十、经验总结
重启日志不等于根因。 业务不可用在前，数据库重启在后——alert log 里的 ORA-01013、ORA-01089、ORA-1092 只是处置过程的记录，不能反推成初始故障原因。分析时要先确认业务不可用的时间点，再对照日志时序拆分。
AWR/ADDM 适合快速排除性能方向。 两个实例 DB Time 和平均活跃会话都很低，CPU、Network、Cluster、User I/O 均不突出，这种情况下应该快速切换到"可用性/基础环境"方向，不要在性能调优上耗时间。
ORA-09925 值得高度重视。 它不是普通的应用报错。一旦 Oracle 无法写审计文件，可能影响登录、后台进程、ASM 访问乃至实例启动。看到 ORA-09925 + Linux Error 28 + ORA-15055 + ORA-17503 的组合，第一反应应该是检查本地文件系统、inode、adump、diag、Grid 日志和 deleted open files。
事后 df -h 正常不代表故障时没问题。 短时耗尽、瞬时 inode 满、日志暴涨、deleted 文件占用，都可能在处置或重启后自动恢复。事后检查只能说明当前状态，不能替代故障时的监控数据。
小文件长期堆积是隐性风险。 adump 三四十万个文件虽然只占 1–2GB，但说明清理机制缺失。这类问题平时没什么存在感，一旦叠加其他因素，就会成为故障的放大器。
十一、结论
本次业务不可用不是数据库性能问题，也不是 RAC 互联或 ASM 磁盘组故障。
故障期间 Oracle 创建本地 audit trail 文件时收到操作系统 ENOSPC，触发 ORA-09925，并连锁引发 ASM 连接失败、online redo log 打开失败和归档异常，最终导致业务数据库访问失败。
数据库重启是应急处置动作，重启过程中的 ORA-01013、ORA-01089、ORA-1092 是伴随现象，不是初始根因。
事后检查显示磁盘、inode、目录权限和 deleted open files 均无持续异常；PRODDB/adump 存在大量历史堆积，但故障日没有异常暴增。直接触发点可以确认，ENOSPC 的具体来源仍需结合故障时监控和整机目录变化继续追踪。
