关于direct path read和latch的问题

gdpr-dba

看了刘大的这篇文章：
直接路径读取对于延迟块清除的影响
http://www.oracledatabase12g.com/archives/direct-read-impact-on-delayed-block-read.html

里面提到direct path read“减少了对栓的使用，避免可能的栓争用”，这个也是可以理解的，因为cache buffer chain只是保护buffer cache的并发访问，而direct path read并没有经过buffer cache。假如此时一个进程先direct path read一个数据块，另外一个进程也尝试从硬盘读取这个数据块时，假如此时没有latch，那oracle如何保护同一个数据块的并发访问呢？

Maclean Liu(刘相兵

direct path read 只能用于查询 read consistent， 且 读取到的block buffer无法复用， 下一次读取时仍需要 direct path read 。  direct path read 要求 之前完成 fast object checkpoint :


Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options


SQL> alter system flush buffer_cache;

System altered.


SQL> alter session set events '10046 trace name context forever,level 12';

Session altered.

SQL> oradebug setmypid;
Statement processed.
SQL> select count(*) from maclean.largedsc;

  COUNT(*)
----------
   4657536

SQL> oradebug tracefile_name;
/s01/orabase/diag/rdbms/vprod/VPROD1/trace/VPROD1_ora_30509.trc


WAIT #139652495272544: nam='direct path read' ela= 515 file number=4 first dba=107908 block cnt=124 obj#=77667 tim=1337065842838967


11g 开始对long table的SCAN 可能会使用direct path read 如上例


[oracle@vrh1 ~]$ ps -ef|grep dbw
grid      4163     1  0 May14 ?        00:00:03 asm_dbw0_+ASM1
oracle    4811     1  0 May14 ?        00:00:12 ora_dbw0_VPROD1
oracle   30575 30342  0 03:11 pts/2    00:00:00 grep dbw
[oracle@vrh1 ~]$ sqlplus  / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Tue May 15 03:11:39 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options

SQL> oradebug setospid 4811;
Oracle pid: 17, Unix process pid: 4811, image: oracle@vrh1.oracle.com (DBW0)

SQL> oradebug suspend;
Statement processed.


suspend 住 dbwr




session A:



SQL> delete maclean.largedsc where rownum<=10000;

10000 rows deleted.

SQL> commit;

Commit complete.



做一些 block change ， 这些chang 在 cache中 没有写入到磁盘


session C:


SQL> alter session set events '10046 trace name context forever,level 12';

Session altered.

SQL> select count(*) from maclean.largedsc;

hang here !!!



因为 无法完成 fast object checkpoint 所以 direct path的SELECT会 hang




SQL> set linesize 200 pagesize 1400

SQL>  select sid,pid ,WAIT_EVENT_TEXT from v$wait_chains;

       SID        PID WAIT_EVENT_TEXT
---------- ---------- ----------------------------------------------------------------
        30         50 enq: KO - fast object checkpoint
       135         19 rdbms ipc message


dbwr 在等待 rdbms ipc message
session C在等待 enq: KO - fast object checkpoint



  SO: 0xbd864358, type: 4, owner: 0xbd4fa8f0, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
     proc=0xbd4fa8f0, name=session, file=ksu.h LINE:12624, pg=0
    (session) sid: 135 ser: 1 trans: (nil), creator: 0xbd4fa8f0
              flags: (0x51) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
              flags2: (0x409) -/-/INC
              DID: , short-term DID:
              txn branch: (nil)
              oct: 0, prv: 0, sql: (nil), psql: (nil), user: 0/SYS
    ksuxds FALSE at location: 0
    service name: SYS$BACKGROUND
    Current Wait Stack:
     0: waiting for 'rdbms ipc message'
        timeout=0xb8, =0x0, =0x0
        wait_id=96757 seq_num=31294 snap_id=1
        wait times: snap=0.003733 sec, exc=0.003733 sec, total=0.003733 sec
        wait times: max=1.840000 sec, heur=0.003733 sec
        wait counts: calls=1 os=1
        in_wait=1 iflags=0x5a8
    There are 1 sessions blocked by this session.
    Dumping one waiter:
      inst: 1, sid: 30, ser: 891
      wait event: 'enq: KO - fast object checkpoint'
        p1: 'name|mode'=0x4b4f0006
        p2: '2'=0x10032
        p3: '0'=0x1
      row_wait_obj#: 4294967295, block#: 0, row#: 0, file# 0
      min_blocked_time: 137 secs, waiter_cache_ver: 6348
    Wait State:
   
   
   
      SO: 0xbdcd7af0, type: 8, owner: 0xbd8ccc38, flag: INIT/-/-/0x00 if: 0x1 c: 0x1
       proc=0xbd51ae40, name=enqueue, file=ksq1.h LINE:380, pg=0
      (enqueue) KO-00010032-00000001    DID: 0001-0032-00000022
      lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  res_flag: 0x3
      mode: SSX, req: X, lock_flag: 0x10, lock: 0xbdcd7b48, res: 0xbdd8c040
      own: 0xbd6ba480, sess: 0xbd6ba480, proc: 0xbd51ae40, prv: 0xbdd8c070
      slk: 0xbbb720c0


'enq: KO - fast object checkpoint'   p1: 'name|mode'=0x4b4f0006



session D:

SQL> select count(*) from maclean.largedsc;

hang again !!!


SQL> select sid,pid ,osid,WAIT_EVENT_TEXT from v$wait_chains;

       SID        PID OSID                      WAIT_EVENT_TEXT
---------- ---------- ------------------------- ----------------------------------------------------------------
        30         50 30623                     enq: KO - fast object checkpoint
       135         19 4819                      rdbms ipc message
        34         54 30735                     enq: KO - fast object checkpoint



恢复  DBW0
        
        
SQL> oradebug resume;
Statement processed.





session D 的10046 trace:

gdpr-dba

刘大貌似没理解我的意思，说得简单点就是假如两个进程同时对一个数据块执行direct path read，没有latch如何保证多个进程对同一个数据块的并发访问？

Maclean Liu(刘相兵

"没有latch如何保证多个进程对同一个数据块的并发访问？"

上面的演示 就是要说明这个问题，  实际是无需保护 因为direct path只是读取物理磁盘上的block， 这就和你用 bbed 或者dul去读了一遍 data file 上的block一样， 因为是 只读的 而且 没有其他 相关内存结构 例如buffer header 所以 也就无所谓 去保护， 只需要保证 direct path之前 完成 fast object checkpoint即可。

不了峰

那如果在direct path read 　开始进行时，修改了还没有读到的块，并且修改的块也更新到数据文件时。那么这时direct path read 会发生什么？
１.继续读下去　，通过构造读一致性来获取数据。那么这时就应该不是direct path read　？
２.direct path read 报错？

Maclean Liu(刘相兵

http://www.oracledatabase12g.com ... yed-block-read.html

其实这篇文章里就介绍了 ， direct path read是 也出现了 cleanouts only - consistent read gets ， direct path read 也会做 cleanout