您的当前位置：聋症 > 聋症诊断 > Oracle数据库强大到令人发指是的，
Oracle数据库强大到令人发指是的，
点击上方“ITPUB”一起玩耍哦~
作为一名混迹数据库江湖十几年的老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其实就是SystemStateDump,系统即时状态DUMP的首字母组合，
RCA就是RootCauseAnalyze,根因分析，是解决问题的难度要大许多，也有意思许多
为什么要收集SSD呢？
因为原因的不确定性，怎么能抓到蝴蝶效应中的那只蝴蝶呢？那就需要足够的信息!
多年前未掌握SSD这个功能的时候，出现问题，喜欢收集v$session,v$session_wait,v$sqlarea,v$lock等动态性能的相关信息，然后重启，但是后来往下分析的时候，发现少收集了什么信息，导致分析不顺利，后悔莫及…
当时就在想，ORACLE是否有一个一键收集的功能：
把想要的，不想要的，全都收集下来呢！答案就是SSD。
甚至是当sysdba无法登陆时，Oracle依然可以直接attach到共享内存，将内存中的即时状态全部抓取下来，包括系统当前各个进程正在执行什么、正在等什么、进城的堆栈等信息，真是强大大令人发紫的一个功能。
SSD的收集非常简单，照敲就是了，以下是SSD收集的命令
###sqlplus-prelim"/assysdba"
SQLoradebugsetmypid
SQLoradebugdumpsystamstate
SQL--等上30秒到1分钟
SQLoradebugdumpsystamstate
SQLoradebugtracefile_name
接下来就带领大家一起去分析SSD，做根因分析，你会发现工作是一件多么有趣的事情。
开启分析之旅
1.查看登陆进程在等什么
从xxdb_ora_.trc中搜索"waitingfor"可以看到：
可以看到：
1)有N个进程都在等latch:librarycache,latch,并且latch是同一个即b9d
2)1个进程在等cursor:pinX，即在等待cursor类型的mutex
3)latch等待的时间已经长达达到秒
这里不难看出：
由于登陆的时候，要执行包括验证用户、获取权限等内部的SQL（递归SQL），但是在发出SQL后，由于长时间无法获取latch:librarycache这样的资源，因此登陆看上去就像hang住了一样…接下来，我们只需要找到无法latch:librarycache的原因，就可以解开数据库hang住的真相了!
2.第一次头脑风暴
看到这里，也许有同学迫不及待地又想再试试身手：
是不是硬解析的问题？
可以看到：
当客户端发出的SQL到达数据库的服务进程后，要先在sharedpool中去找内存中是否存在该SQL和执行计划，如果存在则拿到执行计划直接执行即可。
那么oracle是如何查找的呢？就是对SQL文本计算hash值后，获取latch:librarycache（11g中则采用mutex代替），对对应的链表进行扫描即可。
因此，软解析也会申请该latch。
所以，不能说是简单的硬解析的问题，一切都有可能。
BTW,笔者面试过很多人，其实更像看到的是分析问题的方法论，而不是使劲的猜…
为什么呢？我们总会遇到很多经验范围之外的事情，怎么可能猜出自己不知道的事情呢？
3.找原因，Orale就是这么简单！
既然长时间无法获取latch,那么是谁在持有latch呢？
需要说明的是，当无法获取latch:librarycache的时候,Oracle在实现上，会将自己放到latch的等待着列表waiterlist当中，那么自然也就有一个对应的持有者列表，
这么做的原因在于，当持有者使用完该latch后，到等待者列表中唤醒等待的进程即可。同时，Oracle在做SSD的时候，就已经把持有者给打印到trace里了。
搜索"waitingforb9dChildlibrary"
可以看到“possibleholderpid=19ospid=”，即持有者是pid=19ospid=
接下来，我们需要去看看latch持有者即pid=19ospid=的进程在做什么
4.持有latch的人去哪了？
搜索“ospid:”，就可以看到LATCH持有者的进程的详细信息了
包括进程名，在执行什么SQL，进程状态是什么，在等什么资源…
可以看到：
Pid=19,spid=的进程，是ORACLE的一个JOBSLVAE进程j,
由于他在持有latch,导致了很多进程需要等待，
holding(efd=5)b9dChildlibrarycache
乘胜追击，进一步查看该进程在等什么资源：
可以看到：
该进程对应的SID是，当前实际上并没有在等待任何资源，因为lastwait表示的是上一次的等待了。长时间持有latch:librarycache,导致N个进程登陆执行内部SQL的时候无法获取latch,继而无法登陆，但是，进程持有者PID=19,SID=，又没有在等待任何资源，SQL:0表示当前没有在执行任何SQL。
生无可恋了，那我怎么知道进程持有者在做什么呢，这还怎么往下查呢…
提示：这里请记住latch的持有者，SID是,！
5.
还记得么，Oracle有一套方法论，那么方法论就是查看callstack,通过查看进程调用的函数轨迹，就可以判断出来，当前进入了哪一种场景。
但是由于客户一着急，收集的SSD的level不够，因为没有打印每个进程的callstack！
这可如何是好啊,难道问题要陷入僵局..
如果是你，接下来，会怎么往下打这一场仗
6.心都给你了
如图所示：
红色加框部分显示，该进程的状态处于DEAD状态！即持有latch的那个进程已经死掉了！
看到这里:
有些朋友又要蒙圈了，“这是什么情况?”
有些朋友可能已经开始有点想法了，心里在嘿嘿乐…
没错，实际上，这已经设计到道和术的问题。
技术层面上，一路找到最终的阻塞者后，已经进行不下去了！
接下来，大家不妨停下来，思考一下：
原理层面呢？
学了那么多体系架构的东西，怎么用到生产问题中呢?
是否可以运用原理帮助解开这个数据库挂起的问题呢？
我面试候选DBA的时候，喜欢问原理。
很多候选DBA答不上来的时候，总喜欢解释道，而且是很坦然的解释到：
