限制任何查询可用的并行度 (DOP)

Question

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

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

我们注意到，通过在 Oracle Enterprise Manager (OEM) 中的观察，由于查询是串行执行的，性能很差。为了解决这个问题，所有表、物化视图和索引都进行了更改以利用并行性。例如：

ALTER TABLE SOME_TABLE PARALLEL (DEGREE DEFAULT INSTANCES DEFAULT);

系统已更改为打开并行化：

ALTER SYSTEM SET PARALLEL_DEGREE_POLICY = 'AUTO';

这导致了更好的性能，但我们偶尔会在 OEM 中观察到单个查询会占用 96（所有可用资源）的 DOP。这导致后续查询被降级为 DOP 1（无并行化）。导致性能不佳，直到占用查询完成。

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

ALTER SYSTEM SET PARALLEL_DEGREE_LIMIT = 24;

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

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

Answer 1

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

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

Calibrate 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 concurrent_parallel_users x 5，在 240 到 960 之间，具体取决于您的内存设置。

对于许多 DBA 来说，这些高数字听起来很荒谬，但由于以下原因，它们实际上很有意义：

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