Oracle的一致性讀保證了讀不阻塞寫

再深入一步，為大家測試下，如果手動將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