什么是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，也可以减少此类等待