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

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

0

积分

1

好友

3

主题
1#
发表于 2013-3-1 10:27:46 | 查看: 4749| 回复: 9
最近一段时间数据库在高峰时段10-11点左右,就会出现大量用户反映很慢,使用VNC或SSH登陆上系统发现也的确如此。在操作系统层面输入命令都 很卡。平时间使用TOP命令发现系统的负载也高得离谱。

具体如下:
[root@wdfcmp ~]# top
top - 10:22:46 up 51 days, 12:34,  4 users,  load average: 1241.44, 1242.85, 1242.20
Tasks: 6767 total,   4 running, 6762 sleeping,   0 stopped,   1 zombie
Cpu(s):  4.3%us,  0.8%sy,  0.0%ni, 92.6%id,  2.3%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  32467616k total, 32433172k used,    34444k free,    37152k buffers
Swap: 34963448k total,   299728k used, 34663720k free, 26874540k cached

现在自己处理这个问题有这几个思路:

1、调整业务报表,清理一些资源消耗大,没有优化好的SQL。

2、准备从内存在着手,增大内存,增加SGA

现附上最近高峰时段的2个AWR报表和一个3天的报表,请各位帮我分析一下,系统现在的问题在哪里。瓶颈有哪些,从哪几方面着手去改善。感谢了。。。

awrrpt_1_10317_10318.html

363.83 KB, 下载次数: 769

高峰时段报表

三天的报表.html

418.13 KB, 下载次数: 702

高峰时段报表.html

357.23 KB, 下载次数: 707

10#
发表于 2013-3-2 14:31:52
Segments by Physical Reads:
TORDJHBODY
TSALPLUDETAIL201302
Segments by Row Lock Waits:
PK_TSTKJXCRPTSOUCE201302

io问题应会是根源

回复 只看该作者 道具 举报

9#
发表于 2013-3-1 18:12:38
从Top 5 Timed Events
buffer busy waits
db file sequential read
可知 大量的物理读
从 SQL Statistics 可知
TOP SQL 占的比重很大  但是执行次数不是很多 可见COST 很高
从Time Model Statistics 可知DB CPU 很低
所以I/O很差是可能是由于大量的物理读引起的

先优化下TOP SQL  再观察下吧

回复 只看该作者 道具 举报

8#
发表于 2013-3-1 14:09:06
xiazhangch 发表于 2013-3-1 13:17
另咨询个问题,我现在的undo表空间的大小已经达到70G了,可是undo的使用率还是一直保持在96甚至99%…左右 ...

undo表空间 不是光看使用率的

你至少 该分清楚 高峰时段 哪些是 active 、expired、unexpired undo extent

回复 只看该作者 道具 举报

7#
发表于 2013-3-1 13:17:07
Maclean Liu(刘相兵 发表于 2013-3-1 13:06
高峰时段

log file parallel write 110ms

另咨询个问题,我现在的undo表空间的大小已经达到70G了,可是undo的使用率还是一直保持在96甚至99%…左右,这对性能有没影响。还需要增加undo大小吗?

回复 只看该作者 道具 举报

6#
发表于 2013-3-1 13:14:18
Maclean Liu(刘相兵 发表于 2013-3-1 13:06
高峰时段

log file parallel write 110ms

谢谢刘大指点...

回复 只看该作者 道具 举报

5#
发表于 2013-3-1 13:06:37
Event
Waits
Time(s)
Avg Wait(ms)
% Total Call Time
Wait Class
buffer busy waits
45,481
43,087
947
39.9
Concurrency
db file sequential read
469,438
21,606
46
20.0
User I/O
log file switch (checkpoint incomplete)
27,832
16,958
609
15.7
Configuration
log file sync
93,087
8,088
87
7.5
Commit
CPU time
7,572
7.0



高峰时段

log file parallel write 110ms
log file switch (checkpoint incomplete)        27,832        53        16,958        609        1.6

日志写的IO 太差了, 方向在 诊断 写IO 上, redo量一大   写redo的 响应就极慢。

回复 只看该作者 道具 举报

4#
发表于 2013-3-1 11:50:50
自贴自顶

回复 只看该作者 道具 举报

3#
发表于 2013-3-1 10:52:45
继续顶顶。

回复 只看该作者 道具 举报

2#
发表于 2013-3-1 10:29:23
请各位帮忙分析一下。。谢谢

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-11-16 11:35 , Processed in 0.059719 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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