oracle addm报告

可通过@?/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.90
2 顶级 SQL 语句 .99 | 34.895
3 重做日志缓冲区不够大 .76 | 27.021
4 SGA 不够大 .65 | 23.021
5 提交和回退 .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 和集群等待上花费的时间占其数据库时间的 6
7%。这部分数据库时间可通过 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 语句的硬语法分析并未消耗大量数据库时间。

原文地址:https://www.cnblogs.com/zhjh256/p/10083590.html