Really, The only thing to do is fix the SQL. Each logical I/O or buffer get results in a cache buffer chain latch get. So by doing less LIO, you will get fewer latch gets and as a result fewer sleeps on latches. This is how you fix the *problem*. You can also fix the *symptom*: bump up _spin_count (assuming that you run on a SMP) or set _db_ block_hash_latches to a higher value.
Fixing the SQL is the right way to go. Are you shooting for a 99.99999 percent buffer cache hit ratio ? If you are than that could also be a reason for the problem. Oh and there is a bug in Oracle 8.1.6/8.1.7 I believe that causes an additional buffer get for the index root block (assuming that the hash latches with the high sleeps cover index root blocks). Anjo Kolk http://www.oraperf.com ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Thursday, February 28, 2002 7:53 AM _db_block_hash_buckets > db_block_buffers = 360448 > db_block_lru_latches = 4 > db_block_size = 8192 > > _db_block_hash_buckets = 720896 > > Ok, what I have so far is: > > - using itrprof, I saw that 35% of my elapsed time was based on waits of > "cache buffers chains" latches. > - checking v$latch_children (latch#=66), there are a good number (8-10 > I'd guess) of the 4096 children that have a very high (10k+) number > of sleeps - the rest of the children (of this type latch) have sleep > counts are 10-12, so we have a ton of contention on a low # of "cache > buffers chains" latches. > - joining with x$bh (v$latch_children.addr=x$bh.hladdr), I see that > the most contentioned-for of these latches (51,240 sleeps!) has 66 > blocks on the chain. Checking with all_objects, I'm noticing that these > blocks are scattered in some of the more important (and most-accessed) > tables and indexes > - The other latch children that have high sleep counts also have 30-50 > buffers in their chains > > Questions: > > - to me, 66 seems awfully high - is it? > - the sleep count is obviously high from what I can tell - is it > definitely tied to the buffer chain this latch is protecting being > so long and just happening to be 66 buffers that are mostly important > tables and indexes? > - I haven't set it by hand, but _db_block_hash_buckets = 720896 > and this is 11 * 2^16. Everything I've read says it should be > a prime number (and that jives with my comp sci background) - why > is it not prime, why is it exactly twice db_block_buffers? > - the number of children for "cache buffers chains" is 4096. Now, > increasing that could have a positive effect on distributing the > contention, but since the sleps are so heavily skewed to only a few > of the children as it stands, I don't get the feeling that's the > right fix. > > Anyone have any advice to offer? Pages/URL's that can help give some > advice? > > It's worth noting that these latches are basically non-existant as > wait events at low load - "log file sync" is about the only wait > event I see at low loads, and I'm working on reducing my commit > counts much further to help tackle that. > > Thanks!! > > James > -- > James Manning <[EMAIL PROTECTED]> > GPG Key fingerprint = B913 2FBD 14A9 CE18 B2B7 9C8E A0BF B026 EEBB F6E4 > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: James Manning > INET: [EMAIL PROTECTED] > > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 > San Diego, California -- Public Internet access / Mailing Lists > -------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Anjo Kolk INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
