oracle 10g:ADDM 和 SQL Tuning Advisor

ADDM 和 SQL Tuning Advisor(转自oracle: OraOracle ACE Arup Nandacle)

从最终权威那儿获得关于 SQL 调整的帮助：该权威就是 Oracle 数据库本身！使用 SQL 配置文件进行查询，并了解如何使用 ADDM 来快速、轻松解决常见的性能问题。

迄今为止这是平静的一天：在数据库中没有重大问题发生，不需要去灭“火”。您几乎可以放松一下了；接下来正好可以抓紧处理那些重要任务了，如对 RMAN 调整参数或多个块大小进行调整等。

突然，一位开发人员出现在您面前。他的 SQL 查询要运行很长一段时间。他问您是否能尽快调整该查询使其能够“工作”。

也许您放松得太早了。您最初的日程安排是花些时间制定战略决策，以使您的数据库运行得更好、更快、更安全。例如，确保数据库是可恢复的，增强底层技术或研究安全性更新等等。相反，您将又花一天的时间集中处理 SQL 等战术活动，而很少或没有时间来考虑战略问题。

作为一名战略 DBA，您想把自己从日常琐事中解脱出来，更多地关注那些引人深思的领域。让一名助理 DBA 帮助您做那些琐事难道不好吗？

有了 Oracle 数据库 10g，您就有了一位自动数据库诊断监控程序 (ADDM) 形式的助理 DBA，这种机器人式的 DBA 会不知疲倦地反复搜索数据库性能统计，以标识瓶颈、分析 SQL 语句、并据此提供多种改进性能的建议，它通常与其他“顾问”（如 SQL Tuning Advisor）一起使用。在这篇文章中，对该过程的工作方式进行了概述。

自动数据库诊断监控程序 (ADDM)

在第 6 周，您了解到被称作快照的自动负载信息库 (AWR)，它定期从数据库中收集详细的与性能相关的度量标准。每次快照后，调用 ADDM 来彻底分析源自快照间差异的数据和度量标准，然后就必要的操作提出建议。正如我早先所提及的，发现问题后，ADDM 可能会依次调用其他顾问（如 SQL Tuning Advisor），来提出改进建议。

我将为您完全展示（而不是用文字来解释）这种特性是如何运行的。假定您正设法诊断一个不可解释的性能问题。在我们介绍的示例中，您知道了哪些 SQL 语句需要调整，或至少知道了哪些 SQL 语句存在问题。但是在现实生活中，您可能没有这些有用信息。

要在 10g中执行诊断，您将在相关的时间间隔内选择快照进行深入、透彻的分析。在 Enterprise Manager 10g中，从 Database 主页上，您将选择 "Advisor Central"，然后单击 "ADDM" 链接，它将出现一个类似于图 1 的页面。

图 1：创建 ADDM 任务

在该页中，您可以创建 ADDM 要分析的任务。您知道性能问题发生在晚上 11 点左右，因此选择那个时间间隔的快照，通过 "Period Start" 和 "Period End" 值进行指示。您也可以单击照相机图标，指示开始和终止快照的时间间隔，如此处的红色椭圆形所示。选择时间间隔后，按下 "OK" 按钮，将出现一个类似于图 2 所示的页面。

图 2：ADDM 查找结果

这里 ADDM 在该时间间隔内标识了两个关键的、相关的性能问题：某些 SQL 语句消耗着重要的 CPU 时间，从而使数据库的速度显著减慢。基于这些查找结果，ADDM 建议对图中突出显示的那些语句进行 SQL 调整。

如果您单击某条查找结果，ADDM 会显示更多详细信息。例如，单击问题查找结果，将会出现一个类似于图 3 所示的页面。

图 3：ADDM 查找结果的详细信息

在此您可以看到引发该问题的特定 SQL 语句。ADDM 建议您用 SQL Tuning Advisor 对该 SQL 语句进行彻底的分析，正如在 "Action" 部分中所提到的那样。您可以通过单击它旁边的按钮立即运行该任务，这将调用 SQL Tuning Advisor。

