【等待事件】User I/O类 等待事件(2.9)--local write wait

SELECTA.*

FROMV$EVENT_NAME A

WHERENAMEIN('local write wait');

造成此等待事件的原因：

1)磁盘损坏

2)若执行TRUNCATE操作很慢，则可能由于表及其表上的索引的初始化值过大，可以通过SQL语句ALTER INDEX IND_BIG_TEMP REBUILD STORAGE (INITIAL 1M);和ALTER TABLE T_BIG MOVE STORAGE (INITIAL 1M);修改其初始化大小

Basically 'local write' wait happens (as the name indicates) when the session is waiting for its local (means writes pending because of its own operation) write operation. This could happen typically if the underlying disc has some serious problems (one of the member disk crash in RAID-05 - for example, or a controller failure). That is why I might have said ' you never see this wait in the normal databases!'. You may see this during (rarely) Truncating a large table while most of the buffers of that table in cache. During TRUNCATEs the session has to a local checkpoint and during this process, the session may wait for'local write' wait. We have not documented this in 'Oracle Wait Interface' as it is very uncommon. May be we can think of adding similar events in the Misc Waits in next edition.翻译下： 基本上'local write wait' 表示会话在等待自己的写操作。在磁盘发生严重问题时会发生(例如RAID 5的一个磁盘崩溃,或者磁盘控制器错误),这在正常的系统中极少发生，在TRUNCATE一个大表而这个表在缓存中的时候，会话必需进行一个local checkpoint,这个时候会话会等待local session wait.在开发环境里面truncate一些列表，速度奇慢。看了一下session等待事件Local Write Wait

local write wait 主要是在dbwr将脏数据写回dbf过程中产生的。

Local write waits 等待说明

网上对local write waits 的说明：

Note 1：

Typically DBWRhas to free up some buffers when you want to read something from the disk.During this process there are chances that you will be waiting for your localbuffer (i.e blocks dirtied/invalidated by your session) to be written to disk.During this time the waits are shown aslocal write waits.

Note 2：

Basically  'localwrite' wait happens (as the name indicates) when the session is waiting for itslocal (means writes pending because of its own operation)  writeoperation. This could happen typically if the underlying disc has some seriousproblems (one of the member disk crash in RAID-05 - for example, or acontroller failure). That is why I might have said ' you never see this wait inthe normal databases!'.You may see thisduring (rarely) Truncating a large table while most of the buffers of thattable in cache. During TRUNCATEs the session has to a local checkpoint andduring this process, the session may wait for 'local write' wait.

基本上'local write' wait 表示会话在等待自己的写操作。在磁盘发生严重问题时会发生(例如RAID 5的一个磁盘崩溃,或者磁盘控制器错误),这在正常的系统中极少发生，在TRUNCATE一个大表而这个表在缓存中的时候，会话必需进行一个localcheckpoint,这个时候会话会等待localsession wait.

在MOS 的文档：

Truncates Taking Too Long... [ID 334822.1]

提到了这个等待事件。

Cause：

Processes thatinvolve temporary tables being truncated and repopulated in multiple,concurrent batch streams may present this situation.

The underlyingproblem is we have to write the object's dirty buffers to disk prior toactually truncating or dropping the object. This ensures instancerecoverability and avoids a stuck recovery. It seems at first glance perfectlyreasonable to simply truncate a temporary table, then repopulate for anotherusage.And then to do the temporary poplulate/truncate operationsin concurrent batches to increase throughput.

However, inreality the concurrent truncates get bogged down as dbwr gets busy flushing thosedirty block buffers from the buffer cache. You will see huge CI enqueue waits.The multiple truncate operations in concurrent streams absolutely killthroughput.This is specially critical with large buffers.

There was also adisscussion in Bug: 4147840 (non-publish) where a peoplesoft process wascausing this behavior because of the above explanation and they seemed to fixit by changing some peoplesoft code to implement delete rather than truncate onsamll temporary tables.

Solution：

In 9.2.0.5 andhigher, it may also help to make sure a "temp" table that isfrequently truncated have storage defined so that it occupies one extent.But this workaround is only available as long as the extent is no morethan 50% the size of the buffer cache. In non-RAC environments the tablestill has to be smaller than 50% of the buffer cache, but it allows thetable to have up to 5 extents before falling back to the old algorithm.