RE: Session With oper EXCL is also waiting - where to now? (systemstate dump)

From: <Christopher.Taylor2_at_parallon.net>
Date: Wed, 19 Sep 2012 16:11:13 -0500
Message-ID: <F05D8DF1FB25F44085DB74CB916678E88515AA3824_at_NADCWPMSGCMS10.hca.corpad.net>

If I had been notified when it happened, I would have used hanganalyze :-p (I believe you have to use it during the event right?)

Chris

From: tanel_at_poderc.com [mailto:tanel_at_poderc.com] On Behalf Of Tanel Poder Sent: Wednesday, September 19, 2012 4:07 PM To: Taylor Christopher - Nashville
Cc: oracle-l_at_freelists.org
Subject: Re: Session With oper EXCL is also waiting - where to now? (systemstate dump)

But in general, manually diagnosing a hang from system state dumps is an exercise of walking through the ultimate blocker step by step. The wait interface data (with its "blocking session" and "final blocking session" columns (the latter is in 11gR2+)) is very useful, but for latches blocker info is usually not populated.

Hanganalyze is able to walk through the latch state objects too by the way, showing the blocking latch-holders in the wait chain ... whenever possible I use hanganalyze, systemstate dumps are heavy and too much manual work! :)

--

Tanel Poder
Blog - http://blog.tanelpoder.com
App - http://voic.ee

On Thu, Sep 20, 2012 at 12:02 AM, Tanel Poder <tanel_at_tanelpoder.com<mailto:tanel_at_tanelpoder.com>> wrote: This process was holding 3 different latches at the time of dumping (shared pool simulator, shared pool, row cache objects):

      holding    (efd) a5b747220 Child shared pool simulator level=8 child# <---
        Location from where latch is held: kglsim_scan_lru: scan:
        Context saved from call: 0
        state=free, wlstate=free
      holding    (efd) 600fab30 Child shared pool level=7 child#=1
        Location from where latch is held: kghfrunp: alloc: wait:
        Context saved from call: 0
        state=busy, wlstate=free
      holding    (efd) a5b6bd2a0 Child row cache objects level=4 child#
        Location from where latch is held: kghfrunp: clatch: wait:

And the reason why this process was holding the latch is "kghfrunp" function - Kernel Generic Heap-management FRee UNPinned chunks. It

--

http://www.freelists.org/webpage/oracle-l Received on Wed Sep 19 2012 - 16:11:13 CDT