Oracle的自动数据库诊断监控程序剖析

【 tulaoshi.com - Oracle教程 】

从最终权威那儿获得关于 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 的页面。

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

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

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

在此您可以看到引发该问题的特定 SQL 语句。ADDM 建议您用 SQL Tuning Advisor 对该 SQL 语句进行彻底的分析，正如在 "Action" 部分中所提到