《About Oracle Hanganalyze》的评论

作者：Oracle数据库hang诊断-徐万新之路

Oracle数据库hang诊断-徐万新之路 — Thu, 27 Aug 2020 14:50:38 +0000

[…] repeatedly waiting*/ SPOOL OFF; 获取了数据之后就是分析了！！ Reference: http://www.killdb.com/2014/01/23/about-oracle-hanganalyze/ http://blog.itpub.net/205377/viewspace-2124541/ 赞(0) 打赏 […]

作者：drop用户hang住解决思路 | SEARU.ORG

drop用户hang住解决思路 | SEARU.ORG — Fri, 29 Jul 2016 09:41:57 +0000

[…] 一个insert也能死锁吗？这里不是太清楚，知道的朋友可以指点一下，因为drop的时候hang住了，所以这里想到了做hanganalyze分析一下，这里采用是的3级的hanganalyze分析，当是也是roger老师提示的，具体的分析hanganalyze的知识点和分析过程可以参考http://www.killdb.com/2014/01/23/about-oracle-hanganalyze.html当然我的这个案例也被他引入了，但是MMON 是可管理性监视器（Manageability Monitor），MMON主要用于AWR，ADDM，MMON会从SGA将统计结果写到系统表中。这是这个进程的作用，但是为什么跟删除一个用户有关系，原因还是不清楚希望知道的朋友指点下。喜欢 0 抢沙发分享标签： […]

作者：kimi

kimi — Mon, 10 Feb 2014 08:30:00 +0000

[16]/0/17/154/0x24617be0/26800/IN_HANG/29/32/[185]/19 —从IN_HANG 我们可以看出185被16阻塞

[185]/1/16/4966/0×24617270//IN_HANG/30/31/[16]/16 —

这段看不懂 2个都是in_hang 怎么判断哪个是堵塞者哪个被堵塞？

作者：kimi

kimi — Mon, 10 Feb 2014 08:17:00 +0000

您的意思就是不用看其他的 leaf状态的就是阻塞源头 nleaf的就是被阻塞的是这样理解吗

作者：Roger

Roger — Thu, 23 Jan 2014 07:29:00 +0000

兄弟，你看错地方了，我那里是in_hang的状态，是ok的。如果是nleaf，leaf的状态，应该看我上面写的内容，如下：

例子：
[ nodenum]/cnode/sid/sess_srno/session/ospid/state/start/finish/[adjlist]/predecessor
[16]/0/17/154/0x24617be0/26800/LEAF/29/30//19 –从这里看19是waiter 因此我们认为17阻塞了20
[19]/0/20/13/0×24619830/26791/NLEAF/33/34/[16]/186

作者：kimi

kimi — Thu, 23 Jan 2014 07:03:00 +0000

([nodenum]/cnode/sid/sess_srno/session/ospid/state/[adjlist]):

[190]/1/191/3/0x1eb8ac1b0/14027/IN_HANG/[190]

我们将上述内容进行分解:
State of LOCAL nodes
([nodenum]/cnode/sid/sess_srno/session/ospid/state/[adjlist]):
[45]/1/46/49/0x8d6d5174/3966/NLEAF/[51]
[51]/1/52/35/0x8d6c453c/3928/LEAF/

我做出来的51并不是sid号而是52号sid是blocker