Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

0

积分

0

好友

2

主题
1#
发表于 2013-7-26 08:56:31 | 查看: 3788| 回复: 6
最近收到的一份AWR,具体现象为系统反应慢。
我通过AWR看的话只能看出来下面几个问题:
1、应用SQL比较差,但是这部分修改需要有段时间。
2、5suwywh09n12u这条语句过长,拖垮系统。
所以我想是不是可以考虑以下几个方面:
1、修改5suwywh09n12u这个。
2、修改cursor share为force。
2、提高SGA,buffer和sharedpool设置最小值,然后禁止sharepool收缩。
不知道各位大神们有什么建议么?
awrrpt_2_18049_18052.rar (139.09 KB, 下载次数: 720)

2#
发表于 2013-7-26 10:51:31
我觉得
1.
                                 Begin        End               
Buffer Cache:         12,592M         14,240M       
Shared Pool Size:         7,824M         6,176M

shared        CCursor        667.49        498.02        -25.39
shared        KQR L PO        747.93        62.84        -91.60

这几个指标都可以证明在期间发生了shared pool和buffer cache的相互转化

建议:可以关闭sga自动管理或者设置最小值

2.
Hard parses:         3.60         0.43

每秒的硬解析不过才3.6次,没有必要设置force

3.
PGA Memory Advisory
3,151        1.00        2,014,555.78        310,593.91        87.00        0
3,781        1.20        2,014,555.78        15,029.66                99.00        0

能否把PGA稍微设置大一点?

4.
open_cursors        5000

5.
这个sql相当吓人啊
5suwywh09n12u

这个参数合适吗?

本人愚见,希望高手指出不足

回复 只看该作者 道具 举报

3#
发表于 2013-7-26 11:00:23
chaicsd14 发表于 2013-7-26 10:51
我觉得
1.
                                 Begin        End               

shared pool和buffer cache的抖动我认为应该是5suwywh09n12u引发的

回复 只看该作者 道具 举报

4#
发表于 2013-7-26 11:04:20
Event        Waits        Time(s)        Avg Wait(ms)        % Total Call Time        Wait Class
row cache lock         54,392         129,530         2,381         42.8        Concurrency
latch: row cache objects         1,808,208         116,148         64         38.4        Concurrency
cursor: pin S wait on X         2,868,983         28,202         10         9.3        Concurrency
library cache pin         4,144         9,795         2,364         3.2        Concurrency
CPU time                  7,991                  2.6         


大量解析类等待


        Begin        End               
Buffer Cache:         12,592M         14,240M        Std Block Size:         8K
Shared Pool Size:         7,824M         6,176M        Log Buffer:         14,304K

shared pool发生了 7824=》 6176的收缩

latch row cache objects 主要体现在kqrbip          ==》background release instance lock and invalidate parent object




row cache objects        kqrbip        0        10,822        32,025
row cache objects        kqreqd: reget        0        2,631        12,610
row cache objects        kqrpre: find obj        0        1,173        30,024
row cache objects        kqrso        0        870        15,993
row cache objects        kqreqd        0        541        15,882
row cache objects        kqrigt        0        281        9,409



SGA: MMAN sleep for component shrink        6        83.33        0        8        0.00

发生了约6次shrink


主要还是MMAN shrink shared pool 导致的row cache lock 及其他效应等待

回复 只看该作者 道具 举报

5#
发表于 2013-7-26 11:13:52
恩,谢谢刘大回复

回复 只看该作者 道具 举报

6#
发表于 2013-7-26 11:36:41
主要还是sga内存自动管理的问题,其他都是次要的。

回复 只看该作者 道具 举报

7#
发表于 2013-7-26 12:41:31
Maclean Liu(刘相兵 发表于 2013-7-26 11:04
Event        Waits        Time(s)        Avg Wait(ms)        % Total Call Time        Wait Class
row cache lock         54,392         129,530         2,381 ...

这个kqrbip 具体是什么作用啊

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-6-18 03:02 , Processed in 0.052079 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569