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

• 1.故障现象描述
• 2.确认故障现象
• 3.排查ASM层面
• 4.解决问题

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;

其中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集群也无法成功。看来目前的环境已经完全表现异常，最终还是重启了主机才恢复正常。