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物理大小
当前位置：
论坛首页 »
自由讨论区 »
MySQL, Oracle及数据库讨论区
»
发起投票
技术讨论
加好友
发消息
2011-8-3 16:59:11 |
赞(
操作
