接上文：如何优化并行SQL性能（上）

　　确保执行计划的所有部分都被并行化了

　　在复杂的并行SQL语句中，很重要的一点是要确保该查询执行的所有重要步骤都实现了并行。如果某复杂查询的其中一个步骤是串行执行的，其他并行步骤可能也不得不等待该串行步骤完成，这样并行机制的优势就完全丧失了。“PLAN_TABLE”表中的“OTHER_TAG”列用“PARALLEL_FROM_SERIAL”标记指定了这样一个步骤，“DBMS_XPLAN”在“IN-OUT”列中记录了“S->P”。

　　例如：在下面的例子中表“CUSTOMERS ”是并行化的，但是表“SALES ”不是。对两个表的连接和“GROUP BY”包括许多并行操作，但是对“SALES ”表的全表扫描不是并行化的，而且登记机(tell-tale)串到并(S->P)标记展示了“SALES”行被串行提取到后续并行操作中：

　　像前面这种情况，部分并行化执行计划可能会导致两方面效果都很差：消耗的时间并没有改善，因为串行操作形成了整个执行的瓶颈。然而，该SQL还捆绑了并行服务器进程，而且可能影响其他并发执行SQL的性能。

　　如果我们为表“SALES”设置一个默认的并行度，该串行瓶颈就消失了。对“SALES ”表的全扫描现在是按并行执行了，而且“串到并S->P”瓶颈被全并行的“并到并P->P”操作替代了：

　　在优化并行执行计划时，要确保所有相关步骤都在并行执行：“DBMS_XPLAN”中的串到并S->P 标记或者“PLAN_TABLE”中的“PARALLEL_FROM_SERIAL”通常指示在并行计划的某些方面存在串行瓶颈。

　　确保请求的DOP是可实现的

　　超过调优限度增加DOP可能给系统增加额外负载，而不会提升性能。在最坏的情况下，超过调优限度增加DOP可以导致查询运行时间减少。因此，设置合适的DOP对于数据库整体的健康和并行查询的性能优化都是非常重要的。

　　确保你请求或预期的DOP是现实的;过高的DOP可以导致数据库服务器负载过度，而不会提升SQL的性能。

　　监视实际DOP

　　你请求的DOP可能被优化，但是并不总是能成功。当多个并行查询竞争有限的并行执行资源时，DOP可能会减少，或者SQL语句可能会以串行模式运行。

　　我们前面讨论了Oracle如何决定实际DOP;最重要的参数“PARALLEL_MIN_PERCENT”，“PARALLEL_DEGREE_ POLICY”和“PARALLEL_ADAPTIVE_MULTI_USER”控制了Oracle改变DOP的方式，不管语句运行在降低并行，出错终止，还是在现存资源不足以请求的DOP运行该语句时推迟到后续处理。

　　DOP的减少可以导致你的并行SQL表现出令人失望的性能。你应该监视查询执行来看是否DOP的减少确实出现了。我们前面看到了我们可以如何使用“V$PQ_TQSTAT”来度量实际DOP，以及我们可以如何利用“V$SYSTAT”统计来度量整体并行降级。

　　如果你发现降级的并行导致了令人失望的性能，你可能想重新审查你的系统资源(内存，IO带宽)，调度并行SQL，或者重新检查服务器配置。可能的选择包括：

• 　　重新调度SQL，以便它们不要并发运行。Oracle 11g R2可以自动调度SQL，只要你设置“PARALLEL_ DEGREE_POLICY”参数为“AUTO”。
• 　　调整并行配置参数，以支持更大的并发并行。你可以通过增加“PARALLEL_THREADS_PER_ CPU”或者“PARALLEL_MAX_SERVERS”的值来做到这一点。这里的风险是并行执行的总量将会比你系统能支持的数量要多，这会导致SQL 性能退化。
• 　　增加你数据库服务器的性能。你可以增加CPU数量，RAC集群中实例的数量，你磁盘阵列中磁盘的数量。
• 　　调整“PARALLEL_MIN_PERCENT ”参数，使SQL可以运行在较少的并行状态下，而不是报错。

　　令人失望的并行性能可能是Oracle由于并发负载或者并行执行资源的限制降低了DOP导致的结果。