ANBOB™

Buffer busy wait

当会话尝试访问buffer cache中的块但因缓冲区繁忙而无法访问时，就会发生缓冲区繁忙等待事件，因为另一个会话正在修改该块，而该块的内容处于不断变化中。为了保证读取器对块有一个连贯的映像，要么有所有更改，要么没有任何更改，修改块的会话会用一个标志标记块头，让其他用户知道正在发生更改，并等待直到应用完整的更改。

会话无法将缓冲区固定在缓冲区缓存中的原因有四种，每种原因都有一个单独的等待事件：

1. “buffer busy waits”：一个会话无法将缓冲区固定在缓冲区缓存中，因为另一个会话已将该缓冲区固定。
2. “read by other session”：会话无法将缓冲区固定在缓冲区缓存中，因为另一个会话正在从磁盘读取缓冲区。
3. “gc buffer busy acquire”：一个会话无法将缓冲区固定在缓冲区缓存中，因为另一个会话正在从另一个实例的缓存中读取缓冲区。
4. “gc buffer busy release”：会话无法将缓冲区固定在缓冲区缓存中，因为另一个实例上的另一个会话正在将此缓冲区从该缓存放入其自己的缓存中，以便可以将其固定。

什么原因导致Buffer busy wait等待事件

发生缓冲区忙等待的两种主要情况是：

• 另一个会话正在将块读入缓冲区 – 在 10g 及更高版本中，这种特定情况已被拆分为由其他会话等待事件进行的单独读取。
• 另一个会话以与我们的请求不兼容的模式保存缓冲区。

在更改块时，该块被标记为其他人无法读取。所做的更改应持续不到百分之几秒，例如，磁盘读取应在 20 毫秒内，块修改应在 1 毫秒内。因此，需要大量的缓冲区繁忙等待才能引起问题，但以下是一些示例：

• 热块问题，例如表的空闲列表上的第一个块，并发插入量很高。所有用户将同时向该块插入数据，直到该块填满，然后用户开始向列表中的下一个空闲块插入数据，依此类推。
• 多个用户同时运行低效的 SQL 语句，对同一个大表执行全表扫描。一个用户将从磁盘读取块，而其他用户将等待缓冲区忙等待（或由 10g 及更高版本中的其他会话读取）以完成物理 I/O。

获取有关Buffer busy wait的更多信息

要获取有关正在执行的 SQL 语句和正在等待的块的更多信息，请跟踪会话或从 V$SESSION V$SESSION_WAIT（或 10g 及更高版本中的 V$SESSION）收集数据：

SELECT s.sql_hash_value, sw.p1 file#, sw.p2 block#, sw.p3 reason
FROM v$session_wait sw, v$session s
WHERE sw.event = 'buffer busy waits'
AND sw.sid = s.sid

• P1 – file number of the data file containing the block being waited for
• P2 – block number of the block being waited for
• P3 – this wait is called from many different sections of Oracle code and each uses their own reason code which differ among versions

修复Buffer busy wait等待

一旦知道数据库对象，请考虑以下争用的原因及其解决方案。

• Undo Header – 如果使用自动撤消管理 (AUM)，请增加撤消表空间的大小。如果不使用 AUM，请添加更多回滚段。
• Undo Block — 如果使用 AUM，则增加撤消表空间的大小。如果不使用 AUM，则增加回滚段大小。
• Data Block– 数据块是保存表或索引中的行数据的块。典型的问题是多个会话请求的块不在缓存中或处于不兼容模式（在 10g 及更高版本中 由其他会话读取）。
  • 调整将过多数据块读入缓冲区缓存的低效查询。这些查询可能会刷新缓冲区缓存中可能对其他会话有用的数据块。通过调整查询，需要读入缓存的数据块数量被最小化，从而减少缓存中现有“好”数据块的老化。
  • 解决热块问题– 如果上述查询始终返回相同的块或块集，则这被视为热块情况。删除一些热行并将其重新插入表中。大多数情况下，这些行将被放置在不同的块中。DBA 可能需要调整 PCTFREE 和/或 PCTUSED，以确保这些行被放置在不同的块中。此外，请与开发人员沟通，了解一组块为何热。
  • 将表放入内存– 缓存表或将表保存在 KEEP POOL 中。当多个会话请求驻留在磁盘中的块时，会话需要花费太多时间将其读入缓冲区缓存。需要相同块的其他会话将记录“缓冲区忙等待”。但是，如果块已经在缓冲区缓存中，则消除了这种可能性。另一种选择是增加缓冲区缓存大小。更大的缓冲区缓存意味着更少的磁盘 I/O。这减少了一个会话从磁盘子系统读取块而其他会话正在等待该块的情况。
  • 修复低基数索引– 寻找减少低基数索引数量的方法，即唯一值数量较少的索引，这可能会导致过多的块读取。当并发 DML 对具有低基数索引的表进行操作并导致一些索引块争用时，这尤其成问题。
• Data Segment Header– 每个段都有一个包含段信息（例如空闲和可用块详细信息以及高水位标记）的头块。有时，当多个会话尝试向同一个表插入/删除数据时，此块可能成为争用点。
  • 调整 PCTFREE/PCTUSED 或使用 ASSM — 当会话向块中插入行或从块中删除行时，如果达到 PCTFREE 阈值，则必须将该块从空闲列表中取出。当会话从块中删除行时，如果达到 PCTUSED 阈值，则将块放回空闲列表中。如果有大量块从空闲列表中出来或进入空闲列表，则所有这些会话都必须在段头中的空闲列表映射中进行更新。此问题的解决方案是创建多个空闲列表。这将允许不同的插入流使用不同的空闲列表，从而更新不同的空闲列表映射。这减少了段头块上的争用。您还应该考虑优化 PCTUSED/PCTFREE 参数，以便块不会频繁进出空闲列表。另一个解决方案是使用 ASSM，从而避免使用所有空闲列表。
  • 增加扩展大小– 如果扩展太小，Oracle 必须不断分配新的扩展，从而导致扩展映射中的争用

Shouldn’t we have waited for buffer busy waits while waiting CBC latch？

TanelPoder said
With regular logical  IOs the buffer contents are not read while holding the CBC(Cache Buffer Chian) latch:

1.  1#  Take CBC latch into shared mode
2.  2# Walk the buffer hash chain until you find the relevant buffer header
3.  3# Upgrade the CBC latch to Exclusive mode
4.  4# Pin the buffer header
5.  5 # Release the CBC latch
6.  6 # Now access the buffer data( call transaction,  data layer etc)   — if someone else wants to pin the buffer now , they’d wait for buffer busy waits
7.  7# Take the CBC latch again(in shared mode)
8.  8$ Unpin the buffer header
9.  10# Release the CBC latch

Sometimes “short” logical IOs can skip a few steps

with “short” LIOs like unique index lookup LIO(etc) Oracle can avoid the buffer pinning codepath:

1.  1# Take CBC altch in shared mode
2.  2# Walk the buffer hash chain until you find the relevant buffer header — This show up as consistent reads – examination  conter in v$sesstat
3.  3# Now access the buffer data
4.  4# Release the CBC latch