在 alter system flush shared_pool 性能低下 Oracle答案

【问题标题】：after alter system flush shared_pool low performance Oracle在 alter system flush shared_pool 性能低下 Oracle
【发布时间】：2014-10-24 21:51:56
【问题描述】：

我们进行了重构，并用参数化请求替换了 2 个类似的请求

a.isGood = :1

在使用此参数和参数“Y”的请求之后执行的时间比通常更长（与参数“N”几乎相同）。我们使用了 alter system flush shared_pool 命令，对参数 'Y' 的请求已快速完成（与重构之前一样），而参数为 'N' 的请求挂起很长时间。

正如您可以理解的那样，使用参数“N”的数据库中的行数比使用“Y”要多得多

甲骨文 10g

为什么会这样？

【问题讨论】：

您是否在会话和 tkprof 上运行了 Oracle 跟踪？没有经验数据，这里没有人可以推测。

标签： oracle performance system flush alter

【解决方案1】：

我假设您在该列上有一个索引，否则无论 Y/N 组合如何，性能都是相同的。由于 Oracle 的优化器 Bind Peeking 结合到具有倾斜数据分布的列上的 直方图，我已经在 10g+ 上看到了这种情况。当使用参数 method_opt 和“FOR ALL COLUMNS SIZE AUTO”（以及其他值）收集表统计信息时，会自动创建直方图。 Oracle 针对在该查询的第一次执行时提供的绑定变量中的值优化查询。如果您第一次使用 Y 运行查询，Oracle 可能希望使用索引而不是全表扫描，因为 Y 将返回少量行。下次您使用 N 运行查询时，Oracle 将重复第一个执行计划，这恰好是 N 的糟糕选择，因为它将返回绝大多数行。

执行计划缓存在 SGA 中。刷新后，您会在查询再次运行时获得全新的执行计划。

我的建议是：

获取两个原始查询的解释计划（一个带有硬编码 Y，一个带有硬编码 N）。调查这两个计划是否使用不同的索引，或者一个的成本比另一个高得多。我感觉一个使用全表扫描，另一个使用索引。 N 的第一个应该更快，Y 的第二个应该更快。
尝试删除表上的统计信息，看看它是否会对具有绑定变量的查询产生影响。稍后您需要再次收集该表的统计信息，否则该表上的其他查询可能会受到影响。
- 您还可以使用 method_opt => FOR ALL COLUMNS SIZE 1 收集该表的统计信息。这将保留该表的任何列上的统计信息而不包含直方图。
此列上的位图索引也可以解决此问题。只有两个可能值（Y 和 N）的列上的索引并不是非常有效。

【讨论】：

【解决方案2】：

如果列 isGood 有 99,000 个“N”值和 1,000 个“Y”值，并且您使用条件 isGood = 'Y' 运行，那么使用索引查找结果可能是合适的：您返回 1%行。如果您使用条件isGood = 'N' 运行查询，则全表扫描会更合适，因为无论如何您都会返回大部分表。如果您要为 N 条件使用索引，您将为每个数据项查找执行额外的索引查找。

虽然一般规则是绑定参数是好的，但如果查询确实需要两个不同的计划，则在这种情况下可能会出现问题。带绑定参数场景：

SELECT * FROM x WHERE isGood = :1

将解析语句并计算计划并将其保存在 sql 缓存中。相同的计划将用于两个查询场景，这是不可取的。但是：

SELECT * FROM x WHERE isGood = 'Y'
SELECT * FROM x WHERE isGood = 'N'

将导致两个计划被存储在 sql 缓存中，希望每个计划都有相应的查询计划。 11g 版本使用 adaptive cursor sharing 避免了这个问题，它可以为不同的绑定变量值使用不同的计划。

您需要查看您的计划 (EXPLAIN PLAN) 以了解您的情况正在发生什么。刷新缓存，尝试一种方法，检查计划；尝试另一个，检查计划。它可能会让您了解您的情况发生了什么。您可能会跟进许多其他主题可能会有所帮助，例如：

使用提示强制使用索引
cursor_sharing 参数
统计直方图

【讨论】：