8 积分	0 好友	0 主题

发消息

请各位帮忙解读一下AWR报告

1^#

发表于 2012-5-29 14:10:36 | 查看: 6054| 回复: 5

麻烦各位了，不好意思
Total System Global Area
943718400 bytes

Fixed Size
1300116 bytes

Variable Size

654313836 bytes

Database Buffers
281018368 bytes

Redo Buffers
7086080 bytes

awr_12_0529_8_9.rar

24.3 KB, 下载次数: 964

分享0

收藏0 回复只看该作者道具举报

ricky

2^#

发表于 2012-5-30 11:01:35

你收集的是早上8点到9点的，这个时候不是业务高峰期吧！
还是这段时间你的数据库发生了什么情况啊？
咋一看：‘Execute to Parse %:低《说明可能：这个值低说明sql重用率低。？什么导致sql重用率低啊？你去看看原因，是不是绑定变量啊，还是其他。
Parse CPU to Parse Elapsd %:是指sql语句的CPU时间与总体解析时间的比率, SQL总体解析时间包括CPU时间和wait时间，这个比率过低说明SQL Parse的wait时间远远大于CPU的 Parse时间不是很正常，可能有大量lib cache latch or shared pool latch。
Parse CPU to Parse Elapsd%过低一般是由于latch争用造成的，需要具体问题具体分析，经常伴随较高的latch free和enqueue等待事件。我看了你的AWR也木有这个事件啊！！我经验不足，嘻嘻，不好意思，深层看不见。

Soft Parse %:只是低一点点啦！
太低则需要调整应用使用绑定变量。

db file scattered read 你的等待事件比较明显
通常是由于full table scans或 index fast full scans。发生过多读操作的Segments可以在“Segments by Physical Reads”和 “SQL ordered by Reads”节中识别（在其它版本的报告中，可能是别的名称）。如果在OLTP应用中，不应该有过多的全扫描操作，而应使用选择性好的索引操作。

经验你查一下你系统中执行计划是全表扫描的sql。提出来看看是不是可以不用全表扫。

sql_id： ckrva9611bjst 和2sv2xdxsk6c35 这两个sql必然是全表扫。如果你的系统是OLAP。那这个正常。

回复只看该作者道具举报