记录一则ASM实例阻塞，rbal进程异常的案例

时间：2023-11-10 11:46:38

1.故障现象描述

**环境：**AIX 7.1 + Standalone Oracle 11.2.0.4
**现象：**客户反映某11g版本的ADG备库无法正常进行任何查询，数据库alert发现ORA-00494：enqueue [CF] held for too long (more than 900 seconds) by 'inst 1, osid 18875390'.

2.确认故障现象

登录到db实例，尝试查询select open_mode from v$database都会hang住。使用10046 event跟踪，发现最后的等待事件也是卡在'Disk file operations I/O'不再刷新。
该环境是standalone的单实例ASM环境，既然卡在I/O，自然就要去判断ASM是否正常。

3.排查ASM层面

发现ASM实例确实存在阻塞：

--cascade blocking

select *

  from (select a.sid,

               a.sql_id,

               a.event,

               a.status,

               connect_by_isleaf as isleaf,

               sys_connect_by_path(SID, '<-') tree,

               level as tree_level

          from v$session a

         start with a.blocking_session is not null

        connect by nocycle a.sid = prior a.blocking_session)

 where isleaf = 1

 order by tree_level asc;

记录一则ASM实例阻塞，rbal进程异常的案例

其中417是rbal进程，等待事件是CSS operation：action。

4.解决问题

首先查找MOS时匹配到下面的文档：
ASM Instance Hangs During The Diskgroup Mount Stage After AIX OS Patch Install (文档 ID 1633273.1)

根据该文档中的描述收集hanganalyze/systemstate dumps:

Collected hanganalyze/systemstate dumps:

For Standalone:

$> sqlplus /nolog

SQL> connect / as sysasm

SQL> oradebug setmypid

SQL> oradebug unlimit

REM : The next line should give something like Hang Analysis in $ORACLE_BASE/diag/.../trace/$ORACLE_SID_diag_<pid>.trc. Upload this

REM : Run the following two lines on one instance 2-3 times - 1 minute apart:

SQL> oradebug hanganalyze 3

SQL> oradebug dump systemstate 258

REM : The following line will print the location for the systemstate trace. Upload this

SQL> oradebug tracefile_name

REM : Also upload the instance alert log.

根据收集到的trc文件和MOS描述的故障现象进行匹配，无论是ssd的等待事件历史，还是hanganalyze中显示的函数调用名称和顺序，结果都与MOS的描述一致。但是MOS描述的现象还明确提出是在安装了一个OS的patch后才出现的故障：

SYMPTOMS

non-clustered -- 11203 -- AIX 7.1

ASM instance hangs and will not mount diskgroups, after AIX OS patch was installed (AIX 7.1TL03-01-1341).

This is a platform specifc issue.

那么就需要与客户沟通确认OS是否安装了这个AIX 7.1TL03-01-1341 patch，最终结果意料之中，客户确认了OS的确安装过该补丁。

那么MOS其实没有workaround，只给出最终的解决方案：

SOLUTION

Deinstall the OS patch and report the issue to the OS vendor.

Oracle does not certify OS patches against its software.

意思很明显，就是需要卸载该OS补丁并把该问题提交给OS vendor，Oracle不能保证OS的补丁不与自己软件冲突。到了这里，就可以告知客户将该问题push给OS vendor了。

可是目前还是要先暂时解决当前的问题，现在既然确认是ASM实例阻塞，自然就想到只需要将阻塞进程杀死或者干脆重启ASM实例甚至has集群即可暂时解决。

但实际上事违人愿，我在尝试杀死这个rbal进程时，发现即使使用kill -9也无济于事。并且即使将ASM实例成功abort后，这个rbal进程依然在，进一步尝试直接强制关闭crsctl stop has -f集群也无法成功。看来目前的环境已经完全表现异常，最终还是重启了主机才恢复正常。

相关文章