一个编译存储过程HANG住的问题分析

白鳝的洞穴 2020-06-04

763

今天老白在一个客户这边交流系统优化的事情。开发商、运维人员、集成公司的人员在一起讨论，大家都深感出了问题就互相推诿的弊端。于是一高兴，从早上9点聊到中午12点半，肚子都有点饿了才有人想起来到中午了。于是今天的这篇稿子只能现在腾出空来写了。

这是老白翻出来的一个很古老的案例了，不过这种问题现在偶尔也会发生。重点在于如果遇到这类问题，如何去快速定位分析。

闲话少叙，直接进入正题。问题的现场是用户在编译某个存储过程时候HANG死，编译其他存储过程的时候没问题。我开始让他看看V$SESSION里面的BLOCKING会话。他告诉我，这套数据库十分古老，是8.1.7的。于是我让他做下面的分析：

1、查找hang住对象，通过v$access查找当前正在访问这个对象的会话

select SID,OBJECT from v$access where object like 'PKG%'

SID OBJECT

--- --------------------------

141 PKG_CREATE_BASIC_MID_DAY2

2、查找这个对象正在等待的事件，发现这个会话在等待library cache pin，和我们看到的现象十分一致。于是可以采取进一步分析工作。

select SID, EVENT, STATE from v$session_wait where sid = 141;

SID EVENT STATE

--- ---------------- ------------

141 library cache pin WAITING

3、这种情况下，做一个HANGANALYZE有助于快速定位HANG的情况。

oradebug hanganalyze 3;在HANGANALYZE报告中，发现48号进程是阻塞者。

4、查找SESSION和相关的操作系统进程

select STATUS, PROCESS from V$SESSION where sid = 48 ;

----- ---------

KILLED 7856

问题真相大白了，因为这个进程相关会话被杀掉了。但是由于某种原因，这个进程的进程还没有退出。导致该会话持有的闩锁没有释放，HANG住了系统。只要在操作系统层面把这个进程杀掉，就可以解决这个问题了。

从Oracle10g开始，V$SESSION里面多了BLOCKING SESSION的信息，要想分析这些问题就十分容易了。特别是在ASH里有相关的历史数据，进行历史分析也十分容易。

select sid,blocking_session,blocking_instance,blocking_session_status from v$session;

我们很容易就能获得阻塞者的信息。并根据阻塞者的情况采取相关的措施。自己编写一个等待事件链分析工具，针对V$SESSION或者V$ACTIVE_SESSION_HISTORY视图进行分析，就可以获得你所需要的明确信息了。

最后修改时间：2020-06-05 09:36:10

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。