AWR，请帮忙分析

Fung920

客户一个小系统在巡检的时候发现某个时间点CPU突然升高，客户需要对此有个合理解析。正常时候空闲98%，最高使用率到88%。以下为我写的分析，请问哪里有错，或者哪里有需要补充的地方？
1.        数据库总体业务量

Snap Id        Snap Time        Sessions        Cursors/Session
Begin Snap:        44017        02-Apr-14 12:00:15        81        8.0
End Snap:        44018        02-Apr-14 13:00:51        81        8.0
Elapsed:                 60.61 (mins)                  
DB Time:                 29.85 (mins)                  
抽样在一个小时内，平均每个session打开的cursors为8，表示数据库并发度不高。数据库总消耗时间为29.85mins，29.85/60.61=0.5，表明在这段时间内数据库对系统资源消耗很小，是一个负载很轻的数据库。
2.        TOP 5等待事件
Event        Waits        Time(s)        Avg Wait(ms)        % Total Call Time        Wait Class
CPU time                 863                 48.2         
read by other session        1,581,895        589        0        32.9        User I/O
db file scattered read        595,540        269        0        15.0        User I/O
db file sequential read        375,156        51        0        2.8        User I/O
log file parallel write        4,650        6        1        .3        System I/O
        从top 5等待事件中，平均等待事件都比较小，但read by other session及log file parallel write出现在top事件中需要关注。log file parallel write表示日志文件可能存在IO竞争。
而read by other session表示多个session同时需要把数据加载到data buffer中，表明数据存在热块。下图表示热块所在的对象(szcsk.tax_return)：
Owner        Tablespace Name        Object Name        Subobject Name        Obj. Type        Logical Reads        %Total
SZCSK        CSK_DATA_TBS1        TAX_RETURN                 TABLE        29,069,760        50.63
SZCSK        CSK_DATA_TBS1        RESEND                 TABLE        8,495,696        14.80
SZCSK        CSK_DATA_TBS1        BATCH_INST                 TABLE        6,743,760        11.74
SZCSK        CSK_DATA_TBS1        CONSOLE                 TABLE        5,796,880        10.10
SZCSK        CSK_DATA_TBS1        COL_CHECK_ACCOUNT                 TABLE        4,464,240        7.77
同时在AWR中发现以下操作跟此对象有关：
cy9nh79rnaz5y        update tax_return set State=:b0, Batch_No=:b1, Actual_Total=:b2 where No=:b3
3.        硬解析
Statistic Name        Time (s)        % of DB Time
sql execute elapsed time        1,758.60        98.19
DB CPU        863.38        48.20
parse time elapsed        20.63        1.15
hard parse elapsed time        17.86        1.00
connection management call elapsed time        4.69        0.26
PL/SQL execution elapsed time        0.28        0.02
repeated bind elapsed time        0.07        0.00
sequence load elapsed time        0.04        0.00
PL/SQL compilation elapsed time        0.02        0.00
DB time        1,791.09         
background elapsed time        22.72         
background cpu time        14.74         
        从AWR统计信息看，有一定比例的硬解析，可以尝试减少硬解析。
4.        TOP SQL
TOP SQL中，不论执行时间或者CPU消耗CPU时间来看，以下两个SQL都有问题，而且逻辑读也比其他的SQL要多。
b3a94qmd5jxjd        select count(console0_.ID) as col_0_0_ from Console console0_ where 1=1 and console0_.TIMESTAMP>=to_date(:1, 'yyyy-mm-dd HH24:mi:ss') and console0_.TIMESTAMP<=to_date(:2, 'yyyy-mm-dd HH24:mi:ss') order by console0_.ID desc
28br8k1w7t68c        select * from ( select console0_.ID as col_0_0_ from Console console0_ where 1=1 and console0_.TIMESTAMP>=to_date(:1, 'yyyy-mm-dd HH24:mi:ss') and console0_.TIMESTAMP<=to_date(:2, 'yyyy-mm-dd HH24:mi:ss') order by console0_.ID desc ) where rownum <= :3
5.        结论
针对提供的AWR发现，整个系统负载较轻，导致CPU升高的原因可能由以下三个SQL引起：
（1）
cy9nh79rnaz5y        update tax_return set State=:b0, Batch_No=:b1, Actual_Total=:b2 where No=:b3
（2）
b3a94qmd5jxjd        select count(console0_.ID) as col_0_0_ from Console console0_ where 1=1 and console0_.TIMESTAMP>=to_date(:1, 'yyyy-mm-dd HH24:mi:ss') and console0_.TIMESTAMP<=to_date(:2, 'yyyy-mm-dd HH24:mi:ss') order by console0_.ID desc
（3）
28br8k1w7t68c        select * from ( select console0_.ID as col_0_0_ from Console console0_ where 1=1 and console0_.TIMESTAMP>=to_date(:1, 'yyyy-mm-dd HH24:mi:ss') and console0_.TIMESTAMP<=to_date(:2, 'yyyy-mm-dd HH24:mi:ss') order by console0_.ID desc ) where rownum <= :3
建议对这三条语句进行调整优化。

ziyoo0830

看看这几个sql的执行计划吧，感觉全表扫描可能性比较大 。

yrg5101

10,240        1.00        2,748,383.94        1,355,063.33        67.00        0
12,288        1.20        2,748,383.94        448,483.48        86.00        0

看看pga还能增大点吗  还有 就是 优化sql  硬解析了

xifenfei

1. 某个时间点cpu突然升高，建议根据时间点范围，看看ash信息，因为你的awr可能被平均掉了
2. 从现在的awr报告中看，sql的执行效率低下，引起热块争用可能是导致cpu 突然升高的根本原因（具体最好结合ash分析）