Oracle's consistent read guarantees read not blocking write

A further step, for everyone to test, if manually the buffer header buffer pin memory bit set to 1, which is equivalent to adding a shared buffer pin lock, then another session, update this block, what will happen?

1, take T1 table of the first row of data to do testing:
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

The DBA (Data block address) is made up of 6th files and 131th blocks.

2. Obtain the address of CBC latch according to the document number block number
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 ', ten, ' Mwrite ', one, ' donated ') status from X$bh where file#=6 and dbablk=131;

Hladdr BA STATUS
---------------- ---------------- -------
00000003a43fa468 000000039459c000 Xcur--ba=000000039459c000 The state of this block is xcur (current block) from above you can see that the state of block 6th is the current block.

3, the session number under this session, the process number
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 ro Wnum=1);

SID SPID
---------- ------------------------
125 1545
See from above session number 125, process number 1545

4, use DTrace to track the address of the buffer pin found 3947E73D0
1 51768 sskgslcas:entry i=23 pid::entry:==pid1545:oracle:sskgslcas:entry 3947e73d0 0 1 0 3947e
How to check the buffer pin address Check this link: http://www.itpub.net/thread-1764511-2-3.html
5. Open another session using Oradebug tools
Sql> Conn/as SYSDBA
Connected.
Sql> select distinct SID from V$mystat;

Sid
----------
16
sql> Oradebug Peek 0x3947e73d0 4--Check 6th file 131th No buffer pin
Before: [3947e73d0, 3947e73d4) = 00000000--From this value, there is no buffer pin on the number 131th block of document 6th.
Sql> oradebug Poke 0x3947e73d0 4 1--Add a buffer pin to document 131th, 6th
Before: [3947e73d0, 3947e73d4) = 00000000
After: [3947e73d0, 3947e73d4) = 00000001--changed from 0 to 1, indicating that a buffer pin has been added

6, go back to the 125th session, check the number 6th file 131th block data
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 ', ten, ' Mwrite ', one, ' donated ') status from X$bh where file#=6 and dbablk=131;

Hladdr BA STATUS
---------------- ---------------- -------
00000003a43fa468 000000039459c000 Xcur--ba=000000039459c000 The state of this block is xcur (current block)

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/database/Oracle/

7, to open a new session, the 6th file 131th block rowid= ' aaasp9aagaaaacdaaa ' of this line of data do update, the name of the value from gyj468 modified into GYJDBA;
sql> Update gyj.t1 set name= ' gyjdba ' where rowid= ' aaasp9aagaaaacdaaa ';

1 row updated.
--update operation did not occur wait

8, check 6th file 131th block, there are two records, more than a state is a CR record
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 ', ten, ' Mwrite ', one, ' donated ') status from X$bh where file#=6 and dbablk=131;
Hladdr BA STATUS
---------------- ---------------- -------
00000003a43fa468 000000038f442000 Xcur--From the BA field you can see that this is a new generation, the later update operation, xcur the current block
00000003a43fa468 000000039459c000 CR--ba=000000039459c000 can be seen as the original select operation, from the state xcur (the current block) into CR (consistent read block)

9, check the waiting event
Sql> Select Sid,event from v$session where wait_class<> ' Idle ';

SID EVENT
---------- ----------------------------------------------------------------
140 Sql*net message to client--no waiting to happen

10, summed up: In this case reading is not blocked write, then we see in the awr of the buffer busy waits wait event is produced by, it is written (DML/DDL) blocking read (SELECT) and write blocking write.

11, consider a question:
Does that read block writing?
If so, in what ways?
Dirty buffers inspected wait events to read blocking write in awr?

12, read blocking read the test, link address:
http://blog.csdn.net/guoyjoe/article/details/8585391
Or

Http://www.itpub.net/thread-1764511-1-1.html