在图 2 中，您可能注意到了一个名称为 "View Report" 的按钮。除了在单独的 Web 页面中提供建议外，ADDM 还能够创建纯文本报表，以进行更快速的一步到位的分析。列表 1显示了在我们的示例纯文本报表中提出的全面建议。注意报表是如何给出相关细节的，如所考虑的 SQL 语句、它的散列值等。可以在 Enterprise Manager 的 SQL Tuning Advisor 页中或通过命令行将 SQL ID 用于独立的分析。

在收集了每一张 AWR 快照后就会调用 ADDM，因此可以查看基于相邻快照的建议。因此，如果分析的范围只是两张相邻的快照，就不必创建上面所示的 ADDM 任务。如果您想在两张不相邻的快照之间进行分析，就需要创建 ADDM 任务。

记住 ADDM 所能做的远不止这些；正如您在以前的文章中所看到的，它还提供内存管理、段管理、重作/撤消以及更多的分析和建议。由于在一篇简短的文章中描述所有的 ADDM 功能是不可能的，在此我们只关注 SQL Tuning Advisor。现在让我们看看它是如何工作的。

用 SQL Tuning Advisor 访问分析

在一个典型的运行时优化中，优化器生成一组可能的访问路径，并基于对象统计从中选择出最“经济”的路径。但是，那时它没有时间考虑是否能够调整语句、统计是否陈旧、是否能够创建索引等问题。相反，SQL Tuning Advisor 可以执行这种“专家系统”类型的思考。实质上，优化器能够回答的问题是：“基于可用的资源,获得结果的最佳方式是什么？”而 SQL Tuning Advisor 能够回答的问题是：“基于用户的需求，还需要做些什么来增强性能？”

正如您可能预期的那样，这种“思考”消耗了资源（如 CPU）；因此 SQL Tuning Advisor 在调整模式期间处理 SQL 语句，该模式可以在非高峰时间运行。在创建调整任务时，通过在函数中设置SCOPE和TIME参数来指示这种模式。在数据库活动少的期间运行调整模式是一个好方法，以使常规用户相对不受影响，稍后再进行分析。

这个概念可以通过示例很好地解释。就看看如下所示的开发人员引起您注意的那个查询事例吧。

select account_no from accounts where old_account_no = 11

该语句调整起来并不难，但是为了更容易说明问题，假定它很难调整。激发顾问的方式有两种：使用 Enterprise Manager 或简单明了的命令行。

首先，让我们看看如何在命令行中使用它。我们通过调用提供的包dbms_sqltune来调用顾问。

declare
l_task_id     varchar2(20);
l_sql         varchar2(2000);
begin
l_sql := 'select account_no from accounts where old_account_no = 11';
dbms_sqltune.drop_tuning_task ('FOLIO_COUNT');
l_task_id := dbms_sqltune.create_tuning_task (
sql_text  => l_sql,
user_name  => 'ARUP',
scope      => 'COMPREHENSIVE',
time_limit => 120,
task_name  => 'FOLIO_COUNT'
   );
dbms_sqltune.execute_tuning_task ('FOLIO_COUNT');
end;
/

这个包创建并执行了一个名为FOLIO_COUNT的调整任务。接下来，您将需要查看任务执行的结果（也就是说，查看建议）。

set serveroutput on size 999999
set long 999999
select dbms_sqltune.report_tuning_task ('FOLIO_COUNT') from dual;

列表 2显示的是输出结果。仔细查看这些建议；顾问说您可以通过在 OLD_ACCOUNT_NO 列上创建一个索引来改进性能。更佳的是，如果创建索引，顾问计算了查询成本，从而使潜在的节省量变得更加可定义、更加具体。

当然，考虑到本示例的简单性，通过手动检查也能得到这种结论。但是，可以想象出该工具对于那些更复杂的查询十分有用，因为对这些查询执行手动检查也许是不可能的或不实际的。

中级调整：查询重构

假定查询更复杂：

select account_no from accounts a 
where account_name = 'HARRY' 
and sub_account_name not in 
( select account_name from accounts 
where account_no = a.old_account_no and status is not null);

