RE: "latch: cache buffers chains" wait in NON-RAC Benchmark Runs

Thanks Jonathan for responding & the clarifications

U wrote -> "select     obj, tch    from     sys.x$bh    where     hladdr = 
'6F9CBE00'    -- adjust as necessary"



How is the Value of "hladdr" to be specified for our NON-RAC database?

Oracle 10gR2

Cheers

Vivek

________________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [oracle-l-bounce@xxxxxxxxxxxxx] On Behalf 
Of Jonathan Lewis [jonathan@xxxxxxxxxxxxxxxxxx]
Sent: Friday, February 15, 2008 9:39 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: "latch: cache buffers chains" wait in NON-RAC Benchmark Runs

The Burleson article and the Metalink note are both seriously defective.

"Cache buffers chains" latch activity is a natural consequence of accessing
data buffers.  Contention for "cache buffers chains" latches is more likely
in a system with a high degree of concurrency where lots of small jobs are
visiting the same (relatively small) number of data blocks.

The biggest problem with the Burleson article is that he seems to be confusing
latch contention with buffer busy waits.

The biggest problem with the Metalink article is that it supplies a ridiculous
query to report the "problem object" from the child latch address.  Do NOT run 
that
query on a real production system. See the following note that comments on the
problem:
 
http://www.jlcomp.demon.co.uk/kiddy_scripts.html#_Sometimes_the_best_thing_to_do_is_tIf
 you want an efficient query to get the relevant information in 10.2, then 
allyou need isa query like:    select     obj, tch    from     sys.x$bh    
where     hladdr = '6F9CBE00'    -- adjust as necessary    ;The OBJ is the 
data_object_id of the object (or dataobj# from obj$,since you're prepared to 
poke around at the level of the x$).Another thing to consider is that the TCH 
can be relatively high for anobject that is not subject to much access. The TCH 
is only increased atmost once every three seconds.
Take a look at the following
OBJ        TCH
---------- ----------
51813          1     50303         10         2         13     41383          1 
        2         13      9006          1      9076          1         2        
 13       237        438It's Object 237 has been touched at least once every 
threeseconds for the last 22 minutes (in fact it's job$).  Object50303 has been
  hammered to death for the last 30 seconds.You have to temper the touch count 
with knowledge aboutwhat MIGHT have been happening to the objects.To help you 
address the problem, you may get more cluesfrom a simple statspack/awr report - 
find the SQL that doesmost gets, and check the segment statistics for the 
objectssubject to most buffer gets - cross reference to see if thetwo sets of 
information are consistent, then see if youcan reduce the work done by those 
statements.
Regards

Jonathan Lewis

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are 
not to copy, disclose, or distribute this e-mail or its contents to any other 
person and any such actions are unlawful. This e-mail may contain viruses. 
Infosys has taken every reasonable precaution to minimize this risk, but is not 
liable for any damage you may sustain as a result of any virus in this e-mail. 
You should carry out your own virus checks before opening the e-mail or 
attachment. Infosys reserves the right to monitor and review the content of all 
messages sent to or from this e-mail address. Messages sent to or from this 
e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
--
http://www.freelists.org/webpage/oracle-l

Other related posts: