一致性读保证了读不阻塞写

再深入一步，为大家测试下，如果手动将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(当前块)


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

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

QQ:        252803295

Email:    oracledba_cn@hotmail.com

Blog:      http://blog.csdn.net/guoyJoe

ITPUB:   http://www.itpub.net/space-uid-28460966.html

OCM:     http://education.oracle.com/education/otn/YGuo.HTM
 _____________________________________________________________
加群验证问题：哪些SGA结构是必需的，哪些是可选的？否则拒绝申请!!!

答案在：http://blog.csdn.net/guoyjoe/article/details/8624392

Oracle@Paradise 　总群:127149411

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

Oracle@Paradise No.2群:121341761

Oracle@Paradise No.3群:140856036