深入解析direct path read (转)

标签：

文章转自：http://www.itpub.net/thread-1815281-1-1.html

       传统读取数据的方式是服务器进程通过读取磁盘，然后把数据加载到共享内存中，这样后面的进程就可以通过共享内存访问这些数据，不用再通过缓慢的磁盘读取来完成。direct path read读取数据块方式，是指服务器进程直接读取数据文件，不经过buffer cache，这种方式读取的数据块会加载到服务器进程的PGA内中当中，不会进入buffer cache中。11G之前的direct path read主要用于并行查询中，此等待事件的三个参数p1,p2,p3分别代表：file#：文件号，first block#：读取的起始块号，block count：以first block为起点，连续读取的物理块数。而从11G之后，direct path read不仅可用于并行查询，在符合某些条件后，串行的全表扫描也可以利用direct path read方式来完成。这里主要介绍11G direct path read相关的特性。
    有一次经历让我印象深刻，那是要对一张大表上一个核心索引进行重建，表的大小几十个G是有的。当时预估了时间（全表扫描+排序）应该十几分钟可以搞定，但是让我吃惊的是整个重建过程足足搞了快1个小时。不停的查看重新索引会话的等待事件，大多数时候都是db file sequential read，零星的能看到几次db file scattered read，虽然指定的多块读大小为128，但是观察到的p3参数小的可怜。导致索引重建慢的原因不难分析，是由于这个表的不少数据被缓存进了buffer cache中，虽然设置的多块读参数为128，但是由于总是无法读取到符合要求的连续的数据块而让性能大打折扣，这里所谓的符合要求指的是读取的数据块都不在buffer cache之中。例如：

    上面的12个块为一个extent，假设都不在buffer cache中的话，一次物理IO就可以完成，但是由于部分块被cache，而导致总共需要6次的物理IO才行。因此在做全表扫描的情况下，表里的数据一部分被cache并不见得总是好事。当时我在想，如果可以绕过buffer cache，直接路径读取就好了。11G以后，ORACLE终于推出了这个功能，在全表扫描的时候，如果ORACLE认为这个表足够大，就会启用直接路径读取，而不需要像11G之前，必须先把数据加载到buffer cache。
采用direct path read完成读取的条件
1）表大于_small_table_threshold的参数值设置
    Oracle通过隐含参数_small_table_threshold来界定大表小表的临界，Oracle认为对于大表执行直接路径读取的意义比较大，对于小表通过将其缓存可能受益更大。_small_table_threshold的单位为block。默认为db cache size的2%大小，在实例启动过程中动态决定。11GR2之前，表的大小要是_small_table_threshold参数值的5倍才会采取直接路径读取方式，11GR2后只需要满足_small_table_threshold定义的大小就会采取直接路径读取。我们可以简单的看一下11GR2下的一个测试：
create tablespace test datafile ‘+DG_DATA/test/test.dbf‘ size 64m segment space management manual;
create table t (v varchar2(100)) pctused 1 pctfree 99 tablespace test;
show parameter small
NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_small_table_threshold               integer                3000
CREATE OR REPLACE FUNCTION GET_ADR_TRSH(P_STEP  IN NUMBER,
                                        P_START IN NUMBER DEFAULT 0,
                                        P_STOP  IN NUMBER DEFAULT NULL)
  RETURN NUMBER IS
  L_PRD    NUMBER;
  L_CNT    NUMBER;
  L_BLOCKS NUMBER := 0;
  L_START  NUMBER := P_START;
BEGIN
  EXECUTE IMMEDIATE ‘truncate table t‘;
  LOOP
    INSERT /*+ append */
    INTO T
      SELECT RPAD(‘*‘, 100, ‘*‘)
        FROM DUAL
      CONNECT BY LEVEL <= P_STEP + L_START;
    COMMIT;
    L_BLOCKS := L_BLOCKS + P_STEP + L_START;
    L_START  := 0;
    EXECUTE IMMEDIATE ‘alter system flush buffer_cache‘;
    SELECT /*+ full(t) */
     COUNT(*)
      INTO L_CNT
      FROM T;
    SELECT VALUE
      INTO L_PRD
      FROM V$SEGMENT_STATISTICS
     WHERE OWNER = USER
       AND OBJECT_NAME = ‘T‘
       AND STATISTIC_NAME = ‘physical reads direct‘;
    EXIT WHEN(L_PRD > 0 OR L_BLOCKS > NVL(P_STOP, L_BLOCKS));
  END LOOP;
  RETURN L_BLOCKS - P_STEP;
