用户反映数据库响应较慢的AWR分析问题

tianshiguodong

用户反映在AWR采样时段业务人员反映数据库系统较慢，用户查询相同语句也较平时慢，麻烦大家给分析、分析，看看是不是有性能问题。
我大概的分析结果如下：
1.大概看了下，系统负载不高，平均响应时间也较小，说明性能应该不是很差；
2.主要等待为CPU time，这个是不是花费在数据库上的CPU等待时间，但不知道这个等待主要从哪块去分析？；
3.其中两个指标Execute to Parse %:  -7.62    以及  Parse CPU to Parse Elapsd %: 6.48较低，都说明系统中存在大量的解析从而消耗了大量CPU，从后面可以看到应该大部分为软解析,latch: library cache等待应该值的关注，但这个事件在top5中比较靠后且只占总等待的10%，是不是不应该关注此事件？或者说一定程度上反映了shared pool过小？
4.log file sync这个等待Avg Wait(ms)为115，这个时间是不是比较长，如果比较长那么是说明了commit过于频繁(每秒redo生成量也不大)?还是redo写性能有问题(从AWR中能看出redo的写性能吗)?
由于是第1次看AWR，所以对于很多指标没有量化的概念，附上业务高峰时1小时AWR报告。
AWR Rpt - orcl Snap 8277 thru 8278.html (279.75 KB, 下载次数: 820)

2013-2-16 14:52 上传

点击文件名下载附件
AWR

Maclean Liu(刘相兵

        Snap Id        Snap Time        Sessions        Cursors/Session
Begin Snap:        8277        04-Feb-13 10:00:43        383         3.1
End Snap:        8278        04-Feb-13 11:00:49        395         2.8
Elapsed:                  60.11 (mins)                  
DB Time:                  93.61 (mins)                  

就DB 看 负载并不高， 当然负载 和 响应时间是2回事

Event        Waits        Time(s)        Avg Wait(ms)        % Total Call Time        Wait Class
CPU time                  1,751                  31.2         
db file scattered read         791,033         1,046         1         18.6        User I/O
log file sync         9,023         1,038         115         18.5        Commit
latch: library cache         2,086         612         293         10.9        Concurrency
db file sequential read         37,635         574         15         10.2        User I/O


就等待事件来看 IO 是有问题的， 因为用了文件系统 缓存 所以读db file scattered read 的响应时间还可以，但是写 就很差了 ， 写redo 日志平均等待60ms， user commit 并不频繁 每秒才2次

log file parallel write        8,525        0.00        515        60        0.75


Statistic Name        Time (s)        % of DB Time
sql execute elapsed time        3,452.29        61.46
DB CPU        1,750.70        31.17
parse time elapsed        668.82        11.91
hard parse elapsed time        312.22        5.56

解析SQL花了11%的 DB TIME， 其中一半是硬解析

Logical reads:         20,896.59         6,601.58   逻辑读 每秒163MB 并不算多


我建议你先查一下 写 IO为什么这么差

tianshiguodong

Maclean Liu(刘相兵 发表于 2013-2-16 16:19
Snap Id        Snap Time        Sessions        Cursors/Session
Begin Snap:        8277        04-Feb-13 10:00:43        383         3.1
End Snap:        8 ...

非常感谢ML能够这么快速的回复，的确这个数据库没有挂磁阵，只安装在本地的4块硬盘上，估计3块raid 5+1块热备，下次去客户那做下磁盘I/O测试。