Oracle 11g新特性：SQL Performance Analyzer(1)(3)
这个屏幕显示了有关执行该 SQL 的大量统计信息。 屏幕底部显示了执行计划的比较：
现在您可以看到，使用索引是如何强制减少缓冲区的。但是，情况总是那么乐观吗？看看另一条 SQL：
与上一例的 31.95% 相比，此例改进甚微，只有 0.48%.原因是什么？为了找到答案，单击 SQL ID，出现如下屏幕：
在这里，您可以看到究竟是什么改变了。所用时间实际上从 0.504 秒延长为 1.022 秒，而且都是因为 CPU 时间。为什么？如果您检查一下数据分布模式，您就会看到 promo_id 是这样分布的：
SQL> select promo_id, count(1) cnt from sales group by promo_id; PROMO_ID CNT |
promo_id 999 在表中出现了 887，837 次，将近 97%.当将计划改为包含索引扫描时，这个查询就比较困难了。如果对全表进行扫描，情况应该会好一些。因此，即使整体影响是积极的，也会有个别组件拖后腿。当您决定是否要更改参数时，您应该考虑到这些 SQL 语句的重要性，这些语句既可能改进也可能退化。
正如您所见，您希望评估对数据库参数进行重要更改而带来的影响。使用 SPA，您不必估计潜在的性能影响，连“猜测估计”也不必。您可以使用应用程序针对数据库执行的 SQL 语句客观地衡量。
现在看另一个案例：更改参数后，性能退化了，而不是改进了。下面是一个屏幕截图：
这里，SQL 语句的运行情况都比更改之前要差。您可以利用（本文中讨论的）SQL 计划管理解决这个问题。SPM 允许您选择优良的执行计划作为您的基准，从而保证执行计划的稳定性。随后，优化程序会将这个基准用于相应 SQL 的所有执行过程。这个基准计划会一直使用，直到被禁用或者您创建了新的基准计划。另一个解决 SQL 退化问题的方法是使用 SQL Tuning Advisor，它能提出 SQL 调整建议或建议进行外部修改，如通过创建索引提高性能。
应用案例
SPA 在很多情形中都是极有用的，包括数据库版本升级、部署数据库补丁集、数据库参数更改和优化程序参数更改等等。
例如，当您决定是否要提高优化程序参数时，比如从 10.2 更改为 11.1，您肯定想了解这个更改会对您的 SQL 语句产生怎样的影响。执行该任务最好的工具就是 SPA.唯一不同的是，在上面的步骤 5 中，不是选择 Database Parameter Changes，而是选择 Optimizer Changes，将出现如下所示屏幕。
在此屏幕中，选择合适的源优化程序版本和目标优化程序版本，然后完成剩余的步骤。
结论
使用这个新工具的最佳时间是什么时候？简单的回答就是：在您进行任何更改的时候。与数据库重放不同，在数据库重放中您看不到实际的 SQL，而使用 SPA，您能够得到特定 SQL 或整个应用程序 SQL 负载的结果。您可以评估正反两方面的影响，并达到最佳的可能更改状态而并不危害您的应用程序的性能。没有哪种选择是永远绝对正确或错误的，是对与错的程度使人们难于进行决策。SPA 将对错程度推向某一个极端，从而使您更容易作出决策。
