ORACLE强大的令人发指

作为一名混迹数据库江湖十几年的老 DBA，当你对关系型数据库的了解越来越深入时，你会发现，ORACLE 数据库真的是强大到令人发紫！

Oracle 数据库的强大，不仅体现在其对 ACID 的巧妙实现，其对高并发的完美支持，更重要的是他的可管理性，包括可度量、可回溯，以及出现问题后的问题核查接口和问题检查方法论，真是强大到令人发紫, 这是其他关系型数据库短期内还无法超越的。

问题来了！！！！

电话响了，是某银行一位熟悉的资深 DBA 的来电。

“在吗？现在应用连接数据库会 hang 住，sysdba 登陆也会 hang 住，无报错，该如何处理？”

没有往日的寒暄和客套，直入主题！

人的声音是有表情的，从电话那头急促的语气，不难判断，客户很着急。

可能有些朋友不清楚数据库登录 hang 住是怎样的一种现象，下图可以脑补一下：

 

也就是说，正常的登录是可以快速看到 “SQL>” 这样的提示符的，但出现异常时，就会长时间等不到 “SQL>” 这样的提示符, 这就是所谓的登录数据库会 hang 住。

看到这里，有些朋友开始激动了，要猜一下原因，试一下身手！

1）是不是数据库归档满了？

答：这… 归档满了，sysdba 登录会报 ORA - 归档错误相关的提示！而且注意细节，之前提到了，客户是资深的 DBA，显然这种可能性早就被排除掉了, 注意细节啊 ^_^

2）查一下等待事件，看看在等什么呢？

答：这… 数据库都连不进去了，怎么发出 SQL 来查询呢…

3）alert 日志有什么明显报错么？

答：在这个 case 中 alert 日志没有报错，也没有明显问题…

三板斧用完后，接下来不妨思考个两三分钟，如果是你，接下来你要怎么指挥这场战斗…

“别着急，你收两个 SSD 保存现场，然后杀掉 pmon，先恢复业务，然后把 SSD 的 trace 发我，我来做下 RCA！”

客户杀完 pmon 进程，数据库自动重启后，业务恢复正常。随后将 SSD 发了过来。

这里有些同学听到这些术语，有些摸不着头脑了：

什么是 SSD？固态盘（不会吧）？

还有什么是 RCA 呢？

这里给大家科普一下:

SSD 其实就是 System State Dump, 系统即时状态 DUMP 的首字母组合，

RCA 就是 Root Cause Analyze, 根因分析，是解决问题的难度要大许多，也有意思许多

为什么要收集 SSD 呢？

因为原因的不确定性，怎么能抓到蝴蝶效应中的那只蝴蝶呢？那就需要足够的信息!

多年前未掌握 SSD 这个功能的时候，出现问题，喜欢收集 v$session,v$session_wait,v$sqlarea,v$lock 等动态性能的相关信息，然后重启，但是后来往下分析的时候，发现少收集了什么信息，导致分析不顺利，后悔莫及…

当时就在想，Oracle 是否有一个一键收集的功能：

把想要的，不想要的，全都收集下来呢！答案就是 SSD。

甚至是当 sysdba 无法登陆时，Oracle 依然可以直接 attach 到共享内存，将内存中的即时状态全部抓取下来，包括系统当前各个进程正在执行什么、正在等什么、进城的堆栈等信息，真是强大大令人发紫的一个功能。

SSD 的收集非常简单，照敲就是了，以下是 SSD 收集的命令

### sqlplus -prelim "/as sysdba"

SQL>oradebug setmypid

SQL>oradebug dump systamstate 266

SQL>-- 等上 30 秒到 1 分钟

SQL>oradebug dump systamstate 266

SQL>oradebug tracefile_name

接下来就带领大家一起去分析 SSD，做根因分析，你会发现工作是一件多么有趣的事情。

1. 查看登陆进程在等什么

从 xxdb_ora_33030248.trc 中搜索 "waiting for" 可以看到：

 

可以看到：

1)有N 个进程都在等 LATCH:librarycache,latch, 并且 latch 是同一个即 70000006b9d8008

2) 1个进程在等 cursor:pin X，即在等待 cursor 类型的 mutex

3) latch 等待的时间已经长达达到 3723 秒

这里不难看出：

由于登陆的时候，要执行包括验证用户、获取权限等内部的 SQL（递归 SQL），但是在发出 SQL 后，由于长时间无法获取 latch:library cache 这样的资源，因此登陆看上去就像 hang 住了一样… 接下来，我们只需要找到无法 latch:library cache 的原因，就可以解开数据库 hang 住的真相了!

2. 第一次头脑风暴

看到这里，也许有同学迫不及待地又想再试试身手：

是不是硬解析的问题？

可以看到：

