再深入一步，为大家测试下，如果手动将buffer Header中Buffer Pin内存位设置为1，这就等同于加上了共享Buffer Pin锁，这时另开一个会话，更新这个块，会有什么情况呢?

1、取T1表的第一行数据做测试：

SQL> select rowid,dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid) block#,id,name from gyj.t1　where rownum=1;

ROWID                   FILE#     BLOCK#         ID   NAME

------------------ ---------- ---------- ----------   --------------

AAASP9AAGAAAACDAAA          6        131        468   gyj468

这里的DBA(Data Block Address)就是由6号文件和131号块组成

2、根据文件号块号获取CBC Latch的地址

SQL> select hladdr,ba,decode(state,0,'free',1,'xcur',2,'scur',3,'cr', 4,'read',5,'mrec',6,'irec',7,'write',8,'pi',9,'memory',10,'mwrite',11,'donated') status from x$bh where file#=6 and dbablk=131;

HLADDR           BA               STATUS

---------------- ---------------- -------

00000003A43FA468 000000039459C000 xcur    --BA=000000039459C000时这个块的状态是xcur(当前块)从上面可以看出6号文件131号块的状态是当前块

3、查本会话下的会话号，进程号

SQL> select s.sid,spid from v$session s,v$process b where s.paddr=b.addr and s.sid in(select sid from v$mystat where rownum=1);

SID SPID

---------- ------------------------

125 1545

从上面看出会话号125,进程号1545

4、用Dtrace跟踪一下找到buffer pin的地址3947e73d0

1  51768        sskgslcas:entry i=23 PID::entry:==pid1545:oracle:sskgslcas:entry 3947e73d0 0 1 0 3947e

如何查到buffer pin地址查看这个链接：5、另开一个会话利用oradebug工具

SQL> conn / as sysdba

Connected.

SQL> select distinct sid from v$mystat;

SID

----------

16

SQL> oradebug peek 0x3947e73d0 4　　　　　　  --查6号文件131号有没有buffer pin

BEFORE: [3947E73D0, 3947E73D4) = 00000000　 --从这个值上看在6号文件131号块上没有加buffer pin

SQL> oradebug poke 0x3947e73d0 4 1　　　　　　--在6号文件131号加buffer pin

BEFORE: [3947E73D0, 3947E73D4) = 00000000

AFTER:  [3947E73D0, 3947E73D4) = 00000001         --由0变成1，说明已加上了buffer pin

6、再回到125号会话下，查6号文件131号块的数据

SQL> select * from gyj.t1 where rowid='AAASP9AAGAAAACDAAA';

ID　　NAME

----------　-----------------------------

468　　gyj468

SQL> select hladdr,ba,decode(state,0,'free',1,'xcur',2,'scur',3,'cr', 4,'read',5,'mrec',6,'irec',7,'write',8,'pi',9,'memory',10,'mwrite',11,'donated') status from x$bh where file#=6 and dbablk=131;

HLADDR           BA               STATUS

---------------- ---------------- -------

00000003A43FA468 000000039459C000 xcur   --BA=000000039459C000时这个块的状态是xcur(当前块)

7、再开一个新会话，对6号文件131号块的rowid='AAASP9AAGAAAACDAAA'的这行数据做update，把name的值由gyj468修改成gyjdba;

SQL> update gyj.t1 set name='gyjdba' where rowid='AAASP9AAGAAAACDAAA';

1 row updated.

--update操作没有发生待等

8、再查6号文件131号块，有两条记录，多产生了一条状态是CR的记录

SQL> select hladdr,ba,decode(state,0,'free',1,'xcur',2,'scur',3,'cr', 4,'read',5,'mrec',6,'irec',7,'write',8,'pi',9,'memory',10,'mwrite',11,'donated') status from x$bh where file#=6 and dbablk=131;

HLADDR           BA               STATUS

---------------- ---------------- -------

00000003A43FA468 000000038F442000 xcur    --从BA这个字段可以看出这是新产生出来的，就是后面的UPDATE操作，xcur当前块

00000003A43FA468 000000039459C000 cr      --BA＝000000039459C000可以看出这是原来做SELECT的操作，由状态xcur(当前块)变成cr(一致性读块)

9、查等待事件

SQL> select sid,event from v$session where wait_class<>'Idle';

SID EVENT

---------- ----------------------------------------------------------------

140 SQL*Net message to client                                  --没有发生等待

10、总结一下：在这种情况下读是不会阻塞写的，那我们在AWR中看到的buffer busy waits等待事件是由什么产生的，它是由写(DML/DDL)阻塞读(SELECT)和写阻塞写产生的。

11、思考个问题：

那读会阻塞写吗？

如果有那么在哪几种情况发生？

在AWR中看到的dirty buffers inspected等待事件跟读阻塞写有关吗？

12、读阻塞读的测试，链接地址：

**********本博客所有内容均为原创，如有转载请注明作者和出处!!!**********

Name:    guoyJoe

QQ:        252803295

Email:    oracledba_cn@hotmail.com

OCM:    http://education.oracle.com/education/otn/YGuo.HTM

_____________________________________________________________

加群验证问题：哪些SGA结构是必需的，哪些是可选的？否则拒绝申请!!!

Oracle@Paradise 　总群:127149411

Oracle@Paradise No.1群:177089463(已满)

Oracle@Paradise No.2群:121341761

Oracle@Paradise No.3群:140856036