SQL并行产生进程数量问题

有一些数据库性能问题可能是因为同时启动的并行进程过多造成的，特别常见于RAC节点重启，很多时候是因为瞬间启动了几百个并行进程，导致OS各项指标“彪高”，后台进程失去响应。最近遇到的一个，是因为SQL语句中写了/*+ parallel a,8*/  ，但是在RAC的两个节点上各启动了512个并行进程，一共启动了1024个并行进程，导致网络心跳丢失。因为问题可以通过执行这个语句重现，而使用parallel_force_local=true可以workaround这个问题，所以基本可以确定是跨节点并行导致的。

抛开这个问题背后的其他因素不谈，我们单来讨论一下：一条SQL语句究竟会产生多少个并行进程

一条SQL语句使用的并行度受3个层面的数值影响：

1)hint中指定的并行度

select /*+ parallel(a,8) */ * from scott.emp a order by ename;

2)表的并行度，也就是表的degree:

select owner,table_name,degree from dba_tables where table_name='EMP';

OWNER                          TABLE_NAME                     DEGREE   

------------------------------ ------------------------------ ----------

SCOTT                          EMP                                     2 

3)auto DOP

单节点：auto DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT

RAC：auto DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT

他们的优先级是hint>degree>auto DOP，也就是说：

1）如果hint指定了并行度，会忽略表的degree。

2）如果hint只指定parallel，不写具体的数字，或者表上DEGREE显示为DEFAULT，没有具体数值(alter table scott.emp parallel不指定具体degree数值)，则会使用auto DOP。

除此之外，还有以下一些规则：

1）如果表中有group by或者其他排序操作，以上并行度×2。

2）RAC中，并行度会自动平均分配到各个节点上，比如并行度256，2个节点，则每个节点上各起128个并行进程。

“并行度>parallel_max_servers”的判断在各个节点上进行。

3）在PARALLEL_ADAPTIVE_MULTI_USER = TRUE 的情况下，会根据系统load（当前正在使用并行的用户数），将并行度乘以一个衰减因子。

4）如果以上并行度>parallel_max_servers能够提供的空闲并行进程数，则最终并行度=0，也就是不并行（不使用Pnnn的进程）。

举一些例子来更详细的说明它：

1）如果SQL中没有使用hint，而表上degree=1则并行度=0;

2）如果SQL中没有使用hint，而表上degree=DEFAULT 则并行度=PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT;

3）如果SQL中没有使用hint，而表上degree>1 则并行度=表上degree;

4）如果SQL中使用没有数值的hint(/*+ parallel */ )，无论表上degree的值是多少，并行度= PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT;

5）如果SQL中使用带数值的hint(/*+ parallel (a,8)*/ or /*+ parallel (a 8)*/ )，无论表上degree的值是多少，并行度= hint中的数值(8);

6）如果有排序操作，以上并行度×2;

7）并行度分配到各个RAC节点，乘以衰减因子，如果最终并行度>parallel_max_servers能够提供的空闲并行进程数，则并行度=0;