今天做了个ADDM，有意思，看来DBA的技术含量确实约来越少了
ADDM=Automatic Database
Diagnostic Monitor
这个是oracle 10g推出的一个自动化管理的工具，可以根据 AWR采集的数据做自动的性能分析，给出相应的优化建议。
大家先看看这个ADDM的报告
DETAILED ADDM REPORT FOR TASK '任务_1072' WITH ID 1072
----------------------------------------------------
Analysis Period: from 21-11月-2005 10:00 to 22-11月-2005 14:40
Database ID/Instance: 612735569/1
Database/Instance Names: DB103/db103
Host Name: ×××××××××
Database Version: 10.2.0.1.0
Snapshot Range: from 216 to 245
Database Time: 1463 seconds
Average Database Load: 0 active sessions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
FINDING 1: 100% impact (1463 seconds)
-------------------------------------
在主机操作系统中检测到大量虚拟内存写入/写出。
RECOMMENDATION 1: Host Configuration, 100% benefit (1463 seconds)
ACTION: 主机操作系统出现大量内存写入/写出, 但未检测到根本原因。请研究不属
于 (在消耗了大量虚拟内存的主机上运行的)
此实例的进程。还可以考虑在主机中添加更多物理内存。
FINDING 2: 16% impact (241 seconds)
-----------------------------------
SGA 大小不合适, 导致附加 I/O 或硬语法分析。
RECOMMENDATION 1: DB Configuration, 15% benefit (216 seconds)
ACTION: 通过将参数 "sga_target" 设置为 300 M, 增加 SGA 的大小。
ADDITIONAL INFORMATION:
分析期间, 参数 "sga_target" 的值为 "200 M"。
SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: 对 SQL 语句的硬语法分析消耗了大量数据库时间。 (21% impact [303 se
conds])
SYMPTOM: 等待类别 "用户 I/O" 消耗了大量数据库时间。 (21% impact [301 secon
ds])
FINDING 3: 14% impact (210 seconds)
-----------------------------------
实例在 CPU 上花费的时间占据了数据库时间中的大部分。
RECOMMENDATION 1: Application Analysis, 11% benefit (159 seconds)
ACTION: 对 SQL 语句进行语法分析占用了大量 CPU 资源。有关详细资料, 请参阅此
任务中有关语法分析的其它查找结果。
RECOMMENDATION 2: SQL Tuning, 3.4% benefit (50 seconds)
ACTION: 优化 SQL_ID 为 "2b064ybzkwf1y" 的 PL/SQL 块。请参阅 Oracle 的 "PL/
SQL
User\'s Guide and Reference" 中的 "Tuning PL/SQL Applications" 一章。
RELEVANT OBJECT: SQL statement with SQL_ID 2b064ybzkwf1y
BEGIN EMD_NOTIFICATION.QUEUE_READY(:1, :2, :3); END;
RATIONALE: SQL_ID 为 "2b064ybzkwf1y" 的 SQL 语句执行了 147 次, 每次执行平
均用时 0.47 秒。
RATIONALE: 每次执行使用 CPU 的平均时间为 0.34 秒。
FINDING 4: 10% impact (146 seconds)
-----------------------------------
发现个别数据库段造成了大量的用户 I/O 等待。
RECOMMENDATION 1: Segment Tuning, 5.3% benefit (77 seconds)
ACTION: 在 TABLE "WZY2.WZY_OBJ2" (对象 ID 为 51457) 上运行 "Segment Adviso
r"。
RELEVANT OBJECT: database object with id 51457
ACTION: 调查涉及 TABLE "WZY2.WZY_OBJ2" (对象 ID 为 51457) 的 I/O 的应用程
序逻辑。
RELEVANT OBJECT: database object with id 51457
RATIONALE: 对象的 I/O 使用统计信息为: 3 完整对象扫描, 21225 物理读取, 0 物
理写入和 8316 直接读取。
RECOMMENDATION 2: Segment Tuning, 4.7% benefit (69 seconds)
ACTION: 在 LOB "SYS.SYS_LOB0000000493C00003$$" (对象 ID 为 494) 上运行 "Se
gment
Advisor"。
RELEVANT OBJECT: database object with id 494
ACTION: 调查涉及 LOB "SYS.SYS_LOB0000000493C00003$$" (对象 ID 为 494) 的 I
/O
的应用程序逻辑。
RELEVANT OBJECT: database object with id 494
RATIONALE: 对象的 I/O 使用统计信息为: 0 完整对象扫描, 14981 物理读取, 0 物
理写入和 14981 直接读取。
SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: 等待类别 "用户 I/O" 消耗了大量数据库时间。 (21% impact [301 secon
ds])
FINDING 5: 6.4% impact (94 seconds)
-----------------------------------
发现 SQL 语句消耗了大量数据库时间。
RECOMMENDATION 1: SQL Tuning, 6.4% benefit (94 seconds)
ACTION: 优化 SQL_ID 为 "6gvch1xu9ca3g" 的 PL/SQL 块。请参阅 Oracle 的 "PL/
SQL
User\'s Guide and Reference" 中的 "Tuning PL/SQL Applications" 一章。
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_ID 为 "6gvch1xu9ca3g" 的 SQL 语句执行了 1396 次, 每次执行平
均用时 0.076
秒。
FINDING 6: 4.8% impact (70 seconds)
-----------------------------------
PL/SQL 执行消耗了大量数据库时间。
RECOMMENDATION 1: SQL Tuning, 4.8% benefit (70 seconds)
ACTION: 优化 SQL_ID 为 "2b064ybzkwf1y" 的 PL/SQL 块。请参阅 Oracle 的 "PL/
SQL
User\'s Guide and Reference" 中的 "Tuning PL/SQL Applications" 一章。
RELEVANT OBJECT: SQL statement with SQL_ID 2b064ybzkwf1y
BEGIN EMD_NOTIFICATION.QUEUE_READY(:1, :2, :3); END;
RATIONALE: SQL_ID 为 "2b064ybzkwf1y" 的 SQL 语句执行了 147 次, 每次执行平
均用时 0.47 秒。
RATIONALE: 在 PL/SQL 执行上花费的平均时间为 0.47 秒。
FINDING 7: 4.5% impact (65 seconds)
-----------------------------------
等待事件 "Streams AQ: qmn coordinator waiting for slave to start" (在等待类 "Oth
er" 中)
消耗了大量数据库时间。
RECOMMENDATION 1: Application Analysis, 4.5% benefit (65 seconds)
ACTION: 研究 "Streams AQ: qmn coordinator waiting for slave to start"
等待数较大的原因。有关此等待事件的说明, 请参阅 Oracle 的 "Database Refe
rence"。
RECOMMENDATION 2: Application Analysis, 4.5% benefit (65 seconds)
ACTION: 研究 "Streams AQ: qmn coordinator waiting for slave to start" 等待
数在
"SYS$BACKGROUND" 服务中非常高的原因。
SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: 等待类别 "其它" 消耗了大量数据库时间。 (6.1% impact [90 seconds])
FINDING 8: 4.4% impact (64 seconds)
-----------------------------------
等待类别 "调度程序" 消耗了大量数据库时间。
NO RECOMMENDATIONS AVAILABLE
FINDING 9: 4% impact (59 seconds)
---------------------------------
对 SQL 语句的软语法分析消耗了大量数据库时间。
RECOMMENDATION 1: Application Analysis, 4% benefit (59 seconds)
ACTION: 研究应用程序逻辑, 使经常使用的游标保持打开。请注意, 可以通过游标关
闭调用或会话断开连接来关闭游标。
RECOMMENDATION 2: DB Configuration, 4% benefit (59 seconds)
ACTION: 考虑通过增加 "open_cursors" 参数的值来增加每个会话可以打开的最大游
标数。
ACTION: 考虑通过增加 "session_cached_cursors" 参数的值来增加会话游标高速缓
存大小。
RATIONALE: 分析期间, 参数 "open_cursors" 的值为 "300"。
RATIONALE: 分析期间, 参数 "session_cached_cursors" 的值为 "20"。
FINDING 10: 3.5% impact (52 seconds)
------------------------------------
I/O 子系统的吞吐量比预期吞吐量小得多。
RECOMMENDATION 1: Host Configuration, 3.5% benefit (52 seconds)
ACTION: 考虑增加 I/O 子系统的吞吐量。Oracle 建议的解决方案是使用 SAME
方法将所有数据文件条带化。可能还需要增加磁盘数量以获得更好的性能。或者,
考虑使用 Oracle 的自动存储管理解决方案。
RATIONALE: 分析期间, 数据文件的平均 I/O 吞吐量, 对于读取为每秒 4.8 K, 对于
写入为每秒 2.7
K。单个块读取的平均响应时间为 11 毫秒。
SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: 等待类别 "用户 I/O" 消耗了大量数据库时间。 (21% impact [301 secon
ds])
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ADDITIONAL INFORMATION
----------------------
等待类别 "应用程序" 并未消耗大量数据库时间。
等待类别 "提交" 并未消耗大量数据库时间。
等待类别 "配置" 并未消耗大量数据库时间。
等待类别 "网络" 并未消耗大量数据库时间。
会话连接和断开连接的调用并未消耗大量数据库时间。
在分析时段的 27% 期间, 数据库的维护窗口是处于活动状态的。
The analysis of I/O performance is based on the default assumption that the
average read time for one database block is 10000 micro-seconds.
An explanation of the terminology used in this report is available when you
run the report with the 'ALL' level of detail.
|
