有一些数据库性能问题可能是因为同时启动的并行进程过多造成的，特别常见于RAC节点重启，很多时候是因为瞬间启动了几百个并行进程，导致OS各项指标“彪高”，后台进程失去响应。近遇到的一个，是因为SQL语句中写了/*+ parallel a，8*/  ，但是在RAC的两个节点上各使用了256个并行进程，一共启动了512个并行进程，导致网络心跳丢失。因为问题可以通过执行这个语句重现，而使用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
　　------------------------------ ------------------------------ ----------
　　3)auto DOP
　　单节点：DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT
　　RAC：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）如果以上并行度>parallel_max_servers，则终并行度=0，也是不并行（不使用Pnnn的进程）。
　　3）RAC中，并行度会自动平均分配到各个节点上，比如并行度256，2个节点，则每个节点上各起128个并行进程。
　　“并行度>parallel_max_servers”的判断在各个节点上进行。
　　举一下一些例子来更详细的说明它：
　　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。