当客户端发出的 SQL 到达数据库的服务进程后，要先在 shared pool 中去找内存中是否存在该 SQL 和执行计划，如果存在则拿到执行计划直接执行即可。

那么 oracle 是如何查找的呢？就是对 SQL 文本计算 hash 值后，获取 latch:library cache（11g 中则采用 mutex 代替），对对应的链表进行扫描即可。

因此，软解析也会申请该 latch。

所以，不能说是简单的硬解析的问题，一切都有可能 。

BTW, 笔者面试过很多人，其实更想看到的是分析问题的方法论，而不是使劲的猜…

为什么呢？我们总会遇到很多经验范围之外的事情，怎么可能猜出自己不知道的事情呢？

3. 找原因，Orale 就是这么简单！

既然长时间无法获取 latch, 那么是谁在持有 latch 呢？

需要说明的是，当无法获取 latch:library cache 的时候,Oracle 在实现上，会将自己放到 latch 的等待者列表 waiter list 当中，那么自然也就有一个对应的持有者列表，

这么做的原因在于，当持有者使用完该 latch 后，到等待者列表中唤醒等待的进程即可。同时，Oracle 在做 SSD 的时候，就已经把持有者给打印到 trace 里了。

搜索 "waiting for 70000006b9d8008 Childlibrary"

可以看到 “possible holder pid = 19ospid=10027060”，即持有者是 pid = 19 ospid=10027060

 

接下来，我们需要去看看 latch 持有者即 pid = 19 ospid=10027060 的进程在做什么

4. 持有 latch 的人去哪了？

搜索 “ospid:10027060”，就可以看到 LATCH 持有者的进程的详细信息了

包括进程名，在执行什么 SQL，进程状态是什么，在等什么资源…

 

可以看到：

Pid=19,spid=10027060 的进程，是 ORACLE 的一个 JOB SLVAE 进程 j001,

由于他在持有 latch, 导致了很多进程需要等待，

holding (efd=5) 70000006b9d8008 Child library cache

乘胜追击，进一步查看该进程在等什么资源：

 

可以看到：

该进程对应的 SID 是 534，当前实际上并没有在等待任何资源，因为 last wait 表示的是上一次的等待了。长时间持有 latch:library cache, 导致 N 个进程登陆执行内部 SQL 的时候无法获取 latch, 继而无法登陆，但是，进程持有者 PID=19,SID=534，又没有在等待任何资源，SQL:0 表示当前没有在执行任何 SQL。

生无可恋了，那我怎么知道进程持有者在做什么呢，这还怎么往下查呢…

提示：这里请记住 latch 的持有者，SID 是 534,534！

5.陷入僵局

还记得么，Oracle 有一套方法论，那么方法论就是查看 call stack, 通过查看进程调用的函数轨迹，就可以判断出来，当前进入了哪一种场景。

但是由于客户一着急，收集的 SSD 的 level 不够，因为没有打印每个进程的 call stack！

这可如何是好啊, 难道问题要陷入僵局..

如果是你，接下来，会怎么往下打这一场仗

6.细节决定成败

如图所示：

 

红色加框部分显示，该进程的状态处于 DEAD 状态！即持有 latch 的那个进程已经死掉了！

看到这里:

有些朋友又要蒙圈了，“这是什么情况?”

有些朋友可能已经开始有点想法了，心里在嘿嘿乐…

没错，实际上，这已经设计到道和术的问题。

技术层面上，一路找到最终的阻塞者后，已经进行不下去了！

接下来，大家不妨停下来，思考一下：

原理层面呢？

学了那么多体系架构的东西，怎么用到生产问题中呢?

是否可以运用原理帮助解开这个数据库挂起的问题呢？

我面试候选 DBA 的时候，喜欢问原理。

很多候选 DBA 答不上来的时候，总喜欢解释道，而且是很坦然的解释到：

不好意思，过去从来不关注原理, 熟练操作就可以了！

听到这些回答，本人总会语重心长的让对方做一道故障题，不掌握原理是不可能解开的，结果很显然的，候选人自然答不上来，之后我会演示问题处理和分析过程，候选人往往都会重新定义对道和术的认知，孺子可教...

工程师熟练操作是基础，，但是从中级工程师到高级工程师，再到资深工程师，深入原理是一道坎，能将原理熟练应用到实际分析中又是一道坎。什么时候跨过坎了，层次也就不一样了。很多 DBA 因为没有人点拨，可能永远过不了那道坎…

7. 振聋发聩的一问！

为什么进程死掉了，但是进程还在持有 latch 资源不释放？

PMON 做什么去了？他是干什么吃的…

是的！这就是问题的关键！当听到这么一个振聋发聩的惊天一问时，恭喜你，跨过了一道坎！

如果已经提示到这个程度，依然无法发出这么一个疑问，实在是！

8. 看看 PMON 在做什么

搜索（PMON），就可以找到 SSD 中 PMON 进程的相关信息。如下所示：

 

