oracle 重要的等待事件

buffer busy waits等待事件 orcale的等待事件列表可以从v$event_name中查看完整的等待事件列表 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 ev

buffer busy waits等待事件

orcale的等待事件列表可以从v$event_name中查看完整的等待事件列表

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).

--当一个会话需要读取一个数据块，但这个数据块正在被另一个会话读取到内存中时。

--当一个会话视图修改一个数据块，但这个数据块正在被另一个会话修改时。

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.

 

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.

 

 

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).