限制可用于任何查询的并行度（DOP）

在Oracle Exadata（11gR2）上，我们有一个相对强大的数据库。

• cpu_count是24
• parallel_server_instances是2
• parallel_threads_per_cpu为2

我们注意到，通过在Oracle企业管理器（OEM）中进行的观察，由于查询是按顺序执行的，因此性能很差。为了解决这个问题，所有表，实例化视图和索引都进行了更改，以利用并行性。例如：

ALTER TABLE SOME_TABLE PARALLEL (DEGREE DEFAULT INSTANCES DEFAULT);

更改了系统以打开并行化：

ALTER SYSTEM SET PARALLEL_DEGREE_POLICY = 'AUTO';

这样可以提高性能，但是我们有时在OEM中观察到，单个查询将占用DOP 96（所有可用资源）。这导致随后的查询降级为DOP 1（无并行化）。导致性能下降，直到搜索查询完成。

为了解决这个问题，我们尝试通过以下方式限制可用于任何查询的DOP：

ALTER SYSTEM SET PARALLEL_DEGREE_LIMIT = 24;

这没有效果。我们经常观察到将使用超出限制的查询（通常为48或96，但没有实际模式）。

我们如何防止任何单个查询占用所有可用资源？

并行服务器集： PARALLEL_DEGREE_LIMIT限制了并行度，但是如果您的查询是排序或分组，则并行进程的数量可能是并行进程的两倍（两个服务器集可启用进程间并行性）。这就解释了为什么即使限制为24，也会看到48个并行进程。如果使用资源管理器限制DOP，也会发生这种情况。

并行提示： PARALLEL_DEGREE_LIMIT仅适用于使用自动并行度的语句。任何使用硬编码程度甚至任何类型的对象级并行提示的语句都将忽略该限制。如果有这些提示，则可以解释为什么有时会看到96。

校准IO： 也许未使用自动DOP，因此未遵循限制，因为未校准 IO 。此查询将告诉您IO是否已校准：

select * from V$IO_CALIBRATION_STATUS;

我以前曾见过这会引起问题，但是我当前的系统尚未校准，并且自动DOP似乎可以正常工作。您可以通过查看解释计划的“注释”部分来判断这是否确实是一个问题。如果您看到类似的东西- automatic DOP: Computed Degree of Parallelism is 2就可以了，但是您不想看到automatic DOP: skipped because of IO calibrate statistics are missing。

增加PARALLEL_MAX_SERVERS： 建议不要显着增加PARALLEL_MAX_SERVERS，而不用担心并行服务器会用完。您至少应尝试返回默认值 PARALLEL_THREADS_PER_CPU x CPU_COUNT x parallel_parallel_users x 5，介于240和960之间，具体取决于您的内存设置。

如此高的数目对于许多DBA来说都是荒谬的，但是出于以下原因，它们实际上具有很大的意义：

• Oracle并行服务器的重量比大多数人想象的要轻。（而且几乎没有人进行过测试，他们只是发现一种情况，其中大DOP会引起问题，并认为高DOP总是不好的。）
• 通常在GUI工具中运行临时查询，该工具仅检索前50行，但仍使用数十个并行服务器。除非PARALLEL_MAX_SERVERS太低，否则这些查询不会消耗任何重要资源。然后人们会因为运行完全合理的查询而大吼大叫，这可能会导致某些丑陋的情况。
• 对于单个查询而言，非常大的DOP并不总是不好的。每个人都认为，如果您继续增加DOP，开销将变得过高并且性能将大大下降。但是在很多系统上，我发现即使DOP很高得可笑，也会带来更好的性能，尽管收益肯定会减少，这对于其他会议来说可能是非常不公平的。但是不要只是猜测，要对其进行测试；进行查询并使用各种DOP（最多1000个）运行它。您可能会感到惊讶。
• 是的，太多的并行性可能是不好的。但是，对于系统而言，比最佳会话数稍多的会话，或者迫使查询进行串行操作并基本上杀死了重要的工作，又有什么不好的呢？在引入任意限制之前，您应该监视系统。