可以看到：

PMON 正在等待 cursor:pin x，即申请模式为独占，类型为 cursor 的 mutex

waiting for 'cursor: pin X'

该 mutux 的 IDN 是 idn=ad39e34, 即 hash 值

由于 PMON 被阻塞, 卡住了，因此自然没有机会去清理死去进程所持有的 LATCH 了！

我们继续真相又进了一步！

只需要集中精力，需要继续到底是是哪个进程，持有了 idn=ad39e34 的 mutex, 导致 PMON 被长时间阻塞了，就可以解开问题的真相了！

接下来，大家不妨停下来，思考一下：

上图中， BLOCKING_SESS=0X0，这里无法直接查看是谁阻塞了 PMON 进程。

那么如果是你，你会怎么往下查呢

9. 谁阻塞了 PMON

由于 PMON 进程以独占方式申请

类型为 cursor 的 mutex 被阻塞，显然该 MUTEX 正在被某个进程以独享或独占方式长时间持有。这显然是不正常的。毕竟 MUTEX 是一种轻量级的资源。

接下来，我们在 TRACE 中搜索 "idn ad39e34 oper"，结果如下所示

Mutex 70000003eec4be0(534, 0) idn ad39e34 oper GET_EXCL

Mutex 70000003eec4be0(534, 0) idn ad39e34 oper EXCL

可以看到:

该 MUTEX 上有两个操作, OPER 即 Operation, 操作。

一个进程正在以独占方式持有, 即 oper EXCL

另外一个进程正以独占方式申请，oper GET_EXCL，Get 表示申请， 因此发生阻塞。该进程就是 PMON 进程。

红色底纹部分的 534，就表示 MUTEX 的持有者，即 SID=534！

没错！SID=534 就是我们之前持有 latch:library cache 资源但已经死去的进程！

就是那个等着被 PMON 清理的死去的进程！

10. 分析总结

综合上述分析，总结如下:

1) N 个进程无法登陆，是因为无法获得 latch:library cache 资源，该资源被一个死去的 SID=534 的进程持有了， 还没释放！

2) 按照原理，PMON 有义务去清理死去的 SID=534 的进程所持有的资源（latch 等）.

3) 但是 PMON 只有一个，PMON 正在等'cursor:pin X', 即以独占方式申请类型为 cursor 的 mutex. 所以腾不出手来清理死去的 SID=534 的进程.

4) 正是 SID=534 持有 MUTEX，阻塞了 PMON ！

假设说步骤 1,2 还合理的话，但是步骤 3 和 4 就毁三观了！

总结起来就一句话，PMON 要去给死去的进程收尸，但是要获得死去进程的同意！

这太不合理，太不科学了！为什么会这样呢…

很简单，命中 BUG！

11. 轻松找 BUG

分析到这里，掌握了问题的本质，那么找 BUG 起来就很简单了！

ORACLE 有一个强大的知识库，记录了全球客户提交过的 CASE，里面包含了 BUG 库！

怎么找到具体的 BUG 呢？

接下来不妨思考个 1 分钟，如果是你，接下来你要怎么定搜索关键字呢…

这里，以 “pmon cursor dead” 做为关键字（其他关键字也可以），检索 BUG。

很快，一个 BUG 的标题引起了注意：

Bug 8426816 PMON may hang cleaning up a dead process (rare)

点开 BUG，描述如下：

 

怎么样，看完了吧，这不就是我们这个问题么！

an instance hang may result due to PMON getting

blocked when attempting to clean up a failed process.

从现象到问题本质完全吻合！版本 10.2.0.4 也完全吻合！

当 PMON 要以 X 模式即独占模式申请 MUTEX（cursor:pin X 就是一种 mutex）去清理一个死去进程的时候，该 MUTEX 被死去进程持有！从而导致了数据库 HANG 的情况！

问题原因与经验总结

故障过程总结:

1) SID=534 的进程在持有 latch:library cache 和 mutex 等资源的时候进程死去

2) PMON 有义务清理该进程所持有的资源，如 mutex

3) 由于命中 BUG 5377099 ，导致 PMON 无法获得 MUTEX，被死去的进程 534 阻塞

4) 因此 SID=534 的死去进程长时间持有 latch:library cache, 导致其他用户执行递归

SQL，无法被软解析，继而无法登陆，即数据库出现了 HANG 的故障！

经验总结：

1) 运维公式 = 快速收集系统即时状态信息 + 恢复业务

2) 快速收集系统即时状态信息的目的是做 RCA，根因分析，以便在大规模数据库运维中可以预防其他数据库也出现类似问题。

3) 不定期做补丁分析，发现严重的 BUG，提前预防。

4）技巧重要，原理更重要。

通过这样一个案例，你不难发现，ORACLE 的 SSD 功能，真是强大的令人发指！