zoukankan      html  css  js  c++  java
  • 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 语句的硬语法分析并未消耗大量数据库时间。

  • 相关阅读:
    python学习之strip()
    python学习之find()
    Linux scp命令
    TensorFlow学习笔记4——变量共享
    TensorFlow学习笔记 速记1——tf.nn.dropout
    TensorFlow学习笔记 补充2—— 生成特殊张量
    sublime test3 安装及配置
    TensorFlow学习笔记3——Placeholders and feed_dict
    TensorFlow学习笔记 补充1——InteractiveSession
    TensorFlow学习笔记2——数据类型及简单运算
  • 原文地址:https://www.cnblogs.com/zhjh256/p/10083590.html
Copyright © 2011-2022 走看看