该等待事件我在前面分析过，但是这次和上次产生的原因有些不一样，上次该等待事件的详细分析链接是：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;
原因找到了，发给项目组让开发的同事在创建索引时注意此事项，并进行修改就可以了！
http://blog.sina.com.cn/s/blog_61cd89f60102ef1p.html