转载地址：http://blog.sina.com.cn/s/blog_61cd89f60102ef1p.html
早上巡检数据库时发现报表数据库负载有些异常，取了当时的AWR进行分析，发现一个从未见过的等待事件，记录一下分析过程：
从上图看，会话数量和DB Time相对平时偏大，更何况发生的时间是零辰，有点小奇怪，看看TOP 5
从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，才发现问题产生的原因，请看下图
发现 "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
案例2
该等待事件我在前面分析过，但是这次和上次产生的原因有些不一样，上次该等待事件的详细分析链接是：http://blog.sina.com.cn/s/blog_61cd89f60102eeen.html ，本次原理和上次是一样的，但是引起的原因很典型，记录一下排查过程。
结合发生的时间点，从上图我们可以看出，此时数据库负载相对较高，我们年看load profile部分情况
从load profile模块来看，数据库解析比较严重，并且事务数和每秒登陆次数明显有异常，但是我们还需要结合TOP 5等待事件来看数据库在等什么？
从TOP 5我们可以看到，数据库发生了严重的并行等待，PX Deq Credit :send blkd的原理是：
1.有大量的不同进程之间的数据和信息的交互导致等待，原因可能是一个比较糟糕的执行计划用于了并行执行。
2.等待是由于资源的问题，如CPU或相互连接等。例如CPU利用率达到100%，进程达到了CPU的限制，而不能足够
快地发送数据。
3.由于并行查询hang住，如等待事件为"PX Deq Credit: need buffer"。
说明： Deq = DEQUEUE，这是一个关于出队的等待； PX等待事件发生在并行查询的不同进程之间交互数据或信息时。 这些等待事件在系统负载很轻的时候，大都是没问题的，但是当系统的负载很重，此类等待事件已经进入top5等待事件中那就需要注意了。
结合该等待事件的原理我们进行排除，因为本案例中数据库服务器CPU使用率不高，并且没有出现"PX Deq Credit: need buffer"。 等待事件，那么我们可以排除第2、3两条，原因只有是第1条了，并行执行并且是糟糕的执行计划，我们先来看看TOP SQL是什么SQL然后再去分析执行计划
第一条SQL原因已经排除，我们重点关注标红部分，该SQL在这个时间点执行6697次多少有些异常，我们仔细分析一下SQL：
SELECT T.ID,
T.DEPTID,
T.DEPTNAMETYPE,
T.STARTDATE,
T.ENDDATE,
T.SUBPROCSSINSTID
FROM T_REPORT_REALTIME_ITEM T
WHERE T.GLOBLASN = :B1
ORDER BY T.SUBPROCSSINSTID, T.STARTDATE, T.ENDDATE
可以看出，该SQL其实是很简单的一条SQL，也没有hint使用parallel并行，但是问题到底出在那里呢？因为上次案例中是统计信息收集时我使用了degree属性导致的，这时我突想到索引创建时也可以使用parallel索引， 并且在网上看到过因索引degree引发的故障，下面来确认一下
select table_name, index_name, index_type, degree, partitioned, status
from dba_indexes
where table_name = 'T_REPORT_REALTIME_ITEM'
and degree > 2
结果还真是，该表中有五个索引使用了parallel方法进行索引创建，并且创建完成以后并没有将degree改为1，而且该表查询次数较多，导致数据库中产生严重的：PX Deq Credit :send blkd等待事件
该类等待事件处理方法也很简单，将索引degree改为1即可，具体操作方法是：
alter index index_name noparallel;
原因找到了，发给项目组让开发的同事在创建索引时注意此事项，并进行修改就可以了！