bufferlock引起的buffercache上的等待事件

什么是buffer lock? buffer cache中块的修改，是需要buffer lock来保护的。当用户想修改块或读取块时，会往块头加shared锁或exclusive锁，尽管这个时间只是一瞬间，但刚好此时其他用户也想修改这块，就会等待诸如buffer busy waits、read by other session等

什么是buffer lock? buffer cache中块的修改，是需要buffer lock来保护的。当用户想修改块或读取块时，会往块头加shared锁或exclusive锁，尽管这个时间只是一瞬间，但刚好此时其他用户也想修改这块，就会等待诸如buffer busy waits、read by other session等等的等待事件。

A session that reads or modifies a buffer in the SGA must first acquire the cache buffers chains latch and traverse the buffer chain until it finds the necessary buffer header. Then it must acquire a buffer lock or a pin on the buffer header in shared or exclusive mode, depending on the operation it intends to perform. Once the buffer header is pinned, the session releases the cache buffers chains latch and performs the intended operation on the buffer itself. If a pin cannot be obtained, the session waits on the buffer busy waits wait event. This wait event does not apply to read or write operations that are performed in sessions’ private PGAs.

一个会话想要读或者写位于buffer cache上的块,就必须先获得cache buffers chains latch,然后扫描整条chain上的块头,直到找到适合的块头为止。这个过程中，别的会话就不能再获得cache buffers chains latch了，而必须等待latch:cache buffers chains等待事件。而这些hash latch,hash bucket,hash chain,buffer header，都是位于shared pool上的，真正的块内容，是在buffer cache上的。当会话找到合适的块后，根据块头地址找到需要的块后，就会往块头打上shared或exclusive的标记，这取决于会话想执行的操作，完成以后才释放cache buffers chains latch。然后才做想要做的操作，如select或update。如果往块头打shared或exclusive标记的时候发现冲突，这就是buffer lock冲突，就会出现buffer busy waits等待事件。
BUFFER LOCK管一个块里的争用 latch:cache buffer chain管同一个chain上的争用。

buffer busy waits
The buffer busy waits event occurs when a session wants to access a data block in the buffer cache that is currently in use by some other session. The other session is either reading the same data block

into the buffer cache from the datafile, or it is modifying the one in the buffer cache.

当一个session试图访问buffer cache中其他session正在使用的同一数据块时就会发生buffer busy waits事件，这些session正在从数据文件中读这些块到buffer cache中，或正在修改buffer cache中的这些块。

In order to guarantee that the reader session has a coherent image of the block with either all of the changes or none of the changes, the session modifying the block marks the block header with a flag

letting other sessions know that a change is taking place and to wait until the complete change is applied.

为了保证这些读session对这些数据块的一致性读，修改数据块的session会在数据块的头部作个标记，以告诉其他session当前数据块正在被修改，等待修改完成并commit后再才读取。

