oracle Buffer pin锁的过程(Buffer busy waits)
如果先读后写
申请一个buffer，数据从undo和老的buffer中克隆到新的里，老的buffer状态从XCUR改成CR，给读用，新的buffer状态从0改成XCUR，成为新的当前读buffer。
如果先写后读
申请一个buffer，数据从undo和老的buffer中克隆到新的里，新的buffer状态从0改成CR，给读用。
如果先读后写，同时又来了个读
最后一个读被堵塞，buffer busy waits
Buffer busy waits原理、处理，见本人另外一篇文章
过程
A进程读
B进程写同个BH
1.A进程在BH共享buffer pin，释放CBC latch
2.B进程获得CBC latch，查看BH中的buffer pin锁状态，发现有其他进程留的S锁
3.B进程在BH留一个S锁（共享），释放CBC latch，在buffer pin的保护下把buffer复制到buffer cache中的另个buffer中（过程为buffer clone=buffer克隆，见3-18图），然后新增一个BH（在CBC latch保护下进行），新的BH建完后，CBC latch释放。
4.上面buffer克隆开始时，原BH 的buffer status是XCUR（当前块），新的BH的status没有值。
5.在上面CBC链表中新增完BH后，获得CBC latch，修改原BH中的buffer status为CR（consist read一致读），新的BH中的status为XCUR（当前块），同时，新BH中设置独占buffer pin锁，准备开始修改buffer。至此buffer克隆结束。
克隆数据过程中，老的xcur块中有的直接考到新的种，老的没有的（比如1会话delete掉的），在undo中获取。
6.如果在改新buffer时（CBC latch下了，BH1有共享buffer pin，BH2有独占buffer pin），刚好有C进程也要读5号文件的1234号块，需要进行等待。C进程要在status为XCUR的BH中加共享的buffer pin锁，但是因为BH中有一个独占buffer pin锁，所以C进程被堵塞。这个等待就是buffer busy waits。
在10g-12c中， buffer busy waits：读不堵塞写，写堵塞读。
所以造成buffer busy waits的等待只能是DML语句。
本文从Oracle内核技术揭秘_吕海波中理解
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69980685/viewspace-3003158/ ，如需转载，请注明出处，否则将追究法律责任。
