Re: "latch: cache buffers chains" wait in NON-RAC Benchmark Runs
Date: Sat, 16 Feb 2008 10:18:34 -0000
My comment on the Metalink note was:
>> The biggest problem with the Metalink article is that it supplies a
>> query to report the "problem object" from the child latch address.
If you read the Metalink note you would see that they first tell you how to find the child latch address before telling you a bad way of using it.
Author: Cost Based Oracle: Fundamentals
The Co-operative Oracle Users' FAQ
- Original Message ----- From: "VIVEK_SHARMA" <VIVEK_SHARMA_at_infosys.com> To: <jonathan_at_jlcomp.demon.co.uk> Cc: <oracle-l_at_freelists.org> Sent: Saturday, February 16, 2008 4:47 AM Subject: 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?
From: oracle-l-bounce_at_freelists.org [oracle-l-bounce_at_freelists.org] On Behalf Of Jonathan Lewis [jonathan_at_jlcomp.demon.co.uk] Sent: Friday, February 15, 2008 9:39 PM
Subject: Re: "latch: cache buffers chains" wait in NON-RAC Benchmark Runs
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
query on a real production system.
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 LewisReceived on Sat Feb 16 2008 - 04:18:34 CST