查询成本与执行速度+并行度

Question

我们的IT部门最近受到我们IT部门的谴责（运行良好），因为我们的查询具有破坏数据库稳定性和/或崩溃的实际可能性，因此运行查询的成本非常高。我们都不是DBA的;只是研究人员对数据库编写和执行查询，我可能是唯一一个在谴责之前查看解释计划的人。

我们被告知，超过100的查询成本应该非常少见，并且不应该运行超过1000的成本查询。我遇到的问题是成本似乎与执行时间没有关系，而且我在优化查询时失去了生产力。

作为一个例子，我有一个查询在5秒钟内执行，费用为10844.我重写了查询以使用包含我需要的大部分信息的视图，并将成本降至109，但检索相同结果的新查询需要40秒才能运行。我发现了一个问题，在这里与一个可能的解释：

Measuring Query Performance : "Execution Plan Query Cost" vs "Time Taken"

这个问题使我并行提示。我在成本10884查询中尝试使用/*+ no_parallel*/，但成本没有变化，执行时间也没有变化，所以我不确定并行性是更快执行时间还是更高成本的解释。然后，我尝试使用/*+ parallel(n)*/提示，并发现n的值越高，查询的成本就越低。在成本10844查询的情况下，我发现/*+ parallel(140)*/将成本降至97，执行时间仅略有增加。

这似乎是一个理想的“欺骗”，以满足我们的IT部门提出的要求，但后来我读了这一点：

http://www.oracle.com/technetwork/articles/datawarehouse/twp-parallel-execution-fundamentals-133639.pdf

本文包含了这样一句话：

并行执行可以使单个操作能够利用所有系统资源。

所以，我的问题是：

我是否实际使用/*+ parallel(n)*/暗示具有非常高的并行度将服务器上的资源较为紧张，即使我降低了成本？

假设没有并行性，执行速度是比成本更好的资源使用衡量标准吗？

Answer 1

你的DBA给你的规则没有多大意义。担心为查询报告的成本很少有成效。首先，您不能直接比较两个不同查询的成本 - 一个成本高达数百万的查询可能运行速度非常快，并且消耗的系统资源非常少，另一个成本高达数百的查询可能会运行数小时，并将服务器屈膝。其次，成本是一个估计。如果优化器对成本进行了准确估计，这强烈暗示它已经提出了最佳查询计划，这意味着您不太可能在使用较少资源时修改查询以返回相同结果。如果优化器对成本进行了不准确的估计，这强烈暗示它提出了一个糟糕的查询计划，在这种情况下，报告的成本与您想出的任何有用的指标都没有关系。大多数情况下，您试图优化的查询是优化程序生成不正确查询计划的查询，因为它错误地估计了各个步骤的成本。

通过使用可能或不可能实际更改查询计划的提示来欺骗优化器（例如，取决于如何配置并行性）不太可能解决问题 - 这更有可能导致优化器的估计不太准确，并且更有可能选择的查询计划消耗的资源远远超过需求。例如，具有高度并行性的parallel提示将告诉Oracle大幅降低全表扫描的成本，这使得优化器可能会选择通过索引扫描进行选择。这很少是你的数据库管理员希望看到的东西。

如果你正在寻找的，告诉你一个查询计划是否合理单一指标，我会用逻辑I/O量。逻辑I/O与实际查询性能以及查询消耗的资源量相关性很好。查看执行时间可能会有问题，因为它根据什么数据发生缓存而变化很大（这就是为什么查询在第二次执行时运行得更快），而逻辑I/O不会根据什么数据在缓存中。它还可以让您根据查询处理更改所需的行数扩展您的期望。例如，如果您正在编写一个需要汇总100万行数据的查询，则该查询所消耗的资源要远远多于需要从表中返回100行数据而不汇聚的查询。如果您正在查看逻辑I/O，您可以轻松地将您的期望扩展到问题的大小，以确定查询的实际效率。

在基督教安托尼尼的“Troubleshooting Oracle Performance”（页450），例如，他给了大拇指，这是非常合理的

• 5逻辑的规则，每时返回/聚合读取一行可能是非常好的
• 10逻辑每时返回/聚集行读取是可能足够
• 20+逻辑每行被返回/聚集可能是低效的，并且需要被调谐

读取

具有不同数据模型的不同系统可能需要稍微调整桶，但这些可能是很好的起点。

我的猜测是，如果你是研究人员不属于开发商，你可能运行需要聚合或获取比较大的数据集，至少相较于那些应用程序开发人员通常编写查询。如果您正在扫描一百万行数据以生成一些聚合结果，那么与查询读取或写入少量行的应用程序开发人员相比，您的查询自然会消耗更多的资源。您可能正在编写从每行逻辑I/O角度看同样有效的查询，您可能正在查看更多行。

如果您正在运行针对现场制作数据库查询，你很可能是在它有道理，开始分离工作负载的情况。大多数组织都达到了针对实时数据库运行报表查询开始为生产系统创建问题的程度。解决这类问题的一个常见解决方案是创建一个单独的报告数据库，该数据库从生产系统提供（通过夜间快照或正在进行的复制过程），报告查询可以在不影响生产应用程序的情况下运行。另一个常见的解决方案是使用诸如Oracle资源管理器之类的东西来限制一组用户（在这种情况下是报表开发人员）可用的资源量，以便将对较高优先级用户（在这种情况下为生产用户系统）。