|
|
本帖最后由 guoyJoe 于 2013-2-20 13:29 编辑
vage 发表于 2013-2-19 11:39 ![]()
郭大师不如再深入一步，为大家测试下，如果手动将buffer Header中Buffer Pin内存位设置为1，这就等同于加上 ...
为大家测试下，如果手动将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号块组成
２．根据文件号块号获取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号块的状态是当前块
３.查本会话下的会话号，进程号
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
４.用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
４.另开一个会话利用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
5.再回到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(当前块)
６.再开一个新会话，对6号文件131号块的rowid='AAASP9AAGAAAACDAAA'的这行数据做update，把name的值由gyj468修改成gyjdba;
SQL> update gyj.t1 set name='gyjdba' where rowid='AAASP9AAGAAAACDAAA';
1 row updated.
update操作没有发生待等
７.再查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（一致性读块）
８.查等待事件
SQL> select sid,event from v$session where wait_class<>'Idle';
SID EVENT
---------- ----------------------------------------------------------------
140 SQL*Net message to client
没有发生等待
总结一下：在这种情况下读是不会阻塞写的，那我们在AWR中看到的buffer busy waits等待事件是由什么产生的，它是由写(DML/DDL)阻塞读(SELECT)，写阻塞写产生的.
吕大师我有个疑问：那读会阻塞写吗？如果有那么在哪几种情况发生，对了在AWR中看到的dirty buffers inspected等待事件跟读阻塞写有关吗？
|
|
楼主: guoyJoe
IP卡
狗仔卡
发表于 2013-2-19 10:18
显身卡
楼主
