再深入一步，为大家测试下，如果手动将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地址查看这个链接：http://www.itpub.net/thread-1764511-2-3.html
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(当前块)
查看本栏目更多精彩内容：http://www.bianceng.cnhttp://www.bianceng.cn/database/Oracle/
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、读阻塞读的测试，链接地址：
http://blog.csdn.net/guoyjoe/article/details/8585391
或
http://www.itpub.net/thread-1764511-1-1.html