事件。加速物理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带来不必要的负荷，也会导致这种等待事件增多。
|