可通过@?/rdbms/admin/addmrpt.sql生成ADDM报告
ADDM本身并不是很实用，抽象级别太高，用于初步判断系统配置/IO子系统是否合理和快速参考，一个报告截图如下：
任务 '任务_1853' 的 ADDM 报告
----------------------分析时段
----AWR 快照范围从 1681 到 1690。时段从 06-12月-18 10.00.42 上午 开始时段在 06-12月-18 12.15.37 下午 结束分析目标
----数据库 'ORCL' (DB ID 为 1519409103)。数据库版本 11.2.0.4.0。ADDM 对实例 orcl 执行了分析, 该实例的编号为 1 并运行于 TA5。分析时段期间的活动
---------总数据库时间为 22873 秒。活动会话的平均数量为 2.83。查找结果概要
------ 说明 活动的会话 建议案 活动的百分比 ------------ ------ ---1 "用户 I/O" 等待类 1.1 | 38.902 顶级 SQL 语句 .99 | 34.8953 重做日志缓冲区不够大 .76 | 27.0214 SGA 不够大 .65 | 23.0215 提交和回退 .12 | 4.241 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 查找结果和建议案 --------查找结果 1: "用户 I/O" 等待类
受影响的是 1.1 个活动会话, 占总活动的 38.9\%。------------------------------等待类 "用户 I/O" 消耗了大量数据库时间。等待临时表空间的 I/O 并未消耗大量数据库时间。I/O 子系统的吞吐量不比预期吞吐量小很多。没有可用的建议案。
查找结果 2: 顶级 SQL 语句受影响的是 .99 个活动会话, 占总活动的 34.89\%。-------------------------------发现 SQL 语句消耗了大量数据库时间。这些语句提供了改善性能的绝佳机会。建议案 1: SQL 优化
估计的收益为 .27 个活动会话, 占总活动的 9.6\%。 ------------------------------ 操作 研究 INSERT 语句 (SQL_ID 为 "g3ff2u5n0bvdv"), 确定是否可以改善性能。可以利用此 SQL_ID 的 ASH 报告来补充此处给出的信息。 相关对象 SQL_ID 为 g3ff2u5n0bvdv 的 SQL 语句。 insert into ta_trequest_tmp(c_tenantid,c_tacode,c_requestno,d_request date,c_agencyno,c_fundcode,c_exceedflag,d_requesttime,c_tradeacco,f_s hares,f_balance,c_outbusinflag,c_fundacco,f_agio,c_netno,c_orirequest no,d_hopedate,c_oricserialno,c_otheragency,f_tradefare,c_othernetno,c _othertradeacco,c_othercode,f_totalbackendload,c_sharetype,d_factdate ,c_bonustype,c_freezecause,d_freezeenddate,c_rationvariety,c_rationse rialno,c_rationtype,c_otheracco,c_othershare,c_protocolno,d_protocolb egindate,d_protocolenddate,l_rationdate,c_broker,c_specialcode,c_acce ptmode,c_rationpurpose,l_rationfrequency,c_rationterm,c_rationtimeuni t,f_rationnum,c_fundmethod,c_subfundmethod,f_backfareagio,c_combcode, c_trademethod,c_businflag,c_cserialno,c_reqtradeacco,f_oriagio,c_tafl ag,c_chkstatus,c_status,c_cause,d_date,f_failedbalance,f_failedshares ,d_cdate,f_confirmratio,f_price,c_freezeno,c_specialrequestflag,c_tra nsfarecause,c_adjustcause,f_income,c_improperredeem,f_otherprice,d_or iginaldate,c_forceredemptiontype,d_registdate,f_confirmedbalance,f_co nfirmedshares,c_operator,c_memo,c_nodealflag,f_manualtradefare,c_bank no,l_reqserialno,l_shardingno,c_liqbatchno) values(:c_tenantid,:c_tacode,:c_requestno,:d_requestdate,:c_agencyno, :c_fundcode,:c_exceedflag,:d_requesttime,:c_tradeacco,:f_shares,:f_ba lance,:c_outbusinflag,:c_fundacco,:f_agio,:c_netno,:c_orirequestno,:d _hopedate,:c_oricserialno,:c_otheragency,:f_tradefare,:c_othernetno,: c_othertradeacco,:c_othercode,:f_totalbackendload,:c_sharetype,:d_fac tdate,:c_bonustype,:c_freezecause,:d_freezeenddate,:c_rationvariety,: c_rationserialno,:c_rationtype,:c_otheracco,:c_othershare,:c_protocol no,:d_protocolbegindate,:d_protocolenddate,:l_rationdate,:c_broker,:c _specialcode,:c_acceptmode,:c_rationpurpose,:l_rationfrequency,:c_rat ionterm,:c_rationtimeunit,:f_rationnum,:c_fundmethod,:c_subfundmethod ,:f_backfareagio,:c_combcode,:c_trademethod,:c_businflag,:c_cserialno ,:c_reqtradeacco,:f_oriagio,:c_taflag,:c_chkstatus,:c_status,:c_cause ,:d_date,:f_failedbalance,:f_failedshares,:d_cdate,:f_confirmratio,:f _price,:c_freezeno,:c_specialrequestflag,:c_transfarecause,:c_adjustc ause,:f_income,:c_improperredeem,:f_otherprice,:d_originaldate,:c_for ceredemptiontype,:d_registdate,:f_confirmedbalance,:f_confirmedshares ,:c_operator,:c_memo,:c_nodealflag,:f_manualtradefare,:c_bankno,:l_re qserialno,:l_shardingno,:c_liqbatchno) 原理 SQL 在 CPU, I/O 和集群等待上花费的时间只占其数据库时间的 25%。因此, SQL 优化指导不适用于这种情况。请查看 SQL 的性能数据以找出可能的改进方法。 原理 此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL执行占 0%, Java 执行占 0%。 原理 SQL_ID 为 "g3ff2u5n0bvdv" 的 SQL 语句执行了 49 次, 每次执行平均用时 42 秒。 原理 等待事件 "log buffer space" (在等待类 "Configuration" 中) 消耗了数据库时间的 71% (该数据库时间为处理具有 SQL_ID "g3ff2u5n0bvdv" 的 SQL 语句时所用的时间)。建议案 2: SQL 优化
估计的收益为 .23 个活动会话, 占总活动的 8.25\%。 ------------------------------- 操作 对 INSERT 语句 (SQL_ID 为 "6t4drz4aytqfk") 运行 SQL 优化指导。此外, 研究此语句, 确定是否可以改善性能。可以利用此 SQL_ID 的 ASH 报告来补充此处给出的信息。 相关对象 SQL_ID 为 6t4drz4aytqfk 的 SQL 语句。 insert into ta_tsharecurrents(c_tenantid,c_tacode,d_cdate,c_cserialno ,c_businflag,d_requestdate,c_requestno,c_fundacco,c_agencyno,c_netno, c_tradeacco,c_fundcode,c_sharetype,f_occurshares,f_occurbalance,f_las tshares,f_occurfreeze,f_lastfreezeshares,c_bonustype,c_custtype,c_out businflag,c_shrcrtserailno,c_adjustcause,c_specialcode) values(:c_tenantid,:c_tacode,:d_cdate,:c_cserialno,:c_businflag,:d_re questdate,:c_requestno,:c_fundacco,:c_agencyno,:c_netno,:c_tradeacco, :c_fundcode,:c_sharetype,:f_occurshares,:f_occurbalance,:f_lastshares ,:f_occurfreeze,:f_lastfreezeshares,:c_bonustype,:c_custtype,:c_outbu sinflag,:c_shrcrtserailno,:c_adjustcause,:c_specialcode) 原理 SQL 在 CPU, I/O 和集群等待上花费的时间占其数据库时间的 45%。这部分数据库时间可通过 SQL 优化指导进行改善。请查看下面给出的数据和 ASH 报告以进一步改善性能。 原理 此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL执行占 0%, Java 执行占 0%。 原理 SQL_ID 为 "6t4drz4aytqfk" 的 SQL 语句执行了 44 次, 每次执行平均用时 41 秒。 原理 等待事件 "log buffer space" (在等待类 "Configuration" 中) 消耗了数据库时间的 52% (该数据库时间为处理具有 SQL_ID "6t4drz4aytqfk" 的 SQL 语句时所用的时间)。建议案 3: SQL 优化
估计的收益为 .19 个活动会话, 占总活动的 6.59\%。 ------------------------------- 操作 研究 INSERT 语句 (SQL_ID 为 "6z5kj9j2r6by1"), 确定是否可以改善性能。可以利用此 SQL_ID 的 ASH 报告来补充此处给出的信息。 相关对象 SQL_ID 为 6z5kj9j2r6by1 的 SQL 语句。 insert into ta_tconfirm_tmp(c_businflag,d_cdate,c_cserialno,c_netno,c _tradeacco,c_fundcode,f_confirmbalance,f_confirmshares,f_tradefare,f_ tafare,f_stamptax,f_backfare,f_otherfare1,f_breachfare,f_profitbalanc e,f_totalfare,f_tradefare4agt,f_tradefare4fund,f_tafare4agt,f_tafare4 fund,f_backfare4agt,f_backfare4fund,f_otherfare14agt,f_otherfare14fun d,f_breachfare4agt,f_breachfare4fund,f_interest,f_interestshare,f_int eresttax,f_netvalue,f_frozenbalance,f_unfrozenbalance,c_status,c_caus e,c_custtype,f_chincome,f_confirmincome,f_income,f_confirmratio,f_ori tradefare,f_oritafare,f_oribackfare,f_oriotherfare1,f_oribreachfare,c _othertradeacco,c_outbusinflag,f_backfareagio,c_shareclass,c_boursefl ag,c_subfundmethod,f_returnfare,f_punishratio,c_sharetype,d_outputdat e,d_reqoutputdate,f_profitbalance4agt,f_profitbalance4fund,f_balance, c_adjustcause,c_requestendflag,c_exceedflag,l_reqserialno,f_protectba lance,f_reqrdmbalance,c_tacode,c_tenantid,c_fundacco,c_liqbatchno) values(:c_businflag,:d_cdate,:c_cserialno,:c_netno,:c_tradeacco,:c_fu ndcode,:f_confirmbalance,:f_confirmshares,:f_tradefare,:f_tafare,:f_s tamptax,:f_backfare,:f_otherfare1,:f_breachfare,:f_profitbalance,:f_t otalfare,:f_tradefare4agt,:f_tradefare4fund,:f_tafare4agt,:f_tafare4f und,:f_backfare4agt,:f_backfare4fund,:f_otherfare14agt,:f_otherfare14 fund,:f_breachfare4agt,:f_breachfare4fund,:f_interest,:f_interestshar e,:f_interesttax,:f_netvalue,:f_frozenbalance,:f_unfrozenbalance,:c_s tatus,:c_cause,:c_custtype,:f_chincome,:f_confirmincome,:f_income,:f_ confirmratio,:f_oritradefare,:f_oritafare,:f_oribackfare,:f_oriotherf are1,:f_oribreachfare,:c_othertradeacco,:c_outbusinflag,:f_backfareag io,:c_shareclass,:c_bourseflag,:c_subfundmethod,:f_returnfare,:f_puni shratio,:c_sharetype,:d_outputdate,:d_reqoutputdate,:f_profitbalance4 agt,:f_profitbalance4fund,:f_balance,:c_adjustcause,:c_requestendflag ,:c_exceedflag,:l_reqserialno,:f_protectbalance,:f_reqrdmbalance,:c_t acode,:c_tenantid,:c_fundacco,:c_liqbatchno) 原理 SQL 在 CPU, I/O 和集群等待上花费的时间只占其数据库时间的 27%。因此, SQL 优化指导不适用于这种情况。请查看 SQL 的性能数据以找出可能的改进方法。 原理 此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL 执行占 0%, Java 执行占 0%。 原理 SQL_ID 为 "6z5kj9j2r6by1" 的 SQL 语句执行了 66 次, 每次执行平均用时 22 秒。 原理 等待事件 "log buffer space" (在等待类 "Configuration" 中) 消耗了数据库时间的 71% (该数据库时间为处理具有 SQL_ID "6z5kj9j2r6by1" 的 SQL 语句时所用的时间)。建议案 4: SQL 优化
估计的收益为 .16 个活动会话, 占总活动的 5.83\%。 ------------------------------- 操作 对 INSERT 语句 (SQL_ID 为 "cnzuj8k8yp0sb") 运行 SQL 优化指导。此外, 研究此语句, 确定是否可以改善性能。可以利用此 SQL_ID 的 ASH 报告来补充此处给出的信息。 相关对象 SQL_ID 为 cnzuj8k8yp0sb 的 SQL 语句。 insert/*+ append nologging */into ta_tconfirm (c_businflag,d_cdate,c_cserialno,c_netno,c_tradeacco,c_fundcode,f_con firmbalance,f_confirmshares,f_tradefare,f_tafare, f_stamptax,f_backfare,f_otherfare1,f_breachfare,f_profitbalance,f_tot alfare,f_tradefare4agt,f_tradefare4fund, f_tafare4agt,f_tafare4fund,f_backfare4agt,f_backfare4fund,f_otherfare 14agt,f_otherfare14fund,f_breachfare4agt, f_breachfare4fund,f_interest,f_interestshare,f_interesttax,f_netvalue ,f_frozenbalance,f_unfrozenbalance,c_status, c_cause,c_custtype,f_chincome,f_confirmincome,f_income,f_confirmratio ,f_oritradefare,f_oritafare,f_oribackfare, f_oriotherfare1,f_oribreachfare,c_othertradeacco,c_outbusinflag,f_bac kfareagio,c_shareclass,c_bourseflag,c_subfundmethod, f_returnfare,f_punishratio,c_sharetype,d_outputdate,d_reqoutputdate,f _profitbalance4agt,f_profitbalance4fund,c_liqbatchno, f_balance,c_adjustcause,c_requestendflag,c_exceedflag,f_protectbalanc e, c_acceptmode,c_agencyno,c_auditflag,c_bankno,c_bonustype, c_broker,c_childnetno,c_cityno,c_combcode,c_custno, c_forceredemptiontype,c_freezecause,c_freezeno,c_fundacco,c_fundmetho d,c_improperredeem,c_maintradeacco,c_memo, c_operator,c_oricserialno,c_orifundcode,c_orirequestno,c_otheracco,c_ otheragency,c_othercode,c_othernetno,c_othershare, c_protocolno,c_rationpurpose,c_rationserialno,c_rationterm,c_rationti meunit,c_rationtype,c_rationvariety,c_reqtradeacco, c_requestno,c_specialcode,c_tacode,c_taflag,c_tenantid,c_trademethod, c_transfarecause,d_factdate,d_freezeenddate, d_hopedate,d_originaldate,d_protocolbegindate,d_protocolenddate,d_reg istdate,d_requestdate,d_requesttime,f_agio, f_chshare,f_deductmngfare,f_oriagio,f_oribackfareagio,f_otherprice,f_ price,f_rationnum,f_rshares_ch,f_shares, l_rationdate,l_rationfrequency,c_chkstatus,c_specialrequestflag,d_dat e,f_failedbalance,f_failedshares, f_reqrdmbalance,l_reqserialno) select/*+ use_hash(ct r) full(ct) full(r) parallel(4) */ ct.c_businflag,ct.d_cdate,ct.c_cserialno,ct.c_netno,ct.c_tradeacco,ct .c_fundcode,ct.f_confirmbalance,ct.f_confirmshares, ct.f_tradefare,ct.f_tafare,ct.f_stamptax,ct.f_backfare,ct.f_otherfare 1,ct.f_breachfare,ct.f_profitbalance,ct.f_totalfare, ct.f_tradefare4agt,ct.f_tradefare4fund,ct.f_tafare4agt,ct.f_tafare4fu nd,ct.f_backfare4agt,ct.f_backfare4fund,ct.f_otherfare14agt, ct.f_otherfare14fund,ct.f_breachfare4agt,ct.f_breachfare4fund,ct.f_in terest,ct.f_interestshare,ct.f_interesttax,ct.f_netvalue, ct.f_frozenbalance,ct.f_unfrozenbalance,ct.c_status,ct.c_cause,ct.c_c usttype,ct.f_chincome,ct.f_confirmincome,ct.f_income, ct.f_confirmratio,ct.f_oritradefare,ct.f_oritafare,ct.f_oribackfare,c t.f_oriotherfare1,ct.f_oribreachfare,ct.c_othertradeacco, ct.c_outbusinflag,ct.f_backfareagio,ct.c_shareclass,ct.c_bourseflag,c t.c_subfundmethod,ct.f_returnfare,ct.f_punishratio, ct.c_sharetype,ct.d_outputdate,ct.d_reqoutputdate,ct.f_profitbalance4 agt,ct.f_profitbalance4fund,ct.c_liqbatchno, ct.f_balance,ct.c_adjustcause,ct.c_requestendflag,ct.c_exceedflag,ct. f_protectbalance, r.c_acceptmode, case when (ct.c_businflag = '05' and r.c_businflag = '04') or ct.c_businflag = '15' then r.c_otheragency when ct.c_businflag = '06' and r.c_businflag = '05' or ct.c_businflag = '05' and r.c_businflag = '06' then 'TA0' else r.c_agencyno end c_agencyno, '0', case when ct.c_businflag = '16' then '' else r.c_bankno end c_bankno, r.c_bonustype,r.c_broker,r.c_childnetno,r.c_cityno,r.c_combcode, case when ct.c_businflag = '15' then r.c_otheracco else r.c_fundacco end c_custno, r.c_forceredemptiontype,r.c_freezecause,r.c_freezeno, case when ct.c_businflag = '15' then r.c_otheracco else r.c_fundacco end, r.c_fundmethod,r.c_improperredeem, '' c_maintradeacco, r.c_memo,r.c_operator, case when ct.c_businflag = '05' and r.c_businflag = '06' then '' else r.c_oricserialno end c_oricserialno, '' c_orifundcode, r.c_orirequestno, case when ct.c_businflag = '06' or ct.c_businflag = '05' or ct.c_businflag = '21' or ct.c_businflag = '15' or (ct.c_businflag = '22' and CONCAT(trim(r.c_otheracco),' ') = ' ') then r.c_fundacco else r.c_otheracco end c_otheracco, case when (ct.c_businflag = '06' and r.c_businflag = '06') or (ct.c_businflag = '05' and r.c_businflag = '05') then 'TA0' when (ct.c_businflag = '06' and r.c_businflag = '05') or (ct.c_businflag = '05' and r.c_businflag = '04') or (ct.c_businflag = '05' and r.c_businflag = '06') or ct.c_businflag = '21' or ct.c_businflag = '15' then r.c_agencyno else r.c_otheragency end c_otheragency, case when ct.c_businflag = '16' or ct.c_businflag = '06' or ct.c_businflag = '05' then r.c_fundcode else r.c_othercode end c_othercode, case when (ct.c_businflag = '06' and r.c_businflag = '06' and r.c_status = '1') then r.c_agencyno when ct.c_businflag = '16' or (ct.c_businflag = '06' and r.c_businflag = '05') or (ct.c_businflag = '05' and r.c_businflag = '06') or (ct.c_businflag = '05' and r.c_businflag = '04') or ct.c_businflag = '21' or ct.c_businflag = '15' then r.c_netno else r.c_othernetno end c_othernetno, case when ct.c_businflag = '16' or ct.c_businflag = '06' then r.c_sharetype else r.c_othershare end c_othershare, r.c_protocolno,r.c_rationpurpose,r.c_rationserialno,r.c_rationterm,r. c_rationtimeunit, r.c_rationtype,r.c_rationvariety, case when (ct.c_businflag = '06' and r.c_businflag = '05') or ct.c_businflag = '21' or ct.c_businflag = '15' then r.c_othertradeacco else r.c_reqtradeacco end c_reqtradeacco, r.c_requestno,r.c_specialcode,r.c_tacode, case when (ct.c_businflag = '06' and r.c_businflag = '05') or (ct.c_businflag = '05' and r.c_businflag = '06') then '1' else r.c_taflag end, r.c_tenantid, r.c_trademethod,r.c_transfarecause,r.d_factdate,r.d_freezeenddate,r.d _hopedate, case when ct.c_businflag = '05' and r.c_businflag = '06' then 0 else r.d_originaldate end d_originaldate, r.d_protocolbegindate, r.d_protocolenddate, case when ct.c_businflag = '04' or ct.c_businflag = '05' or ct.c_businflag = '06' then ct.d_reqoutputdate else r.d_registdate end d_registdate, case when (ct.c_businflag = '15' and r.c_status = '3') then r.d_requestdate - 10000000 else r.d_requestdate end d_requestdate, r.d_requesttime,r.f_agio, 0.0 f_chshare, 0.0 f_deductmngfare,r.f_oriagio, 0.0 f_oribackfareagio,r.f_otherprice, case when ct.c_businflag = '16' and r.f_otherprice = 0 then ct.f_netvalue when ct.c_businflag = '16' and r.f_otherprice != 0 then r.f_otherprice else r.f_price end f_price, r.f_rationnum,0.0 f_rshares_ch,r.f_shares,r.l_rationdate,r.l_rationfr equency, r.c_chkstatus,r.c_specialrequestflag,r.d_date,r.f_f ailedbalance,r.f_failedshares, r.f_reqrdmbalance,r.l_reqserialno from ta_tconfirm_tmp ct,ta_trequest_tmp r where ct.l_reqserialno = r.l_reqserialno and ct.c_tacode = r.c_tacode and ct.c_tenantid = r.c_tenantid and r.c_tenantid = '*' and ( r.c_tacode='F6' ) 原理 SQL 在 CPU, I/O 和集群等待上花费的时间占其数据库时间的 67%。这部分数据库时间可通过 SQL 优化指导进行改善。请查看下面给出的数据和 ASH 报告以进一步改善性能。 原理 此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL执行占 0%, Java 执行占 0%。 原理 SQL_ID 为 "cnzuj8k8yp0sb" 的 SQL 语句执行了 2 次, 每次执行平均用时 599 秒。 原理 该语句的执行至少有一次是并行方式。 原理 在分析期间, 此 SQL 语句至少利用了 2 个不同的执行计划。建议案 5: SQL 优化
估计的收益为 .13 个活动会话, 占总活动的 4.62\%。 ------------------------------- 操作 研究 DELETE 语句 (SQL_ID 为 "fc3cwb0uhd81d"), 确定是否可以改善性能。可以利用此 SQL_ID 的 ASH 报告来补充此处给出的信息。 相关对象 SQL_ID 为 fc3cwb0uhd81d 的 SQL 语句。 delete/*+ full(t) parallel(t 4) */from ta_trequest_tmp t where ( c_tacode='F6' ) and c_tenantid = '*' 原理 SQL 在 CPU, I/O 和集群等待上花费的时间只占其数据库时间的 11%。因此, SQL 优化指导不适用于这种情况。请查看 SQL 的性能数据以找出可能的改进方法。 原理 此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL执行占 0%, Java 执行占 0%。 原理 SQL_ID 为 "fc3cwb0uhd81d" 的 SQL 语句执行了 2 次, 每次执行平均用时 467 秒。 原理 该语句的执行至少有一次是并行方式。 原理 等待事件 "log buffer space" (在等待类 "Configuration" 中) 消耗了数据库时间的 81% (该数据库时间为处理具有 SQL_ID "fc3cwb0uhd81d" 的 SQL 语句时所用的时间)。 查找结果 3: 重做日志缓冲区不够大受影响的是 .76 个活动会话, 占总活动的 27.02\%。 --这就不是很正确了，主要是I/O慢，log_buffer都400多M了-------------------------------等待重做日志缓冲区空间消耗了大量数据库时间。建议案 1: 主机配置
估计的收益为 .76 个活动会话, 占总活动的 27.02\%。 -------------------------------- 操作 研究改善对联机重做日志文件的 I/O 性能的可能性。 原理 对联机重做日志文件执行写入的平均大小为 2305 K, 每次写入的平均时间为 34 毫秒。导致查找结果的故障现象:
------------ 等待类 "配置" 消耗了大量数据库时间。 受影响的是 .78 个活动会话, 占总活动的 27.49\%。 查找结果 4: SGA 不够大受影响的是 .65 个活动会话, 占总活动的 23.02\%。-------------------------------SGA 大小不合适, 导致附加 I/O 或硬语法分析。分析期间, 参数 "sga_target" 的值为 "71680 M"。建议案 1: 数据库配置
估计的收益为 .64 个活动会话, 占总活动的 22.6\%。 ------------------------------- 操作 通过将参数 "sga_target" 设置为 112000 M, 增加 SGA 的大小。导致查找结果的故障现象:
------------等待类 "用户 I/O" 消耗了大量数据库时间。 受影响的是 1.1 个活动会话, 占总活动的 38.9\%。 查找结果 5: 提交和回退受影响的是 .12 个活动会话, 占总活动的 4.24\%。------------------------------在执行 COMMIT 和 ROLLBACK 操作时, 等待 "日志文件同步" 事件消耗了大量数据库时间。建议案 1: 主机配置
估计的收益为 .12 个活动会话, 占总活动的 4.24\%。 ------------------------------- 操作 研究改善对联机重做日志文件的 I/O 性能的可能性。 原理 对联机重做日志文件执行写入的平均大小为 2305 K, 每次写入的平均时间为 34 毫秒。 原理 重做日志文件上的总 I/O 吞吐量的读取为每秒 0 K, 写入为每秒 13 M。 原理 重做日志 I/O 吞吐量由以下部分构成: RMAN 和恢复占 0%, 日志写进程占 100%, 归档程序占 0%, 流 AQ 占 0%, 所有其他活动占 0%。导致查找结果的故障现象:
------------ 等待类 "提交" 消耗了大量数据库时间。 受影响的是 .12 个活动会话, 占总活动的 4.24\%。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~附加信息
----各种信息
----等待类 "应用程序" 并未消耗大量数据库时间。等待类 "并发" 并未消耗大量数据库时间。CPU 不是此实例的瓶颈。等待类 "网络" 并未消耗大量数据库时间。会话连接和断开连接的调用并未消耗大量数据库时间。对 SQL 语句的硬语法分析并未消耗大量数据库时间。