Comments on: Tuning latch contention: Cache buffers chain latches

By: Bad Stats and the Strage "Cache Buffers Chain Latches" Wait

Bad Stats and the Strage "Cache Buffers Chain Latches" Wait — Thu, 05 Jan 2012 20:56:31 +0000

[...] know what this mysterious “latch” thing was, so of course I google’d it and found an article from “orainternals”. Inside is a lot of Oracle DBA stuff that I probably don’t have access to but toward [...]

By: Cardinality feedback to resolve a Cache buffers chains latch contention issue - OraInternals

Sun, 01 Jan 2012 00:32:08 +0000

[...] I blogged about resolving cache buffers chains latch contention in my earlier entry , in which, root cause was excessive index access due to Nested Loops join. Recently, we resolved [...]

By: troullyTror

troullyTror — Fri, 08 Apr 2011 08:09:55 +0000

Wow thank god almighty for orainternals.wordpress.com. That training and kindness in taking care of the whole thing was tremendous. I don’t know what I would’ve done if I had not come across such a point like this. I can at this moment look ahead to my future. Thank you so much for the professional and result oriented guide. I will not be reluctant to recommend the website to any person who will need recommendations on this area.

By: CBC Latch Contention – My Experience « Anand's Blog

CBC Latch Contention – My Experience « Anand's Blog — Wed, 15 Sep 2010 17:22:56 +0000

[...] http://orainternals.wordpress.com/2008/07/30/tuning-latch-contention-cache-buffers-chain-latches/ [...]

By: Osama Karim

Osama Karim — Sat, 24 Oct 2009 21:01:45 +0000

Riyaz,

Thanks for the lovely blog. We are facing similar problem where CPU usage is going upto 80% +. We will try to implement your Suggestion.

Thanks

By: orainternals

orainternals — Tue, 06 Oct 2009 15:10:28 +0000

Hello Muthu
Thanks for visiting. I am glad this blog is helpful.
Cheers
Riyaj

By: Muthu

Muthu — Mon, 05 Oct 2009 21:46:46 +0000

Riyaj,

Very nice article. We’re experiencing latch contention in our EBS environment off and on. I’m sure, this article will help troubleshooting the issues.

Also, have you blogged with the focus on tuning the SQLs ? We’ve a situation in whchi, the SQLs that were written over 3 yrs ago, during the implementation phase, has undergone some changes ; and with the growth of the database from 1 TB to around 4 TB, performance troubleshooting has become a big challenge now.

Thanks and regds.
Muthu

By: orainternals

orainternals — Fri, 16 Jan 2009 16:50:17 +0000

Hi Charles

I removed the union all branch joining with object_id and tested out.. It works fine with data_object_id outer join itself.

with bh_lc as
(select /*+ ORDERED */
lc.addr, lc.child#, lc.gets, lc.misses, lc.immediate_gets, lc.immediate_misses, lc.spin_gets, lc.sleeps,
bh.hladdr, bh.tch tch, bh.file#, bh.dbablk, bh.class, bh.state, bh.obj
from
x$kslld ld,
v$session_wait sw,
v$latch_children lc,
x$bh bh
where lc.addr =sw.p1raw
and sw.p2= ld.indx
and ld.kslldnam=’cache buffers chains’
and lower(sw.event) like ‘%latch%’
— and state=’WAITING’
and bh.hladdr=lc.addr
)
select bh_lc.hladdr, bh_lc.tch, o.owner, o.object_name, o.object_type, bh_lc.child#, bh_lc.gets, bh_lc.misses, bh_lc.immediate_gets,
bh_lc.immediate_misses, spin_gets, sleeps
from
bh_lc, dba_objects o
where bh_lc.obj = o.data_object_id(+)
order by 1,2 desc
/

Cheers
Riyaj

By: orainternals

orainternals — Fri, 16 Jan 2009 14:23:41 +0000

Hi Charles
Thanks for reading my blog.
You had a question about union branch in latch_cbc_to_buf.sql. Problem was that x$bh.obj column has object_id in few cases and data_object_id in few other cases. Original SQL had only data_object_id, but in few specific instances, SQL didn’t print some objects since object_id was populated in x$bh.obj column (which may have been a bug when I think about it now). That’s why one branch joins with object_id and another with data_object_id. Of course, it is an outer join and so can’t exactly use OR clause.
Side effect of above change is that bh_lc is materialized in the execution plan.
About touch_count question: In some cases, it is the # of clones that causes issues, not necessarily, touches to the buffer. As you may know, cloning buffers involves quite a bit of latching activity too. If we sort by touch count, cloned buffers are not visible and can be misleading.
So, I guess, what I am saying that is probably better to get more rows and throw away junk rows manually then throwing away from SQL

Yes, I would very much appreciate, if you can enhance the script.

Cheers
Riyaj

By: Charles Schultz

Charles Schultz — Wed, 14 Jan 2009 20:44:23 +0000

I did find one minor issue with the query; the latch_children stats are a little misleading in the report. While it may be useful to see all the objects controlled by a specific latch, I would think that during a performance problem, one would want to know what the hot objects are; those objects that are being heavily requested (ie, high touch counts). Would it be pertinent to alter the query a little to make it a top-n type query?

I am thinking it would also be nice to cross-reference with the sessions that are experiencing the wait. I’ll try to play around with it some more. =)