Re: Session With oper EXCL is also waiting - where to now? (systemstate dump)
- From: Tanel Poder <tanel@xxxxxxxxxxxxxx>
- To: Christopher.Taylor2@xxxxxxxxxxxx
- Date: Thu, 20 Sep 2012 00:07:09 +0300
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@xxxxxxxxxxxxxx> wrote:
> This process was holding 3 different latches at the time of dumping
> (shared pool simulator, shared pool, row cache objects):
>
> holding (efd=11) a5b747220 Child *shared pool simulator* level=8
> child#=15 <---****
>
> Location from where latch is held: kglsim_scan_lru: scan:****
>
> Context saved from call: 0****
>
> state=free, wlstate=free****
>
> holding (efd=11) 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=11) *a5b6bd2a0* Child *row cache objects* level=4
> child#=16****
>
> 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
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
