从最终权威那儿获得关于 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 所示的页面。
(本文来源于图老师网站,更多请访问http://m.tulaoshi.com)在此您可以看到引发该问题的特定 SQL 语句。ADDM 建议您用 SQL Tuning Advisor 对该 SQL 语句进行彻底的分析,正如在 "Action" 部分中所提到