ORACLE强大的无法无天

可以看得见：

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，即注册Mode为相互竞争，多种类型号为 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 Mode即相互竞争Mode注册 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 机制，真是有力的难以置信推指！