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

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

0

积分

0

好友

6

主题
1#
发表于 2013-5-8 17:47:51 | 查看: 3667| 回复: 3
本帖最后由 tianshiguodong 于 2013-5-8 18:06 编辑

用户反映业务高峰时数据库响应较慢
library cache latch及shared pool latch比较严重,期间发生过SGA resize
看了下,造成latch的原因不可能是硬解析;可能与绑定变量有关,SGA resize对latch也有一定的加剧作用,如果是绑定变量造成的,那么从AWR中的sql by version count这里得到的sql准确么?
不知道我的简单分析是不是合理,请大家给看看

20130503_09_10.html

293.38 KB, 下载次数: 690

9点到10点

20130503_10_11.html

293.16 KB, 下载次数: 714

10点到11点

20130503_09_11.html

293.84 KB, 下载次数: 698

9点到11点

2#
发表于 2013-5-8 17:54:03
...........能不要这种无意义的标题吗?

回复 只看该作者 道具 举报

3#
发表于 2013-5-8 17:58:45
Maclean Liu(刘相兵 发表于 2013-5-8 17:54
...........能不要这种无意义的标题吗?

刚改过了,刘大帮给看看

回复 只看该作者 道具 举报

4#
发表于 2013-5-8 19:50:05
9点到10点:

shared        CCursor        342.51        419.19        22.39
shared        KGH: NO ACCESS        770.04        770.04        0.00
shared        PCursor        116.23        149.26        28.42
shared        free memory        557.60        568.06        1.88
shared        kglsim object batch        28.60                 -100.00
shared        library cache        77.88        93.26        19.75
shared        sql area        438.36        664.55        51.60

sql area 涨了200多MB ,  说明 还是有不少"新"SQL进入系统的

9点到10点 shared pool在涨, 之后又收缩


建议你关掉 auto sga , shared pool手动设置为2,224MB

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-11-16 12:43 , Processed in 0.049570 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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