Buffers cannot be locked, because they are not relational structures. However, for a number of reasons, they can be temporarily unavailable. When this occurs, the buffer is deemed busy. Distilling all the complexity down to its essence, a buffer busy waits event is about limited concurrency. A process needs to access a buffer, but it can't because another process is accessing the buffer and won't allow concurrent access. There are a number of situations when this can occur and specific solutions in each case.

What makes buffer busy waits events challenging is there are multiple solid diagnostic approaches. One of the most common diagnostic buffer busy approaches is using what is known as the reason code. The reason code consists of three digits, with each digit's value revealing part of the story as to why the buffer is busy and cannot be immediately accessed.7 While many performance specialists use this method, I was never comfortable with it. Strangely, in Oracle Database 11g, Oracle removed the reason code from the v$session_wait and v$session view's p3 column! If you are used to using the reason code, don't fret, because the method I will detail works wonderfully.

In Oracle Database 10g, Oracle took one of the most common buffer busy situations and gave it its own wait event. So what we now see as a read by other session event used to be part of the buffer busy waits event. While this did cause some confusion, it's actually good news, because it makes both wait events more specific. I will also detail the read by other session event in this section.