顾问建议如下：

1- Restructure SQL finding (see plan 1 in explain plans section)
----------------------------------------------------------------
The optimizer could not unnest the subquery at line ID 1 of the execution
plan.
Recommendation
  --------------
Consider replacing "NOT IN" with "NOT EXISTS" or ensure that columns used
on both sides of the "NOT IN" operator are declared "NOT NULL" by adding
either "NOT NULL" constraints or "IS NOT NULL" predicates.
Rationale
  ---------
A "FILTER" operation can be very expensive because it evaluates the
subquery for each row in the parent query.The subquery, when unnested can
drastically improve the execution time because the "FILTER" operation is
converted into a join.Be aware that "NOT IN" and "NOT EXISTS" might
produce different results for "NULL" values.

这一次顾问不会建议任何结构上的更改（如索引），但会通过用NOT EXISTS取代NOT IN的方式很聪明地猜测到调整查询的正确方式。由于两种构造相似但不相同，顾问给出了这种改变的基本原理，并把决定权留给 DBA 或应用程序开发人员，由他们决定该建议是否对环境有效。

高级调整：SQL 配置文件

正如您可能知道的，优化器通过检查查询中引用的对象统计，来对查询执行计划作出决定，然后计算成本最低的方法。如果查询涉及到一张表以上这种典型情况，优化器就会通过检查所有引用对象的统计来计算成本最低的选项 ― 但是它并不知道对象间的关系。

例如，假定一个DELINQUENT状态的帐户拥有不到 1000 美元的余额。如果谓词带有一个只筛选DELINQUENT的子句，那么连接 ACCOUNTS 表和 BALANCES 表的查询的报告行将较少。优化器不知道这种复杂关系 ― 但是顾问知道；它从数据中“组合”了这种关系，并将其以 SQL 配置文件的形式存储起来。通过访问该 SQL 配置文件，优化器不但知道了表的数据分布，而且知道了这些表之间的数据相关系。这个附加信息可以让优化器生成一个高级执行计划，从而获得一个优良的查询。

SQL 配置文件通过手动将查询提示添加到代码中，而无需调整 SQL 语句。因此，SQL Tuning Advisor 使无需修改代码即可调整打包的应用程序成为可能且极具优势。

要点在于，与对象统计不同的是，SQL 配置文件映射到一个查询，而不是映射到一个或多个对象。涉及到同样两个表（ACCOUNTS 和 BALANCES）的另一个查询可能具有不同的配置文件。使用查询中的这种元数据信息，Oracle 就能够改进性能。

如果能够创建一个配置文件，它是在 SQL Tuning Advisor 会话期间完成的，该顾问将在会话中生成配置文件并建议您“接受”。除非接受了配置文件，否则它不会被捆绑到语句上。您可以通过发出如下语句随时接受配置文件：

begin
dbms_sqltune.accept_sql_profile (
task_name   => 'FOLIO_COUNT',
name        => 'FOLIO_COUNT_PROFILE'
descrīption => 'Folio Count Profile',
category    => 'FOLIO_COUNT');
end;

该命令将把顾问先前生成的名为FOLIO_COUNT_PROFILE的配置文件捆绑到一条语句上，该语句与前面示例中描述过的名为FOLIO_COUNT的调整任务相关联。（注意：尽管 SQL 配置文件只能由顾问而不能由 DBA 创建，但只有您能决定何时使用它。）

您可以在字典视图DBA_SQL_PROFILES中查看创建的 SQL 配置文件。SQL_TEXT 列显示分配给配置文件的 SQL 语句；STATUS 列指示是否启用给该配置文件。（即使它已经捆绑到一条语句上，也必须启用配置文件来影响执行计划。）可以从视图DBMSHSXP_SQL_PROFILE_ATTR查看配置文件的元数据信息，在该视图中，ATTR_VALUE 列显示了优化器用以确定计划的多种专有信息。

使用 ADDM 和 SQL Tuning Advisor

