数据库学习案例20240426-记一次Oracle DG备库实例宕分析 主机节点inode满导致

一、问题概述

     同事反馈某库的XXX备库实例宕，尝试将该实例重启，结果重启报如下错误，未能正常启动该数据库。

Standby crash recovery failed to bring standby database to a consistent
point because needed redo hasn't arrived yet.
MRP: Wait timeout: thread 1 sequence# 0
Errors with log +DG/xxxx/archivelog/2021_12_29/thread_2_seq_24193.3766.1092589235
Standby Crash Recovery aborted due to error 16016.
Errors in file /u01/app/oracle/diag/rdbms/xxxx/xxxx/trace/xxxx_ora_67164.trc:
ORA-16016: archived log for thread 1 sequence# 22789 unavailable
Recovery interrupted!
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Completed Standby Crash Recovery.
Errors in file /u01/app/oracle/diag/rdbms/xxxx/xxxx/trace/xxxx_ora_67164.trc:
ORA-10458: standby database requires recovery
ORA-01196: file 1 is inconsistent due to a failed media recovery session
ORA-01110: data file 1: '+DG/xxxx/datafile/system.419.941189591'
ORA-10458 signalled during: ALTER DATABASE OPEN...

二、问题分析

首先查看了下问题发生时段的alert日志，在日志里看到了在数据库发生故障时所报的日志信息：

从日志里可以看到由于产生了ORA-1092 : opitsk aborting process报错，导致该数据库实例宕。此时就要去分析是什么原因导致产生ORA-1092报错。首先看了下报错时产生的/u01/app/oracle/diag/rdbms/xxxx/xxxx/trace/xxxx_diag_45155_20211229172002.trc文件，文件内容太多，格式化输出后也不太好排查，希望能从其它地方获取到一些价值信息。

首先在MOS上查询了 ORA-1092 : opitsk aborting process报错原因，MOS上讲该问题产生的原因也比较多，此时尝试看下操作系统日志，看下是否有什么价值的信息。

从操作系统的 /var/log/messages里，发现日志不停的有xxx-xxx-standby-db1 kernel: EXT4-fs warning (device sda2): ext4_dx_add_entry: Directory index full!这样的报错：

三、问题处理

于是通过find 结合 xargs 和rm 将两个实例下的审计文件大量删除，并配置了定时清理任务，后续观察了几天，innode已经由原来的89%降到了当前的34%，操作系统日志未在报index full满的报错信息，备库和主库的同步也正常。