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 184.108.40.206/UEK 4/OEL 6
stap -v latch_callgraph2.stp -d oracle -x 6240 | sed -f latchname.sed |sed -f where_why_decode.sed
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 🙂
DOWNLOAD : latch_callgraph2.stp
That’s it 😀