小机上运行ORACLE需要注意的进程调度BUG

DBA小y

前  言

小y这个名字，是我临时想的一个笔名，以后索性也就用这个名字和大家分享一些我们的技术人生故事吧。

小y给接下来即将分享的一系列故事，起了个名字，叫技术人生，以此来缅怀自己的Oracle DBA生涯.

今天要分享的是一个应用间歇性局部挂起的案例。

01.  问题描述

据客户反映，应用会间歇性出现异常，包括insert单条记录在内的操作长时间无法完成，按照客户的说法，数据库内可能有“死锁”现象，希望能够找到问题发生的根因，提出解决方案，以避免问题再次发生。

2015年12月23日，问题再次发生，客户再次联系到小y,小y通过远程方式进行了信息收集和故障诊断，最终定位了问题的根本原因。

环境介绍：

操作系统 HPUX IA64 B.11.31 数据库 ORACLE 10.2.0.5,单实例

2分析过程

>>> 2.1 异常时刻数据库出现异常等待

可以看到：

有2个会话在等待行锁（拿不到事务锁，需要一直等待）

另外有一个会话在等待“undo segment extension”

>>>> 2.2 梳理异常等待之间的关系

1）分析行锁等待的阻塞者

可以看到：

SID 285/290的两个会话都是被SID=315的会话阻塞了，他们在等待行锁，时间已经超过60000秒

2）查看阻塞者SID=315在做什么

可以看到：

SID=315的会话阻塞了其他两个会话，

他本身也处于一个资源的等待上，在等待“undo segment extension”,已经等了70384秒了！该等待事件没有阻塞者。

3）SID=315在执行的SQL语句

>>>> 2.3 什么是“undo segment extension”等待事件

“undo segment extension”即等待回滚段扩展完成。当执行增删改等操作时，数据库需要回滚段来存储前镜像，当回滚段空间不足时，则需要扩展。

具体来说，undo segment的扩展或者回收（extend / shrink）都是前台进程通过通知SMON后台进程来完成的。

发出下列命令查看undo的使用情况，

UNDO表有空有1个文件27750M，其中

目前活动的值有8M，未过undo retention的1892M，过了undo retention的有40M

未发现异常。

>>>> 2.4 收集数据库hanganalyze和systemstate信息

发出下列命令异常时候的hanganalyze和systemstate信息

SQL> oradebug setmypid Statement processed. SQL> oradebug hanganalyze 3 Hang Analysis in /oracle/admin/xxdb/udump/xxdb_ora_14136.trc SQL> SQL> oradebug dump systemstate 266 Statement processed. SQL> oradebug tracefile_name /oracle/admin/xxdb/udump/xxdb_ora_14136.trc

>>>> 2.5 问题在收集信息后自动解决

在发出上述命令收集相关信息后，再次检查，发现数据库异常等待居然已经自动解决掉了。

从原理和经验分析，这是因为oradebug 在收集systemstate dump时，其中会调用dbx等OS命令去做进程堆栈的打印，此时会将进行wakeup(唤醒)。

如下所示

>>>> 2.6 获得SID：315会话的活动会话历史

可以看到，确实一直在等待undo segment extension

>>>> 2.7 分析systemstate dump定位问题根因

其中SID=315的会话在等待”undo segment extension”,该会话对应PROCESS 19

SSD当中的信息如下

之所以执行不下去，不是因为死锁，而是因为该会话即SID=315的会话,需要执行DML，

因此需要UNDO SEGMENT即回滚段来存储前镜像，但发现回滚段空间不足，需要通知SMON后台进程来完成扩展的请求,但是长时间没有获得回滚段扩展成功与否的返回消息。前台进程和SMON之间通过POST/WAIT进制来通讯。

由于操作系统HPUX调度的缺陷，具体来说是pw_wait系统调用(post/wait)存在缺陷，当SMON进程完成回滚段扩展后，消息返回时，前台进程SID=315并没有能被及时调度到CPU上继续处理后续工作，即体现出来就是等待在“undo segment extension“事件上等待，当我们人为使用ORADEBUG对SID 315收集信息并间接唤醒了该前台进程后，前台进行可以继续往下工作，这更加印证了SMON已经将消息已经返回给前台进程，只是由于操作系统调度进制的问题，未能即使将前台进程调度到CPU上，拿到UNDO扩展成功的消息

造成该故障的根本原因是操作系统调度机制的问题，该问题命中操作系统HPUX上的已知缺陷。

>>>> 3.2 建议

Solution: on 11.31 install PHKL_38397 or later equivalent.

请系统管理员为操作系统安装PHKL_38397补丁