AWR，请帮忙分析
本帖最后由 Fung920 于 2014-4-2 16:26 编辑客户一个小系统在巡检的时候发现某个时间点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
建议对这三条语句进行调整优化。
看看这几个sql的执行计划吧，感觉全表扫描可能性比较大 。 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硬解析了 1. 某个时间点cpu突然升高，建议根据时间点范围，看看ash信息，因为你的awr可能被平均掉了
2. 从现在的awr报告中看，sql的执行效率低下，引起热块争用可能是导致cpu 突然升高的根本原因（具体最好结合ash分析）
页:
[1]