buffer busy waits

Wait occurs when a session attempts to access a block in memory, is denied and
must wait until the buffer becomes available. This event happens because a buffer is
either being read into the buffer cache by another session (and the session is waiting
for that read to complete) or the buffer is in the buffer cache, but in a incompatible
mode (that is, some other session is changing the buffer).

Resolved By
DBAs and Developers

Solutions
Buffer busy waits often occur in the following cases:

 Inefficient SQL statements read more blocks than necessary. If there are
many sessions running these statements, they will attempt to read the
same blocks and possibly wait on this event.

 If the FREELISTS parameter for a table is too low, multiple sessions that
are attempting to insert rows in the same table and end up waiting for
freelists. This problem shows up as contention for the segment header of
the table.

 Multiple sessions are attempting to change an index block (possibly do to

an insert).

 The INITRANS parameters is too low for a segment. Any DML operation
that needs to go into the block needs to lock an Interested Transaction
List (ITL). If INITRANS parameter is set too low, then there will be less
number of ITLs allocated originally. Oracle can only allocate more ITLs if
there is space in PCTFREE area of the block. If, however, there is no
space to increase the ITL, the transactions that cannot lock ITLs will have
to wait until the previous transactions have completed operations on the
block. The waiter will register 'buffer busy wait' for the block.

Using SolarWinds DPA, drill down to the Objects tab to find the table or indexes
waited for. Once the database object is known, consider the following causes of
contention and their solutions.

Waits on Data blocks

Data blocks are the blocks that actually hold the row data in a table or index.

Problem: Multiple sessions are requesting a block that is either not in cache or in an
incompatible mode.
Solution 1: Tune inefficient queries. Inefficient queries read too many blocks into the
buffer cache. These queries could flush out blocks that may be useful for other
sessions in the buffer cache. By tuning queries, the number of blocks that need to be
read into the cache is reduced, reducing aging out of the existing "good" blocks in the
cache.

Solution 2: Delete some of the hot rows and insert them back into the table. Most of
the time, the rows will be place in a different block. The DBA may need to adjust
pctfree and/or pctused to ensure the rows are placed into a different block.

Solution 3: Cache the table or keep the table in the KEEP POOL. When multiple
sessions are requesting the blocks that reside in the disk, it takes too much time for a
session to read it into the buffer cache. Other session(s) that need the same block
will register 'buffer busy wait'. If the block is already in buffer cache, however, this
possibility is eliminated. Another alternative is to increase the buffer cache size. A
larger buffer cache means less I/O from disk. This reduces situations where one
session is reading a block from the disk subsystem and other sessions are waiting for
the block.

Solution 4: Look for ways to reduce the number of low cardinality indexes. A low
cardinality index is an index on a column(s) with a relatively low number of unique
values such as a U. S. state column that has only fifty unique values. Low cardinality
indexes could result in excessive block reads. Concurrent DML operations on low
cardinality columns could also cause contention on a few index blocks.
Waits on Segment Header blocks
Each segment has one segment header block.

Problem: At times, this block can be a point of contention which manifests itself as a
buffer busy wait. This occurs especially when multiple sessions are attempting to
insert into or delete from the same table.

Solution 1: When sessions insert rows into a block, the block must be taken out of
the freelist if the PCTFREE threshold reached. When sessions delete rows from a
block, the block will be put back in the freelist if PCTUSED threshold is reached. If
there are a lot of blocks coming out of the freelist or going into it, all those sessions
have to make that update in the freelist map in the segment header. This can cause
contention for the segment header block which manifests itself as 'buffer busy wait'.
One solution to this problem is to create multiple freelists. This will allow different
insert streams to use different freelists and thus update different freelist maps. This
reduces contention on the segment header block. You should also look into
optimizing the PCTUSED/PCTFREE parameters so that the blocks don't go in and
out of the freelists frequently.

Solution 2: Increase the size of the extents. If extents are too small, Oracle must
constantly allocate new extents causing contention in the extent map
Solution 3: Increase the undocumented database parameter,
_bump_highwater_mark_count, from the default of 5. Updating the high water mark
on the table can become a bottleneck.

Additional Research
Search Oracle Support
Search Google Groups
Search Google

Expanded Definition
Wait until a buffer becomes available. This event happens because a buffer is either
being read into the buffer cache by another session (and the session is waiting for
that read to complete) or the buffer is in the buffer cache, but in a incompatible mode
(that is, some other session is changing the buffer).