Latch acquisition/release call-graph including UltraFast Latch

In one of my previous post i showed that it was not possible to draw a complete latch call graph for a specific process based only on dedicated function call such as  ksl_get_shared_latch,kslgetl and kslfre. The reason for this is that UltraFast latch can be acquired without the need for a dedicated function call (ex: inside kcbgtcr function).

So how to track them ?

When analyzing the disassembly code of some functions (kcbzar,kcbrls,kcbgtcr) where the UltraFast latch “cache buffers chains” is acquired and released i have identified that whenever the latch is manipulated it’s address is stored at some offset from the process address (this value is not externalized in X$KSUPR/v$process) .Based on this finding i was able to improve the script to also show the UltraFast latch (or some of them).

NOTE : The script is very experimental and may not track all the UltraFast Latchs as the offsets where the addresses are stored seem to be depending on some stuff.Further investigation is needed !

TEST : Oracle 11.2.0.4/UEK 4/OEL 6

stap -v latch_callgraph2.stp -d oracle -x 6240  | sed -f latchname.sed |sed -f where_why_decode.sed

capture-01

We can see here that one “cache buffers chains” child latch was acquired inside “kcbgtcr”(fast latch)  and then released by “kslfre” after having acquired and released other latches in the meantime.This mean that the child latch was upgraded but that’s another story 🙂

capture-02

DOWNLOAD : latch_callgraph2.stp

That’s it 😀

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s