无聊，把自己电脑上学习的数据库的ADDM报告拿到来看看，感觉性能很差啊 哈哈 
仅供学习参考，仅供学习参考，仅供学习参考
任务 'ADDM:1392579372_1_572' 的 ADDM 报告
------------------------------------
分析时段
----
AWR 快照范围从 571 到 572。
时段从 29-2月 -16 10.00.41 下午 开始
时段在 29-2月 -16 11.00.03 下午 结束
分析目标
----
数据库 'ORCL' (DB ID 为 1392579372)。
数据库版本 11.2.0.1.0。
ADDM 对实例 orcl 执行了分析, 该实例的编号为 1 并运行于 localhost.localdomain。
分析时段期间的活动
---------
总数据库时间为 19763 秒。
活动会话的平均数量为 5.55。
查找结果概要
------
说明 活动的会话 建议案
活动的百分比
------------------------ ------ ---
1 顶级 SQL 语句 3.36 | 60.544
2 按 "用户 I/O" 和 "集群" 统计的顶级段 3.26 | 58.672
3 PGA 不够大 3.12 | 56.231
4 提交和回退 1.29 | 23.22
5 "调度程序" 等待类 .25 | 4.560
6 I/O 吞吐量 .23 | 4.111
7 "并行" 等待类 .18 | 3.320
8 由于并行查询而产生的检查点 .07 | 1.320
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
查找结果和建议案
--------
查找结果 1: 顶级 SQL 语句
受影响的是 3.36 个活动会话, 占总活动的 60.54\%。
--------------------------------
发现 SQL 语句消耗了大量数据库时间。这些语句提供了改善性能的绝佳机会。
建议案 1: SQL 优化
估计的收益为 1.75 个活动会话, 占总活动的 31.56\%。
---------------------------------
操作
对 SELECT 语句 (SQL_ID 为 "fpactj934kg4c") 运行 SQL 优化指导。
相关对象
SQL_ID 为 fpactj934kg4c 的 SQL 语句。
select count(*) from (SELECT distinct J.RECORDID, J.AJDJH, (CASE
WHEN (J.SJFS = 1) THEN '来信登记' WHEN (J.SJFS = 2) THEN '接待登记' ELSE ''
END ) AS SJFS, J.SJLX, J.AJZT, J.AJDJR, J.LASCR_ZZJG,
J.CBC_LAC, J.CBR_LAC, J.CBC_LAJBLC, J.CBR_LAJBLC, J.JSRQ,
JD.JDRQ, J.DJSJ, J.DCSJ, J.BJSJ_LAC, JD.BJDRS, J.SPR,
J.LB, J.SQRRS, J.BSQRZL, J.BSQRMC, J.FYXWMC, J.MJ, J.QX,
J.FYXWWH, J.YJTXWMC, J.YJTXWWH, to_char(J.YJTXWWHSJ,'yyyy-mm-dd')
as YJTXWWHSJ, J.XZGLQY, J.XZXWLB, J.AJCLJG, J.AJCLZJG,
J.BLWH, J.JALX, J.GBZT, J.CBCS, R.XM, R.SDDZ,
J.LXRDZ FROM XZANJIANXX J LEFT JOIN XZJIEDAIXX JD on JD.RECORDID
= J.JDXX_ID INNER JOIN XZANJIANRYXX R ON J.RECORDID = R.SSID AND
R.XH = 1 WHERE 1 = 1 AND J.ISDELETE = 0) t1
原理
SQL 在 CPU, I/O 和集群等待上花费的时间占其数据库时间的 98%。这部分数据库时间可通过 SQL 优化指导进行改善。
原理
此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL 执行占 0%, Java 执行占 0%。
原理
SQL_ID 为 "fpactj934kg4c" 的 SQL 语句执行了 5 次, 每次执行平均用时 1229 秒。
原理
TABLE "XZANJIANXX" (对象 ID 为 83618) 的 I/O 和集群等待消耗了在此 SQL
语句上花费的数据库时间的 89%。
原理
TABLE "XZANJIANRYXX" (对象 ID 为 83319) 的 I/O 和集群等待消耗了在此 SQL
语句上花费的数据库时间的 8%。
建议案 2: SQL 优化
估计的收益为 1.08 个活动会话, 占总活动的 19.44\%。
---------------------------------
操作
对 SELECT 语句 (SQL_ID 为 "91kyg7ahvn10u") 运行 SQL 优化指导。
相关对象
SQL_ID 为 91kyg7ahvn10u 的 SQL 语句。
select * from (select rs.*,rownum rnm from (SELECT J.RECORDID,
J.AJDJH, J.SJLX, (CASE WHEN
(J.SJFS = 1) THEN '来信登记' WHEN (J.SJFS = 2) THEN '接待登记' ELSE '' END )
AS SJFS, to_char(J.JSRQ,'yyyy-mm-dd') as JSRQ,
to_char(J.BJSJ_LAC,'yyyy-mm-dd') as BJSJ, R.XM
AS XM, R.SDDZ AS ZZ,
J.BSQRMC, J.AJDJR, J.LASCR_ZZJG,
J.CBR_LAC, J.SPR, J.AJZT_CODE,
J.AJZT, J.GBZT, J.Cjajdjh,
J.BAZT, J.MJ, J.QX,
J.BADJH, J.SPJG, J.CBCS
FROM XZANJIANXX J, XZANJIANRYXX R WHERE J.RECORDID = R.SSID
AND R.XH = 1 AND J.ISDELETE = 0 ORDER BY (CASE WHEN
J.LASCR_ZZJG = '系统管理员' THEN 1 ELSE 2 END ), J.AJZT, J.AJDJH DESC ) rs
where rownum:2
原理
SQL 在 CPU, I/O 和集群等待上花费的时间占其数据库时间的 98%。这部分数据库时间可通过 SQL 优化指导进行改善。
原理
此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL 执行占 0%, Java 执行占 0%。
原理
SQL_ID 为 "91kyg7ahvn10u" 的 SQL 语句执行了 14 次, 每次执行平均用时 269 秒。
原理
TABLE "XZANJIANXX" (对象 ID 为 83618) 的 I/O 和集群等待消耗了在此 SQL
语句上花费的数据库时间的 76%。
原理
TABLE "XZANJIANRYXX" (对象 ID 为 83319) 的 I/O 和集群等待消耗了在此 SQL
语句上花费的数据库时间的 22%。
建议案 3: SQL 优化
估计的收益为 .27 个活动会话, 占总活动的 4.85\%。
-------------------------------
操作
对 SELECT 语句 (SQL_ID 为 "5d055dwy137nk") 运行 SQL 优化指导。
相关对象
SQL_ID 为 5d055dwy137nk 的 SQL 语句。
select count(*) from (SELECT J.RECORDID, J.AJDJH,
J.SJLX, (CASE WHEN (J.SJFS = 1) THEN '来信登记' WHEN
(J.SJFS = 2) THEN '接待登记' ELSE '' END ) AS SJFS,
to_char(J.JSRQ,'yyyy-mm-dd') as JSRQ,
to_char(J.BJSJ_LAC,'yyyy-mm-dd') as BJSJ, R.XM
AS XM, R.SDDZ AS ZZ,
J.BSQRMC, J.AJDJR, J.LASCR_ZZJG,
J.CBR_LAC, J.SPR, J.AJZT_CODE,
J.AJZT, J.GBZT, J.Cjajdjh,
J.BAZT, J.MJ, J.QX,
J.BADJH, J.SPJG, J.CBCS
FROM XZANJIANXX J, XZANJIANRYXX R WHERE J.RECORDID = R.SSID
AND R.XH = 1 AND J.ISDELETE = 0 ORDER BY (CASE WHEN
J.LASCR_ZZJG = '系统管理员' THEN 1 ELSE 2 END ), J.AJZT, J.AJDJH DESC ) t1
原理
SQL 在 CPU, I/O 和集群等待上花费的时间占其数据库时间的 92%。这部分数据库时间可通过 SQL 优化指导进行改善。
原理
此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL 执行占 0%, Java 执行占 0%。
原理
SQL_ID 为 "5d055dwy137nk" 的 SQL 语句执行了 9 次, 每次执行平均用时 115 秒。
原理
TABLE "XZANJIANXX" (对象 ID 为 83618) 的 I/O 和集群等待消耗了在此 SQL
语句上花费的数据库时间的 90%。
建议案 4: SQL 优化
估计的收益为 .19 个活动会话, 占总活动的 3.48\%。
-------------------------------
操作
对 SELECT 语句 (SQL_ID 为 "ctwm11jdacfh4") 运行 SQL 优化指导。
相关对象
SQL_ID 为 ctwm11jdacfh4 的 SQL 语句。
select * from (select rs.*,rownum rnm from (SELECT distinct
J.RECORDID, J.AJDJH, (CASE WHEN (J.SJFS = 1) THEN '来信登记' WHEN
(J.SJFS = 2) THEN '接待登记' ELSE '' END ) AS SJFS, J.SJLX, J.AJZT,
J.AJDJR, J.LASCR_ZZJG, J.CBC_LAC, J.CBR_LAC, J.CBC_LAJBLC,
J.CBR_LAJBLC, J.JSRQ, JD.JDRQ, J.DJSJ, J.DCSJ, J.BJSJ_LAC,
JD.BJDRS, J.SPR, J.LB, J.SQRRS, J.BSQRZL, J.BSQRMC,
J.FYXWMC, J.MJ, J.QX, J.FYXWWH, J.YJTXWMC, J.YJTXWWH,
to_char(J.YJTXWWHSJ,'yyyy-mm-dd') as YJTXWWHSJ, J.XZGLQY,
J.XZXWLB, J.AJCLJG, J.AJCLZJG, J.BLWH, J.JALX, J.GBZT,
J.CBCS, R.XM, R.SDDZ,
J.LXRDZ FROM XZANJIANXX J LEFT JOIN XZJIEDAIXX JD on JD.RECORDID
= J.JDXX_ID INNER JOIN XZANJIANRYXX R ON J.RECORDID = R.SSID AND
R.XH = 1 WHERE 1 = 1 AND J.ISDELETE = 0) rs where rownum:2
原理
SQL 在 CPU, I/O 和集群等待上花费的时间占其数据库时间的 100%。这部分数据库时间可通过 SQL 优化指导进行改善。
原理
此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL 执行占 0%, Java 执行占 0%。
原理
SQL_ID 为 "ctwm11jdacfh4" 的 SQL 语句执行了 5 次, 每次执行平均用时 134 秒。
原理
TABLE "XZANJIANXX" (对象 ID 为 83618) 的 I/O 和集群等待消耗了在此 SQL
语句上花费的数据库时间的 81%。
查找结果 2: 按 "用户 I/O" 和 "集群" 统计的顶级段
受影响的是 3.26 个活动会话, 占总活动的 58.67\%。
--------------------------------
发现个别数据库段造成了大量的 "用户 I/O" 和 "集群" 等待。
建议案 1: 段优化
估计的收益为 2.83 个活动会话, 占总活动的 50.97\%。
---------------------------------
操作
在 TABLE "XZANJIANXX" (对象 ID 为 83618) 上运行 "段指导"。
相关对象
ID 为 83618 的数据库对象。
操作
研究涉及 TABLE "XZANJIANXX" (对象 ID 为 83618) 的 I/O 的应用程序逻辑。
相关对象
ID 为 83618 的数据库对象。
操作
查看 "顶级 SQL 语句" 以找出此段上消耗大量 I/O 的 SQL 语句。例如, SELECT 语句 (SQL_ID 为
"fpactj934kg4c") 占此段上的 "用户 I/O" 和 "集群" 等待的 56%。
原理
对象的 I/O 使用统计信息为: 67 完整对象扫描, 1314089 物理读取, 1320 物理写入和 1260210 直接读取。
建议案 2: 段优化
估计的收益为 .43 个活动会话, 占总活动的 7.7\%。
------------------------------
操作
研究涉及 TABLE "XZANJIANRYXX" (对象 ID 为 83319) 的 I/O 的应用程序逻辑。
相关对象
ID 为 83319 的数据库对象。
操作
查看 "顶级 SQL 语句" 以找出此段上消耗大量 I/O 的 SQL 语句。例如, SELECT 语句 (SQL_ID 为
"91kyg7ahvn10u") 占此段上的 "用户 I/O" 和 "集群" 等待的 56%。
原理
对象的 I/O 使用统计信息为: 25 完整对象扫描, 245763 物理读取, 1375 物理写入和 235649 直接读取。
导致查找结果的故障现象:
------------
等待类 "用户 I/O" 消耗了大量数据库时间。
受影响的是 3.4 个活动会话, 占总活动的 61.24\%。
查找结果 3: PGA 不够大
受影响的是 3.12 个活动会话, 占总活动的 56.23\%。
--------------------------------
PGA 大小不合适导致了对临时表空间的附加 I/O, 从而消耗了大量数据库时间。
分析期间, 参数 "pga_aggregate_target" 的值为 "256 M"。
建议案 1: 数据库配置
估计的收益为 .53 个活动会话, 占总活动的 9.56\%。
-------------------------------
操作
通过将 "pga_aggregate_target" 参数的值设置为 358 M, 增加 PGA 的大小。
导致查找结果的故障现象:
------------
等待类 "用户 I/O" 消耗了大量数据库时间。
受影响的是 3.4 个活动会话, 占总活动的 61.24\%。
查找结果 4: 提交和回退
受影响的是 1.29 个活动会话, 占总活动的 23.2\%。
-------------------------------
在执行 COMMIT 和 ROLLBACK 操作时, 等待 "日志文件同步" 事件消耗了大量数据库时间。
建议案 1: 应用程序分析
估计的收益为 1.29 个活动会话, 占总活动的 23.2\%。
--------------------------------
操作
研究应用程序逻辑, 了解通过增加事务处理的大小来减少 COMMIT 操作数量的可能性。
原理
应用程序每分钟执行 741 个事务处理, 每个事务处理的平均重做日志大小为 3900 字节。
建议案 2: 主机配置
估计的收益为 1.29 个活动会话, 占总活动的 23.2\%。
--------------------------------
操作
研究改善对联机重做日志文件的 I/O 性能的可能性。
原理
对联机重做日志文件执行写入的平均大小为 19 K, 每次写入的平均时间为 61 毫秒。
原理
重做日志文件上的总 I/O 吞吐量的读取为每秒 43 K, 写入为每秒 48 K。
原理
重做日志 I/O 吞吐量由以下部分构成: RMAN 和恢复占 0%, 日志写进程占 52%, 归档程序占 0%, 流 AQ 占 0%,
所有其他活动占 47%。
导致查找结果的故障现象:
------------
等待类 "提交" 消耗了大量数据库时间。
受影响的是 1.29 个活动会话, 占总活动的 23.2\%。
查找结果 5: "调度程序" 等待类
受影响的是 .25 个活动会话, 占总活动的 4.56\%。
------------------------------
等待类 "调度程序" 消耗了大量数据库时间。
没有可用的建议案。
查找结果 6: I/O 吞吐量
受影响的是 .23 个活动会话, 占总活动的 4.11\%。
------------------------------
I/O 子系统的吞吐量比预期吞吐量小得多。
建议案 1: 主机配置
估计的收益为 .23 个活动会话, 占总活动的 4.11\%。
-------------------------------
操作
考虑增加 I/O 子系统的吞吐量。Oracle 建议的解决方案是使用 SAME
方法将所有数据文件条带化。您可能还需要增加磁盘数量以获得更好的性能。
原理
分析期间, 数据文件的平均 I/O 吞吐量, 对于读取为每秒 3.5 M, 对于写入为每秒 81 K。单个块读取的平均响应时间为 16 毫秒。
导致查找结果的故障现象:
------------
等待类 "用户 I/O" 消耗了大量数据库时间。
受影响的是 3.4 个活动会话, 占总活动的 61.24\%。
查找结果 7: "并行" 等待类
受影响的是 .18 个活动会话, 占总活动的 3.32\%。
------------------------------
等待类 "并发" 消耗了大量数据库时间。
对 "缓冲区忙" 事件的等待并未消耗大量数据库时间。
与共享池相关的闩锁争用并未消耗大量数据库时间。
对缓冲区高速缓存闩锁的争用并未消耗大量数据库时间。
DBMS_PIPE.PUT 调用中的等待并未消耗大量数据库时间。
索引块分离的争用未消耗大量数据库时间。
没有可用的建议案。
查找结果 8: 由于并行查询而产生的检查点
受影响的是 .07 个活动会话, 占总活动的 1.32\%。
------------------------------
由于对相同对象的并发 DML 和并行查询而产生的缓冲区高速缓存写入对 I/O 子系统的吞吐量有很大影响。
没有可用的建议案。
导致查找结果的故障现象:
------------
I/O 子系统的吞吐量比预期吞吐量小得多。
受影响的是 .23 个活动会话, 占总活动的 4.11\%。
等待类 "用户 I/O" 消耗了大量数据库时间。
受影响的是 3.4 个活动会话, 占总活动的 61.24\%。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
附加信息
----
各种信息
----
等待类 "应用程序" 并未消耗大量数据库时间。
等待类 "配置" 并未消耗大量数据库时间。
CPU 不是此实例的瓶颈。
等待类 "网络" 并未消耗大量数据库时间。
会话连接和断开连接的调用并未消耗大量数据库时间。
对 SQL 语句的硬语法分析并未消耗大量数据库时间。
在分析时段的 99% 期间, 数据库的维护窗口是处于活动状态的。
1464
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
