Two days until I leave for Asia. (You have no idea how busy I’ve been for the past month!) If anyone’s curious about trip details I’ve posted about it over on the non-technical side of my blog.

Last night I posted a case study where I used the AWR (a blessed new feature) to investigate “gc buffer busy” wait events in a RAC environment. I concluded the write-up by theorizing that the single freelist was pointing all nodes of the cluster to the same small group of blocks for inserts and thereby causing the blocks on the freelist to always be subject to unearthly contention across the cluster.

One common piece of advice for gc buffer busy waits is to treat them like regular buffer busy waits. Because essentially that’s what they are – a buffer busy wait on a remote instance. So another avenue of investigation is to look at what might be causing buffer busy waits across the cluster.

Some people may remember that back in the days before YAPP and the wait interface, latches were usually where the purported “experts” looked when you had performance problems. Particularly those two infamous latches cache buffers chains and library cache. And of course today these are still an important part of any in-depth investigation and V$LATCH even includes wait time so you can take a time-based approach to analysis. I spent some time yesterday having a look at the latching in this RAC system and it yielded some results that I thought might be interesting to post. So here goes…
› Read more

Well I don’t have a lot of time to write anything up… sheesh – it’s like 10pm and I’m still messing with this. I should be in bed. But before I quit for the night I thought I’d just do a quick post with some queries that might be useful for anyone working on a RAC system who sees a lot of the event “gc buffer busy”.

Now you’ll recall that this event simply means that we’re waiting for another instance who has the block. But generally if you see lots of these then it’s an indication of contention across the cluster. So here’s how I got to the bottom of a problem on a pretty active 6-node cluster here in NYC.

Using the ASH

I’ll show two different ways here to arrive at the same conclusion. First, we’ll look a the ASH to see what the sampled sessions today were waiting on. Second, we’ll look at the segment statistics captured by the AWR.

First of all some setup. I already knew what the wait events looked like from looking at dbconsole but here’s a quick snapshot using the ASH data from today:
› Read more

Just sent this to someone in an email and it seems like something that could be useful for everyone. They were asking how to determine the best setting for db_file_multiblock_read_count. First off, you probably will need assistance from a system admin or SAN admin if you’re running on a SAN. And contrary to one popular belief, it is very possible that setting this parameter too high can cause performance degradation. [Max I/O chunk size] / [db_block_size] is not necessarily the best value for the MBRC. Yes Steve Adams has a script to determine the max possible size for your system – but that doesn’t necessarily mean that this is the best value.

Also, note that getting system statistics is far more important than the MBRC value. It’s really critical that you get good system stats in place so that Oracle costs the read operations far more accurately. For more a good overview of system statistics check out Jonathan Lewis’ article on OTN, Understanding System Statistics.
› Read more