END;
/
set serveroutput on
DECLARE
  L_TRSH NUMBER;
BEGIN
  L_TRSH := GET_ADR_TRSH(10, 1500, 4000);
  DBMS_OUTPUT.PUT_LINE(L_TRSH);
END;
/       
3000
以上的代码大家可以研究一下，我不做详细说明了，大体的意思是不断的增加表大小，观察增加到表上的block有多少时，会采取直接路径读取。我们测试的结果是3000，刚好和我们定义的_small_table_threshold参数值完全吻合。11GR1的话，经过测试是_small_table_threshold的5倍的时候才会出现直接路径读取。
但是表的大小并不仅仅是唯一决定是否采用直接路径读取的因素，还有其他两个因素：脏块的比例、表中数据被cache的比例
2）表上的脏块小于表总block数的25%
    下面的代码通过不断增加表的脏块数，当达到表脏块数的25%的时候，不在发生直接路径读取事件了。
CREATE OR REPLACE FUNCTION GET_DIRTY_TRSH(P_STEP  IN NUMBER,
                                          P_START IN NUMBER DEFAULT 0,
                                          P_STOP  IN NUMBER DEFAULT NULL)
  RETURN NUMBER IS
  L_TRSH  NUMBER := 0;
  L_PRD   NUMBER := 0;
  L_CNT   NUMBER := 0;
  L_START NUMBER := P_START;
BEGIN
  EXECUTE IMMEDIATE ‘alter system flush buffer_cache‘;
  LOOP
    L_TRSH := L_TRSH + P_STEP + L_START;
    UPDATE T SET V = V WHERE ROWNUM <= L_TRSH;
    COMMIT;
    L_START := 0;
    SELECT /*+ full(t) */
     COUNT(*)
      INTO L_CNT
      FROM T;
    SELECT VALUE
      INTO L_CNT
      FROM V$SEGMENT_STATISTICS
     WHERE OWNER = USER
       AND OBJECT_NAME = ‘T‘
       AND STATISTIC_NAME = ‘physical reads direct‘;
    EXIT WHEN L_CNT = L_PRD OR L_TRSH > NVL(P_STOP, L_TRSH);
    L_PRD := L_CNT;
  END LOOP;
  RETURN L_TRSH;
END;
/
DECLARE
  L_TRSH NUMBER;
BEGIN
  L_TRSH := GET_DIRTY_TRSH(1, 350, 4000);
  DBMS_OUTPUT.PUT_LINE(L_TRSH);
END;
/
739
我们看到脏块的比例大约达到表块的25%（共3000个表块）的时候，直接路径读消失了。
3）表中的块被cache的比例小于50%的时候
CREATE OR REPLACE FUNCTION GET_CACHED_TRSH(P_START IN NUMBER DEFAULT 0,
                                           P_STEP  IN NUMBER DEFAULT 1)
  RETURN NUMBER IS
  CURSOR L_CUR IS
    SELECT /*+ index(t i_t) */
     t
      FROM T WHERE v=‘****************************************************************************************************‘;
  L_V     VARCHAR2(100);
  L_TRSH  NUMBER := 0;
  L_PRD   NUMBER := 0;
  L_CNT   NUMBER := 0;
  L_START NUMBER := P_START;
