在数据库层面如何减少PX DEQ CREDIT SEND BLKD等待

本文给出一些意见用于在数据库层面减少"PX Deq Credit: need buffer"和"PX Deq Credit: send blkd"等待事件。
PX等待事件发生在并行查询的不同进程之间交互数据或信息时。

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

本文不讨论关于2和3的两个原因。

1)并行度的设置

在数据库级，通常需要检查这个并行执行的设置。检查对象是否有并行度的设置。例如通过"alter index rebuild parallel 4;"语句会导致某个索引的并行度为4，但是目的仅是通过并行度4来重建索引，而不回改变并行度。

最好运行下面这篇文章的SQL命令：
Note.270837.1  Report for the Degree of Parallelism on Tables and Indexes 

该脚本的第4个命令将会显示不适当的索引或表的DOP。下面是一个输出的例子：
OWNER  TABLE_NAME   DEGREE  INSTANCES INDEX_NAME   DEGREE  INSTANCES
------ ------------ ------- --------- ------------ ------- ---------
SCOTT  DEPT         1       1         PK_DEPT      4    1
SCOTT  EMP          1       1         PK_EMP       DEFAULT DEFAULT

可以看到索引PK_DEPT和PK_EMP设置有并行度，但是它们的基础表没有。这时就该考虑改变索引的并行度设置为没有并行度。
alter index SCOTT.PK_DEPT noparallel;
第2个脚本用于显示schema中的DOP的描述概要。下面是一个输出的例子：
OWNER  DEGREE     INSTANCES  Num Tables  'PARALLE
------ ---------- ---------- ----------  --------
OSS    1          1                  126 Serial
OSS    8          1                   1  Parallel

可以看到在schema OSS中只有1张表的并行度为8。可能该表不需要设置DOP为8，可以考虑将该表设置为非并行，查找该表可以通过下面这个SQL：
select table_name from all_tables
where ( trim(degree) != '1' and trim(degree) != '0' ) or  
      ( trim(instances) != '1' and trim(instances) != '0' )
      and owner = 'OSS';
输出的结果：
TABLE_NAME
------------------------------
OSS_EMP
设置为非并行：
alter table OSS.OSS_EMP noparallel;

以上的方法就是通过减少并行查询的数量来减少数据的交互。
通常索引或表小于200 MB，不需要设置并行度。

有时可以增大参数PARALLEL_EXECUTION_MESSAGE_SIZE=8k或16k，但这会要求更多的"PX msg pool"。该pool可以通过下面这个查询监控：
select * from v$sgastat where upper(name)  like 'PX%';