oracle导入监视功能,Oracle 自动数据库诊断监控（ADDM）的引入

有了这个AWR这个“数据仓库”之后，Oracle自然可以在此基础之上实现更高级别的智能应用，更大程度地发挥AWR的作用，这就是Oracle 10g引入的另外一个功能：自动数据库诊断监控程序(Automatic Database Diagnostic Monitor，ADDM)。

通过ADDM，Oracle试图使数据库的维护、管理和优化工作变得更加自动和简单。

ADDM概述

ADDM可以定期检查数据库的状态，根据内建的专家系统，自动确定潜在的数据库性能瓶颈，并提供调整措施和建议。由于这一切都是内建在Oracle数据库系统之内的，其执行效率很高，几乎不影响数据库的总体性能。

ADDM经常被描述为一个内建在Oracle数据库内部的自我诊断引擎，和现实中的医学诊断过程非常相似。对于一个运行的数据库系统，在诊断时ADDM首先分析整个系统，然后给出诊断概要，接着ADDM或者会直接建议调整或者推荐你进一步向其他科目的专家“问诊”，例如Oracle 10g提供的其他专家系统，如SQL Tuning Advisor等。

ADDM可以通过不断下钻识别问题的根源所在，报告特定问题对于系统的影响，在很多情况下，ADDM能够给出推荐的解决方案和量化的期望受益值。同时ADDM也会标识系统中不存在问题的部分，这可以使我们快速地得知数据库哪些方面是相对优化的，从而可以跳过这些部分，节省调整和优化的时间。

新版的Oracle Enterprise Manager可以以一种方便直观的形式提供ADDM的结果和建议，并引导管理员逐步实施ADDM的建议，快速解决性能问题。

通过图1，可以直观地看到AWR与ADDM的关系。

图1 AWR与ADDM的关系

ADDM报告的生成

ADDM的诊断报告可以通过脚本调用来生成，该脚本位于$ORACLE_HOME/rdbms/admin/adddrpt.sql。运行这个脚本及回答的问题和其他报告类似：

SQL> @?/rdbms/admin/addmrpt

Current Instance

~~~~~~~~~~~~~~~~

DB Id DB Name Inst Num Instance

----------- ------------ -------- ------------

3965153484 DANALY 1 danaly

…………

生成的报告会根据内置的专家系统对系统的调整作出建议，下面简单摘录几点报告的建议。

列在第一位影响最大的是SGA，Oracle认为：SGA大小不适当，引发了额外的I/O和硬解析，所以推荐的解决方案是将SGA_TARGET参数从当前的900MB调整为1125MB。Oracle做出这一建议的原因是User I/O消耗了显著的数据库时间：

FINDING 1: 100% impact (1769 seconds)

-------------------------------------

The SGA was inadequately sized, causing additional I/O or hard parses.

RECOMMENDATION 1: DB Configuration, 100% benefit (1769 seconds)

ACTION: Increase the size of the SGA by setting the parameter

"sga_target" to 1125 M.

ADDITIONAL INFORMATION:

The value of parameter "sga_target" was "900 M" during the analysis

period.

SYMPTOMS THAT LED TO THE FINDING:

SYMPTOM: Wait class "User I/O" was consuming significant database time.

(58% impact [1022 seconds])

所谓的ADDM也正是数据库代替我们在对AWR报告进行分析，这个“药方”开的也是有理有据。

接下来排在第二位的是SQL调整建议：

FINDING 2: 45% impact (790 seconds)

-----------------------------------

SQL statements consuming significant database time were found.

RECOMMENDATION 1: SQL Tuning, 14% benefit (239 seconds)

ACTION: Tune the PL/SQL block with SQL_ID "6gvch1xu9ca3g". Refer to the

"Tuning PL/SQL Applications" chapter of Oracle's "PL/SQL User's Guide

and Reference"

RELEVANT OBJECT: SQL statement with SQL_ID 6gvch1xu9ca3g

DECLARE job BINARY_INTEGER := :job; next_date DATE := :mydate;

broken BOOLEAN := FALSE; BEGIN

EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); :mydate := next_date; IF

broken THEN :b := 1; ELSE :b := 0; END IF; END;

RATIONALE: SQL statement with SQL_ID "6gvch1xu9ca3g" was executed 441

times and had an average elapsed time of 0.54 seconds.

RECOMMENDATION 2: SQL Tuning, 11% benefit (193 seconds)

ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID

"00prz3j9n4gyj".

RELEVANT OBJECT: SQL statement with SQL_ID 00prz3j9n4gyj and

PLAN_HASH 2221002512

SELECT METRIC_GUID, TRUNC(COLLECTION_TIMESTAMP, 'HH24'), KEY_VALUE,

COUNT(TARGET_GUID), AVG(VALUE), MIN(VALUE), MAX(VALUE), STDDEV(VALUE)

FROM MGMT_METRICS_RAW WHERE TARGET_GUID = :B3 AND

COLLECTION_TIMESTAMP >= (:B2 +(1/24)) AND COLLECTION_TIMESTAMP < (:B1

+(1/24)) AND VALUE IS NOT NULL GROUP BY TARGET_GUID, METRIC_GUID,

KEY_VALUE, TRUNC(COLLECTION_TIMESTAMP, 'HH24')

RATIONALE: SQL statement with SQL_ID "00prz3j9n4gyj" was executed 42

times and had an average elapsed time of 4.5 seconds.

Oracle对执行次数、消耗时间等显著的SQL进行调整建议，诸如此类的建议有很多，这里不再一一列举。

在报告的最后部分，ADDM会对系统的“健康指标”进行描述，以使我们可以快速了解数据库的哪些部分在正常运作：

ADDITIONAL INFORMATION

----------------------

Wait class "Application" was not consuming significant database time.

Wait class "Concurrency" was not consuming significant database time.

Wait class "Configuration" was not consuming significant database time.

Wait class "Network" was not consuming significant database time.

Session connect and disconnect calls were not consuming significant database

time.

Hard parsing of SQL statements was not consuming significant database time.

ADDM的报告就像一张数据库的“体检报告”，专家会告诉我们数据库的哪些部件是运行良好的，哪些存在健康问题以及应该如何去治疗。