Shulou(Shulou.com)06/01 Report--

Continue to verify, using dtrace in solaris

Session1: writing dtrace scripts

More test.dharmharmracer ndtrace:::BEGIN ndtrace:::BEGIN Dtrace1;} pid$1:::entry {printf ("iTunes% d PID::entry:==%s:%s:%s:%s% x% x", I, probeprov, probemod, probefunc, probename,arg0,arg1,arg2,arg3,arg4,arg5); iTunes 1;}

Session2: execute the rowid query several more times to make the query read logically

Create table an as select * from scott.emp;create index ind_a on a (empno); select c. Sid1. Sid # from (select sid from v$mystat where rownum logic_read1.log

Session2: execute it again, which is a logical read

Select * from a where rowid='AAAMjsAABAAAOs6AAA'

Session1: query file, which contains traces made during statement execution

Cat logic_read1.log | wc-l1393

Session2:

Select dbms_rowid.ROWID_RELATIVE_FNO ('AAAMjsAABAAAOs6AAA'), dbms_rowid.rowid_block_number (' AAAMjsAABAAAOs6AAA') from dual;1 60218select file#,dbablk,tch,lower (HLADDR) from x$bh where file#=1 and dbablk=60218; FILE# DBABLK TCH LOWER (HL- 1 60218 8 5f0f596c

Block 60218 of document 1, protected by Latch with the address 5f0f596c

Session1:

Cat logic_read1.log | grep 5f0f596c 1 113271 sskgslcas:entry iTunes 637 PID::entry:==pid1154:oracle:sskgslcas:entry 5f0f596c 0 2000000f fdc1a128 fdc1a0d0 fdc1a128 1 113274 sskgsldecr:entry iTunes 646 PID::entry:==pid1154:oracle:sskgsldecr:entry 5f0f596c 2000000f fdc1a128 fdc1a0d0 fdc1a128 804534c 1 113271 sskgslcas:entry iTunes 687 PID::entry:==pid1154:oracle:sskgslcas:entry 5f0f596c 02000000f 1 fdc1a0c0 5854e074 159436 kcbzar:entry iTunes 692 PID : entry:==pid1154:oracle:kcbzar:entry 5f181bcc 5f0f596c 108000 8045268 1 fdc1a0c0 1 103456 slmxnoop:entry iTunes 693 PID::entry:==pid1154:oracle:slmxnoop:entry 587ed578 fdc1a130 5f0f596c 8045238 a9ef965 c4a88d0 1 103456 slmxnoop:entry iTunes 694 PID::entry:==pid1154:oracle:slmxnoop:entry 587ed578 fdc1a130 5f0f596c 8045238 a9ef965 c4a88d0 1 103456 slmxnoop:entry iTunes 695 PID::entry:==pid1154:oracle:slmxnoop:entry 587ed578 fdc1a130 5f0f596c 8045238 a9ef965 c4a88d0 1 103456 Slmxnoop:entry iTunes 696 PID::entry:==pid1154:oracle:slmxnoop:entry 587ed578 fdc1a130 5f0f596c 8045238 a9ef965 c4a88d0 1 103456 slmxnoop:entry iTunes 697 PID::entry:==pid1154:oracle:slmxnoop:entry 587ed578 fdc1a130 5f0f596c 8045238 a9ef965 c4a88d0 1 103456 slmxnoop:entry iTunes 699 PID::entry:==pid1154:oracle:slmxnoop:entry 587ed578 fdc1a130 5f0f596c 8045238 a9ef965 c4a88d0 1 113274 sskgsldecr:entry iTunes 701 PID::entry:==pid1154:oracle:sskgsldecr: Entry 5f0f596c 2000000f 1 fdc1a0c0 5854e074 8045410 1 54264 k***mf:entry iTunes 703 PID::entry:==pid1154:oracle:k***mf:entry 5f181ba8 5f0bcc2c 587ed578 2000000f 5f0f596c 5f181bcc

There are a dozen lines related to this address (5f0f596c). Here, there is a bit of programming habit. Again, to apply for the Latch at a certain address, the address of the Latch is the most important parameter of this function.

Therefore, Oracle will put it first, that is, in the above dozen lines, the first parameter is not 8ea1d750, which can be basically excluded.

So, these are the only lines we need to pay attention to:

1 113271 sskgslcas:entry iTunes 637 PID::entry:==pid1154:oracle:sskgslcas:entry 5f0f596c 0 2000000f fdc1a128 fdc1a0d0 fdc1a128 1 113274 sskgsldecr:entry iTunes 646 PID::entry:==pid1154:oracle:sskgsldecr:entry 5f0f596c 2000000f fdc1a128 fdc1a0d0 fdc1a128 804534c 1 113271 sskgslcas:entry iTunes 687 PID::entry:==pid1154:oracle:sskgslcas:entry 5f0f596c 020000f 1 fdc1a0c0 5854e074 1 113274 sskgsldecr:entry iTunes 701 PID::entry:==pid1154:oracle:sskgsldecr:entry 5f0f596c 20000f 1 fdc1a0c0 5854e074 8045410

These four lines, two function calls, sskgslcas, sskgsldecr

The first argument is the address of Latch: 5f0f596c. I'm sure it's no coincidence that they are functions that request and release Latch.

In the line iTun637, Oracle calls sskgslcas to hold Latch, and in iTunes 646, calls sskgsldecr to release

Next, the sskgslcas hold Latch is called again at iTunes 687, and the sskgsldecr release is called at iTunes 701.

One logical read corresponds to two Latch calls.

Is this the result? let's continue to verify that Oracle's Oradebug can call some Oracle's own function, so it verifies it:

Session2:

SQL > oradebug setmypidStatement processed.SQL > oradebug call sskgslcas 0x5f0f596c 0 0x2000000f 0xfdc1a128Function returned 1SQL > select * from a where rowid='AAAMjsAABAAAOs6AAA';Hang live

Session3: view events, etc., and release latch

SQL > select sid,event,p1raw,p2 from v$session where sid=159 SID EVENT--P1RAW P2159 latch: cache buffers chains5F0F596C 122SQL > oradebug setospid 1154Oracle pid: 15, Unix process pid: 1154 P_w_picpath: oracle@sol (TNS V1-V3) SQL > oradebug call sskgsldecr 0x5f0f596c 0x2000000fFunction returned 2000000F

Look at it in session2, and the results come out. It shows that the session that has been Hang can be executed smoothly. It means that Latch has been released.

Conclusion: the application function of cbc latch,cbc latch is sskgslcas and the release function is sskgsldecr after one logical reading.

Cbc latch in logical Reading (1): http://qhd2004.blog.51cto.com/629417/1576554

Cbc latch in logical Reading (3): http://qhd2004.blog.51cto.com/629417/1577532

Reference: http://blog.itpub.net/321157/viewspace-730936/

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.