buffer lock 引起的等待事件： buffer busy waits buffer busy global cache/CR(10g起变身成gc buffer busy) read by other session（10g起）
9i: buffer busy waits等待事件的参数 P1:FILE#（绝对的文件号） select * from v$datafile where file#=10; P2:Block# P3:原因码 P3是130的话，就等同于10g的read by other session。是220的话则相当于10g的buffer busy waits，这两个是最常见的，记得，少于200的原因吗都是与IO相关的。
10g以上，不再用原因码，P3值改为争用的块的类(class#)，这里不是等待事件的WAIT_CLASS#。可以通过select * from v$waitstst来查看。假如P3的CLASS#是1，而会话SQL是查询，那么就等同于以前的130.如果会话SQL是DML，就等同于以前的220。 select/select引起的read by other session select/select引起的buffer lock争用，发生在将相同块载入到内存的过程中。通俗地说，你读的块，别人也正从磁盘读，你就须等待read by other session。为什么会发生这个呢？因为最初创建缓冲区时，需要以Exclusive模式获得buffer lock，这样其他想以shared模式读取此块的会话需要等待Exclusive模式的buffer lock释放。（这个与Hadr Parsing发生时对对应的SQL Cursor以Exclusive模式获得library cache pin是相类似的概念）。发生这个等待事件时，同时会发生db file sequential read、db file scatterred read等物理IO等待现象。如果要读入的块已经载入到SGA中，多个会话以shared模式获取相应块的buffer lock，自然不会发生buffer lock争用。（但修改块头为shared与释放块头shared标记，都要以exclusive模式锁定对应cache buffer chain latch，此时发生的latch:cache buffer chain就得另当别论了）。
解决方法：要减少物理IO。减少逻辑IO就可以减少物理IO，所以要优化SQL，使得buffer get减少。 SGA很大的话，也可以减少物理IO，所以设置稍微大的SGA，不用频繁地从磁盘做物理IO，也可以减少此类等待事件。加速物理IO 这个跟存储性能相关
select/update引起的buffer busy waits/read by other session 有两种情况： 1.当会话发出select查询，而数据库已经被修改了，他就必须读取过去映像的CR块。此时CR块不在缓冲区上，就要从磁盘读取undo块。读取过程中，别的会话也需要查询到这些CR块，就会出现read by other session。这是一致性读发生的select/select争用。 2.会话在update过程中，会修改undo块头上的信息，所以要以exclusive模式获取undo块的buffer lock，此时刚好别的会话发出的一致性查询要用到这个undo块，要以shared模式获取undo块的buffer lock，此时会发生buffer busy waits等待事件。试想，假如undo块很大，里面容纳很多行，每update一行都需要以exclusive获取块的buffer lock，这种情况才容易发生。但在AUM环境下几率很低了。这里为什么说是undo块呢？注意：朋友们难道读到这里，没觉得有什么不妥吗？对于select /update这种争用，难道在普通数据块不会发生吗，为什么仅在Undo块发生呢？对普通的数据块进行update，要在瞬间加上exclusive锁，而读块行为，是需要获取块的shared锁，才能读取块头关于undo的信息，从而知道去哪里找到相应的undo块来构造CR块。shared遇到exclusive也是会发生冲突的。其实对于普通的块，是由hash chain进行管理的。因为如果对普通块进行update还是select，都是须先获得cache buffer chain子锁存器的，这就把竞争放在上由的子latch了。而undo块并没由hash chain管理。由从这里也可以看出，内存中的细粒度锁也是分为上层latch以及下层buffer lock的。解决方法：也是如上一样，减少SQL的logical read,以及加大buffer cache等。
update/update引起的buffer busy waits 多个会话同时update同一个块的行时，如果是同一行，自然能通过TX锁做事务级别的同步，但对不同的行，就需要通过buffer lock进行同步。在此过程中发生的争用，等待buffer busy waits事件。对Index，以及index leaf block的多个修改请求，也可能发生buffer busy waits。对undo block header的争用也会，例如多个会话同时执行update时也会发生。解决方法： update/update引发的buffer busy waits等待，可以通过采用避免对相同块同时执行update的方法得以解决。创建把update形式考虑周全的最优的分区，将成为最好的解决方法。通过取高PCTFREE或使用较小的块，可以将块分散，因为能减少buffer lock争用，但可能有负面效果，所以要测试。
write complete waits DBWR将脏buffer写到磁盘期间，对buffer以exclusive模式占有buffer lock。这时，读取或修改缓冲区的其他进程需要等待此项工作结束，会等待write complete waits事件。这也说明了exclusive/shared buffer lock是会发生冲突的。
解决方法： write complete waits广泛出现，很可能是DBWR性能问题。 IO系统性能缓慢，伴随长时间的db file parallel write，较少的db_writer_processes值，都会导致此类等待过多。以及频繁发生检查点，使DBWR工作量过多，可能是因为取得较少得FAST_START_MTTR_TARGET，重做日志文件过小导致的频繁日志切换，都会使得频繁发生增量检查点。Parallel Query引发的direct path read时，还有truncate,drop,hot backup时也会发生检查点。这时就给DBWR带来不必要的负荷，也会导致这种等待事件增多。