有一些数据库性能问题可能是因为同时启动的并行进程过多造成的，特别常见于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;
这个用户的问题是，hint的写法写错了，没有使用括号，写成了/*+ parallel a,8*/，系统认为就是/*+ parallel a*/，而忽略了后面的数字8，结果使用了自动并行度= PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT;
而语句中又有group by，于是最终并行度= PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT × 2。
在现在的多CPU主机上，auto DOP是比较危险的，一般都会产生较多的并行进程。