select/select 引起的read by other session

select/select 引起的buffer lock争用，发生在将相同块载入到内存的过程中，通过read by other session等待事件观察。

在oracle 9i中，相当于reason code 130的buffer busy waits等待，我们可以通过测试了解select/select引起的buffer lock争用怎样

发生的，测试方案如下：

      1)创建拥有5万行的BFW_TEST表

      2)多个进程同时对BFW_TEST表执行select

      3)在此过程中，多个进程同时想对一个块获得buffer lock过程中，发生buffer lock竞争。

      

     测试5  select /select引起的buffer lock争用

     

     20个会话同时读取相同的表时，read by other session事件等待广泛地出现，利用v$session_wait视图扑捉read by other session等待事件。

 就可获得更准确的信息。

     

     请注意一点，发生read by other session等待时，同时发生df file sequential read,db file scattered read等待等I/O等待现象。

 read by other session等待在其属性上一直与物理i/o同时出现，因此以相同方式再次进行测试时，就因为数据已位于高速缓冲区，所以

 不发生物理i/o.自然read by other session等待以及db file sequential read,db file scattered read等现象也会消失。要读取的块

 已载入到SGA，因为以shared模式已获得了buffer lock,所以不会发生buffer lock争用，read by other session等待事件与db file sequential

 db file scattered read等待事件密切相关，请大家理解这一点。

 

      

      之前已经讲过buffer lockm只有shared 模式和exclusive模式，读取sga上的块是以shared模式获得buffer lock,所以不发生读取工作引起的

 buffer lock争用，但是发生物理i/o后将新块载入到sga需要创建新的缓冲区，因此最初创建缓冲区的进程以exclusive模式获得buffer lock,这样

 其他想以shared 模式读取此块的会话需要等待exclusive模式的buffer lock释放，此时会发生read by other session等待，请留意，上述情况中，

 即便是读取工作时，因为创建新的缓冲区，所以也会以exclusive模式获得buffer lock,这与hared parsing发生时对相应的sql cursor以exclusive

 模式获得library cache pin相类似的概念，对此问题会在library cache相关等待事件上仔细进行讨论。

 

 

     以上测试结果，成为减少物理i/o的有一根据，而且提供了优化逻辑I/O本事的必要性，因为减少逻辑I/O，物理I/O也会随着减少。

 在上面的测试中，因为SGA的大小足以想要读取的对象块全部载入，所以重复相同的测试可以基本上消除I/O以及BUFFER LOCK相关等待。到若是SGA过小

 或读取过多过程中，其他会话使得要读取的块从SGA丢失，则再次发生物理I/O持续出现Read by other session等待。

     

     减少select/select引起的ready by other sessoon等待的方法，整理结果如下：

     1、应该通过对SQL进行优化，以便能以最少的I/O获得所需的结果

     2、若SGA大小比全局的I/O小，就不能只通过SQL调优解决问题，还需要增加SGA物理大小

     

      

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7194105/viewspace-703984/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7194105/viewspace-703984/