一分钟查一个案例带你看看Oracle数据库到底有多牛逼性能难题

一分钟查一个案例带你看看Oracle数据库到底有多牛逼

性能难题

问题来了

电话响了，是一位证券客户 DBA 的来电，看来，问题没过两天，又出现了。

接起电话，果不其然。

“小y,前天那个问题又重现了。重启后恢复正常，这次抓到了hangAnalyze,不过领导在身后一直催，所以没来得及抓取 systemstate dump 就重启了。你尽快帮忙分析下吧，hanganalyze 的 trace 文件

已经转到你邮箱了。”

就在 2 天前，该客户找到小 y, 他们有一套比较重要的系统出现了数据库无法登陆的情况，导致业务中断，重启后业务恢复，但原因未明，搞的他们压力很大。

可惜的是，他们是事后找过来，由于客户现场保护意识不足，最后也只能是巧妇难为无米之炊了…

总的来说，小 y 还算是比较熟悉证券行业的。

毕竟，小 y 多年来一直在银行、证券、航空等客户提供数据库专家支持服务，这其中就包括了北京

排名前 6 的所有证券公司。

简而言之，证券行业的要求就是快速恢复，快速恢复业务大于一切。

原因很简单，股价瞬息万变，作为股民，如果当时无法出售或者购买股票，甚至可能引发官司。所以，证券核心交易系统如果中断时间超过 5 分钟，则可以算得上是严重故障了，一旦被投诉，则可能会

被证监会通报，届时业务可能被降级，影响到证券公司的经营和收益。

结合这个特点，小 y 为客户制定了应急预案，看来收集 systemstate dump 是来不及了，只能先

收集 hangAnalyze, 时间来得及的话则可以继续收集 systemstate dump。收集 hangAnalyze 的命令

很简单，照敲就是了，没什么技术含量。

$sqlplus –prelim “/as sysdba”

SQL>oradebug setmypid

SQL>oradebug hanganalyze 3

.. 此处等上一会 ..

SQL>oradebug hanganalyze 3 SQL>oradebug

tracefile_name

开启分析之旅

1、hanganalyze 初体验

打开附件，内容如下，中间部分太长了，所以用省略号代替。

朋友们，不妨自己停下来，耐心阅读一下，看

看是否可以看的明白。

很快，根据这个 trace, 小 y 在一分钟找到了问

题原因。

而这种问题，在其它数据库中属于很难查清的

问题。

所以不得不说，Oracle 的 hangAnalyze 是如

此的牛逼…

问题原因就在后面，什么时候往下翻，由你决

定…

2、如何开始

先看 trace 的第一部分，如下所示：

上面的信息为出现异常时数据库的整体状态摘要，这些信息表示：

1）共 76 个会话被 sid=494 的会话阻塞，原因是 sid=494 的会话本身申请 latch: shared pool

资源时被其他会话阻塞。

2）共 22 个会话被 sid=496 的会话阻塞，原因是 sid=496 的会话本身申请 latch: shared pool

资源时被其他会话阻塞。

3）共11个会话被sid=598的会话阻塞，”No Wait”表示sid=598的会话本身并未等待任何资源，即该进程在使用 CPU。

4）共 13 个会话被 sid=518 的会话阻塞，原因是 sid=518 的会话本身申请 latch: shared pool 资源时被其他会话阻塞。

用一张图来表示，如下所示：

3、找到阻塞的源头

会话 494、496、598、518 之间可能相互独立，也可能存在互相阻塞的关系。

小 y 带着大家继续往下梳理。

从抓取到的 hanganalyze 信息摘取上述会话信息的细节，如下所示 :

在该信息中，关注 4 列的内容即可，其中：

第 1 列为 oracle 给 trace 中每一个会话所取的唯一逻辑标识；

第 3 列表示会话 sid；

第 6 列表示操作系统进程号；

第 10 列表示阻塞该会话的唯一逻辑标识，为空时表示无阻塞。

因此，从上述信息可知：

1)sid=494 的会话被唯一逻辑标识为 597 的会话阻塞

2)sid=496 的会话被唯一逻辑标识为 597 的会话阻塞

3)sid=518 的会话被唯一逻辑标识为 597 的会话阻塞而唯一逻

辑标识为 597 的会话信息为 :

即唯一逻辑标识为 597 的会话的 sid=598, 操作系统进程号 553382，该行的第 10 列为空，即再也没有其他会话阻塞 sid=598 的会话。

也就是说，sid=598 的会话就是数据库异常时的会话获取资源时阻塞的源头。如下图所示：

4、陷入僵局？（阻塞的源头只是一个数字！）

前面的分析，已经找到了源头是 SID=598 的会话。

那么 sid=598 的会话是什么用户什么程序什么机器发起，在执行什么 SQL，进程的 callstack 是什么呢？所有这些信息，我们都可以在systemstate dump 中可以找到，但可惜的是，客户虽然由于时间关系没有来得及抓取 systemstate dump，因此无法进一步获取该进程的信息。

悲剧了！难道要再一次陷入巧妇难为无米之炊的尴尬境地么？如果是你，你会怎么办，此处不妨思考几分钟…

5、找到打开天堂大门的钥匙

打开天堂之门的钥匙有很多把，但上帝总是会眷恋把握细节和用心的人。难道因为缺少systemstatedump 就放弃了么？那客户怎么办？

这里介绍其中一把钥匙，当然还有其他钥匙，如果你也找到了其他钥匙，不妨留言告诉小 y。继续看阻塞源头的相关信息。

SID=598 的会话，在操作系统上的进程号是 553382。

一个进程要么是前台进程（服务进程），要么是后台进程。

如果是后台进程，则我们可以在 alert 日志中，找到操作系统上进程号是 553382 对应的后台进程到底是什么！

打开 alert 日志，果然不出所料，凶手真的是他

如下所示 :