除了上面描述的三种情形外，SQL Tuning Advisor 还会标识出查询中引用的丢失统计的任何对象。因此，顾问执行四种独特类型的任务：

• 检查对象是否具有有效的、可用的统计，以进行适当优化
• 试图重新编写性能更好的查询并就重新编写提出建议
• 检查访问路径，查看是否能够通过添加额外的结构（如索引和物化视图）来改进性能。
• 创建 SQL 配置文件，并将它们附加到特定的查询上。

基于这些功能，我可以想到至少三种不同情况，将 ADDM 和 SQL Tuning Advisor 作为功能强大的工具来使用。

• 反应式调整：您的应用程序突然运行得很糟糕。使用 ADDM，您可以把问题深入剖析到一条 SQL 语句或一组语句的层面上，如 ADDM 一节所示。根据 ADDM 的建议，您可以启动 SQL Tuning Advisor 并矫正问题。
• 积极式调整：应用程序的运行情况尚好；但是，您希望确保执行了所有必要的维护任务，并知道是否可以对查询进行进一步调整。您将在独立模式下激发 SQL Tuning Advisor，以标识出可能的调整选择。
• 开发式调整：在开发过程中对代码进行测试时，相对于 QA 阶段或生产阶段，有许多机会可调整查询。在开发最后确定 SQL 语句前，可以使用顾问的命令行版本对这些语句进行单独测试。

使用 Enterprise Manager

前一个示例被有意用来说明如何在命令行模式下使用 SQL Tuning Advisor，该模式对积极编写这些任务的脚本非常有用。但是，在大多数情况下，您需要依据终端用户所报告的问题执行调整。Enterprise Manager 10g在这些情况下就可以大显身手了。

几个星期以前（第 13 周），向您介绍了更新过的 Enterprise Manager 界面。这里将介绍您将如何用它来诊断和调整 SQL：从 Database 主页单击屏幕底部的 "Advisor Central" 链接，这将启动一个包含所有顾问的页面。接下来，单击屏幕顶部的 "SQL Tuning Advisor"，如图 4 所示。

图 4：Enterprise Manager 中的 Advisor Central

您刚才启动了 SQL Tuning Advisor。从下一页选择 "Top SQL"，如图 5 所示。

图 5：SQL Tuning Advisors

该操作启动了一个类似于图 6 所示的页面，其中有一个包含多种等待级别的沿时间维进行跟踪的图表。

图 6：顶部的 SQL 选择器

红色椭圆内的灰色矩形区域把焦点置于该图表上。用鼠标拖动该矩形，将其重新定位到 CPU 等待级别为高的位置上（如图中所示）。该页面的下面部分将显示那个时间间隔内相关的 SQL 语句，如图 7 所示。

图 7：选择基于活动性的 SQL 语句

正如您可以看到的，显示在顶部（被红色椭圆形所包围）的 SQL 语句活动性最高，其 CPU 消耗也最大。单击语句 ID 查看该语句的详细信息，这将引出一个如图 8 所示的屏幕。

图 8：SQL 详细信息

在该图中，您可以看到在那个时间段引发 CPU 消耗的确切的 SQL 语句。您可以单击 "Run SQL Tuning Advisor" 按钮（在图中作了标记）运行顾问。这将引出一个类似于图 9 所示的屏幕。

图 9：调度 SQL Tuning Advisor

在顾问调度程序中，您可以确定任务的类型，以及将要做多少分析工作。例如，在上图中，我选择了“全面”分析和顾问将会立即运行。在顾问结束运行后，您可以查看其建议，如图 10 所示。

图 10：顾问建议

我刚才描述的这个过程类似于您在命令行版本中所看到的过程；但是这个流程更反映了真实情况，在那种情况下，您对一个问题作出反应，深入剖析其原因，并接受关于如何修复它的建议。

结论

ADDM 是一个功能强大的“智能”工具，它能够自动根据最佳实践和经验丰富的 Oracel 专业人员公认的方法，来分析性能度量标准和提供建议。这种功能不但能告诉 DBA 发生了什么以及为什么发生，而且最为重要的是，它还指明了下一步怎么做。