BEGIN
  EXECUTE IMMEDIATE ‘alter system flush buffer_cache‘;
  OPEN L_CUR;
  LOOP
    FOR I IN 1 .. P_STEP + L_START LOOP
      FETCH L_CUR
        INTO L_V;
    END LOOP;
    L_TRSH  := L_TRSH + P_STEP + L_START;
    L_START := 0;
    SELECT /*+ full(t) */
     COUNT(*)
      INTO L_CNT
      FROM T;
    SELECT VALUE
      INTO L_CNT
      FROM V$SEGMENT_STATISTICS
     WHERE OWNER = USER
       AND OBJECT_NAME = ‘T‘
       AND STATISTIC_NAME = ‘physical reads direct‘;
    EXIT WHEN L_CNT = L_PRD OR L_CUR%NOTFOUND;
    L_PRD := L_CNT;
  END LOOP;
  CLOSE L_CUR;
  RETURN L_TRSH;
END;
/
create index i_t on t (v);
DECLARE
  L_TRSH NUMBER;
BEGIN
  L_TRSH := GET_CACHED_TRSH(500, 1);
  DBMS_OUTPUT.PUT_LINE(L_TRSH);
END;
/
1497
在接近50%（共3000个表块）的表块被cache的时候，直接路径读消失了。

11GR1

11GR2

备注

块阀值

_small_table_threshold*5

_small_table_threshold

统计信息里记录的表的block数目（11GR2)。

超过此阀值后。

Block cache阀值

表块的50%

表块的50%

少于此阀值

脏块阀值

表块的25%

表块的25%

少于此阀值

满足以上条件时，Oracle会进行直接路径读取。

Oracle为直接路径读取设置的三个“门槛”，非常的合理：

第一个阀值：表大小，太小的表从direct path read中的获益太小。但是特别需要引起你的警惕，如果表上存在统计信息，那么ORACLE会采取表的统计信息中记录的block与_small_table_threshold的设定值来做比较，而不是表的真实大小（dba_segments中记录的值）。这可能导致一些不是你预期的情况发生。如果你的统计信息与表的真实情况差异很大，那么你应该仔细考虑可能发生什么样的结果。如果你的表没有统计信息，ORACLE会依据表的真实大小来决定是否进行direct path read。

第二个阀值：脏块阀值，由于direct path read需要出发一个段的检查点，因此脏块太多，刷新脏块可能会导致IO繁忙

第三个阀值：表在内存里的cache率,如果cache率很高，那么还是走传统路径更快。direct path read的出现，需要让ORACLE公司的开发人员设计一个单独的结构来存储每个表有多少数据是脏数据，有多少数据被cache。不过这个结构目前还并未暴露给我们查询。在flush buffer cache后，这个结构被清空。（flush shared_pool并不会被清空）

当你预期一个查询应该会走direct path read，但是却走了传统的路径扫描的时候，应该检查是否违背了这三个前置条件中的一个或几个。不过很多时候，当一个查询“应该”走direct path read但是却没有的时候，你往往无能为力，你能在数据库运行过程中修改表的数据的cache比例吗？不能！你能修改表的脏数据的比例吗？往往也不能，通过修改表的统计信息中的表块数，可以满足第一个条件，但是如果不满足其他两个条件，依然不能有效。你可以通过flush buffer cache来满足后两个条件，但往往在生产环境中不被允许。我曾经在个人微博(新浪微博：魏兴华-DBA)发布过一个关于索引创建走不上direct path read的微博，现在终于想明白了，不满足第三个条件，表被cache的内容需要低于50%。

direct path read的优势

• 我认为非常重要的，参照我文章开头举得例子，采用直接路径读取后，总能保证读取的块数是多块读参数设置的大小，提高了读取的效率
• 大大的降低了对于latch的使用，进而避免了可能导致的latch竞争（cbc latch等）
• 降低了全表扫描对buffer cache的冲击
• 降低了buffer pin的开销，有可能降低buffer busy waits等相关等待

• event 10949设置后，可以禁用direct path read。

• 会发生段一级的检查点（后面详细介绍），因此在查询真正开始执行前，会做这个额外的准备工作。而且可能会造成IO抖动，因为要写脏数据。
• 如果你的表需要频繁的全表扫描读取，还是用传统的读取方式比较好。
• 在MOS中搜索direct path read，会发现它可能会导致多次的延迟块清除（后面详细介绍）

深入解析direct path read (转)

标签：

原文地址：http://www.cnblogs.com/hellojesson/p/4570790.html