早上巡检数据库时发现报表数据库负载有些异常，取了当时的AWR进行分析，发现一个从未见过的等待事件，记录一下分析过程：

    http://s5/mw690/001N2SGity6E8sLDTsof4&690Deq Credit: send blkd" TITLE="AWR实战分析之----PX Deq Credit: send blkd" />

    从上图看，会话数量和DB Time相对平时偏大，更何况发生的时间是零辰，有点小奇怪，看看TOP 5
    http://s13/mw690/001N2SGity6E8sLFfDCfc&690Deq Credit: send blkd" TITLE="AWR实战分析之----PX Deq Credit: send blkd" />

    从TOP 5上看，排在第一位的是direct path read它的产生原理：

1.与直接读取相关联的等待事件。当ORACLE将数据块直接读入会话的PGA（进程全局区）中，同时绕过SGA（系统全局区）。PGA中的数据并不和其他的会话共享。即表明，读入的这部分数据该会话独自使用，不放于共享的SGA中。
2.在排序操作(order by/group by/union/distinct/rollup/合并连接)时，由于PGA中的SORT_AREA_SIZE空间不足，造成需要使用临时表空间来保存中间结果，当从临时表空间读入排序结果时，产生direct path read等待事件。
3.使用HASH连接的SQL语句，将不适合位于内存中的散列分区刷新到临时表空间中。为了查明匹配SQL谓词的行，临时表空间中的散列分区被读回到内存中(目的是为了查明匹配SQL谓词的行)，ORALCE会话在direct path read等待事件上等待。
4.使用并行扫描的SQL语句也会影响系统范围的direct path read等待事件。在并行执行过程中，direct path read等待事件与从属查询有关，而与父查询无关，运行父查询的会话基本上会在PX Deq:Execute Reply上等待，从属查询会产生direct path read等待事件。
   

    可是在这里我们没有看到所谓的PX Deq:Execute Reply等待事件，但是发现了和它相似的PX Deq Credit: send blkd 经过查询官网发现，PX Deq Credit: send blkd 和PX Deq Credit: need buffer 

    官方解释产生原因如下：

     1.有大量的不同进程之间的数据和信息的交互导致等待。原因可能是一个比较糟糕的执行计划用于了并行执行。
     2.等待是由于资源的问题，如CPU或相互连接等。例如CPU利用率达到100%，进程达到了CPU的限制，而不能足够快地发送数据。
     3.由于并行查询hang住，如等待事件为"PX Deq Credit: need buffer"。

    说明： Deq = DEQUEUE，这是一个关于出队的等待；  PX等待事件发生在并行查询的不同进程之间交互数据或信息时。 这些等待事件在系统负载很轻的时候，大都是没问题的，但是当系统的负载很重，此类等待事件已经进入top5等待事件中那就需要注意了，在查询gv$等视图和并行查询都会产生此类等待事件。

    两个TOP 5中的等待事件都指向了并行查询，然后我看了一下TOP SQL，才发现问题产生的原因，请看下图

http://s2/mw690/001N2SGity6E8utks5r31&690Deq Credit: send blkd" TITLE="AWR实战分析之----PX Deq Credit: send blkd" />
    发现 "BEGIN sys.dbms_stats.gahter_sc......."在下面的TOP SQL模块中都排在第一位   

    SQL ordered by CPU Time

    SQL ordered by Gets

    SQL ordered by Reads

    原来产生的原因是收集统计信息语句块指定并行度引起起的，脚本如下：

BEGIN
  sys.dbms_stats.gather_schema_stats(ownname          => 'CUECM',
                                     estimate_percent => dbms_stats.auto_sample_size,
                                     method_opt       => 'FOR ALL INDEXED COLUMNS SIZE AUTO',
                                     cascade          => true,
                                     options          => 'GATHER AUTO',
                                     degree           => 8);
END;

    该脚本是我时凌晨时分手工执行的统计信息收集脚本，并行度过高！经过查询联机文档，官方建议采用自动确定并行度，脚本修改如下：

BEGIN
  sys.dbms_stats.gather_schema_stats(ownname          => 'CUECM',
                                     estimate_percent => dbms_stats.auto_sample_size,
                                     method_opt       => 'FOR ALL INDEXED COLUMNS SIZE AUTO',
                                     cascade          => true,
                                     options          => 'GATHER AUTO',
                                     degree           => dbms_stats.auto_degree);
END;

    官网相关文档：738464.1