一个ADDM报告--自动数据库诊断监视器 (ADDM):
2016-03-01 00:05
309 查看
无聊，把自己电脑上学习的数据库的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% 期间, 数据库的维护窗口是处于活动状态的。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 基于 Red Hat 的发行版 Oracle Linux 正式发布Oracle Linux 7.1
- Oracle Containers for J2EE远程安全漏洞(CVE-2014-0413)
- Oracle 10g R2不能使用EM的问题
- 表空间操作
- PreparedStatement中in子句的处理
- VMware下RedHat4.8_64位安装Oracle 10g RAC--简略脚本
- oracle sql日期比较
- 基于 Red Hat 的发行版 Oracle Linux 正式发布Oracle Linux 7.1
- OS block size和Oracle block size，查找OS Blocksize的方法
- oracle中创建数据库和表空间的几点总结
- 数据库自动备份脚本
- oracle的nvl函数的使用介绍
- 解决oracle用户连接失败的解决方法
- oracle的一些tips技巧
- Oracle 下的开发日积月累
- Oracle存储过程之数据库中获取数据实例
- Windows下ORACLE 10g完全卸载的方法分析
- Oracle 函数大全[字符串函数，数学函数，日期函数]第1/4页
- ORACLE LATERAL-SQL-INJECTION 个人见解