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

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

0

积分

1

好友

4

主题
1#
发表于 2013-1-11 10:47:54 | 查看: 4792| 回复: 4
客户的oracle环境:11.2.0.1,redhat 64位。
故障现象是每隔十来天就要重启下,不重启IO会严重等待(db seauence/scattered read,read by other session),重启马上正常了,重启前后业务都是一样的。杀进程不能解决,flush data cache不行。主机的iostat重启后维持在30%左右,出问题时就一直100%。
本人是应用开发方,客户基本上没有DBA,附上故障时/重启后的awr报告,简单比较下能看到sga/pga大小明显不同,其它的我就不懂了。麻烦大家帮助分析一下。alert中没有可疑的内部错误等情况。

20130110_awr_09am_10am_IO堵塞.html

488.1 KB, 下载次数: 700

堵塞时的AWR

20130110_awr_14pm_15pm_正常.html

438.6 KB, 下载次数: 695

重启后的AWR

2#
发表于 2013-1-11 11:02:24
IO 阻塞时 每秒物理读 1769 * 8k = 13M
Physical reads:         1,769.5         141.0                  
Physical writes:         16.2         1.3                  

IO 正常时 每秒物理读 55 * 8k = 0.4M

Physical reads:         55.1         4.3                  
Physical writes:         11.1         0.9                  

IO阻塞时的TOP 物理读SQL

Physical Reads        Executions        Reads per Exec        %Total        Elapsed Time (s)        %CPU        %IO         SQL Id        SQL Module        SQL Text
2,823,701        8        352,962.63        43.78        84,776.28        0.71        99.11        bmt4znqvbgcx7         ????????        begin if :p_action = '??' then...
1,452,539        9        161,393.22        22.52        49,418.19        0.71        99.04        04dn798sjfkxm         ????????\????????\????????????        select distinct ??, ??, ??, ??...
635,685        11        57,789.55        9.86        23,014.02        0.68        99.29        5fgfs1548rar9         ????????        select distinct ??, ??, ??, ??...
635,559        6        105,926.50        9.85        10,496.34        0.73        98.61        5mykk74xr35dd         ????????        select distinct ??, ??, ??, ??...
343,188        18        19,066.00        5.32        4,891.77        2.23        97.30        7jk60jabybkg3         ????????        SELECT :"SYS_B_0" ChildCount, ...
249,802        1,816,246        0.14        3.87        55,413.92        0.52        99.46        8b5c0u498ufmg         BA_java        SELECT T.F_LEVEL_ID FROM F_STO...
191,356        7        27,336.57        2.97        17,642.81        0.15        99.89        0xxbtat38cu2m         ????????\????????\??????????????        begin /* p_????: INTEGER = ; p...



IO正常时的TOP 物理读SQL:

Physical Reads        Executions        Reads per Exec        %Total        Elapsed Time (s)        %CPU        %IO         SQL Id        SQL Module        SQL Text
7,312        2,995,674        0.00        3.75        317.52        93.23        7.14        8b5c0u498ufmg         kwappserver.exe        SELECT T.F_LEVEL_ID FROM F_STO...
1,230        4,915        0.25        0.63        16.59        30.31        70.36        d60w0vs5t8b9f         kwappserver.exe        begin Pkg_CellTree.DoCellTreeV...
1,139        16,722        0.07        0.58        21.85        54.25        43.91        48kuxbj2zcsj0         kwappserver.exe        begin pkg_celltree.CTLog(:p1, ...
1,023        17        60.18        0.52        148.66        96.32        3.61        3z7awvju0qa5u         ????????        begin if :p_action = '??' then...
864        17        50.82        0.44        148.21        96.42        3.50        0k30kvsqp2atq         ????????        INSERT INTO TT_BILL_QUERY (ID,...
420        4,538        0.09        0.22        4.09        24.61        74.93        4m7m0t6fjcs5x                 update seq$ set increment$=:2,...



结论:

1. 物理Io 读能力极差,和笔记本差不多
2. Io阻塞时对比IO正常时 运行了更多 消耗Io的不良SQL


回复 只看该作者 道具 举报

3#
发表于 2013-1-11 11:14:12
你这个库是数据分析库吧,第一个top sql(bmt4znqvbgcx7)都执行了10,597秒,还有好几个这样的sql,执行的不多,但把库拖垮了,个人感觉要进行sql优化才行

回复 只看该作者 道具 举报

4#
发表于 2013-1-11 11:20:53
刘大的分析有理

回复 只看该作者 道具 举报

5#
发表于 2013-1-11 14:12:30
Maclean Liu(刘相兵 发表于 2013-1-11 11:02
IO 阻塞时 每秒物理读 1769 * 8k = 13M
Physical reads:         1,769.5         141.0                  
Physical writes:         16.2         1.3 ...

刘大, 这是个OLTP+OLAP混合的业务DB,5块SAS硬盘做raid5,我对主机不了解,不知道繁忙时持续10多M的随机读取速度,是不是很慢,是不是意味着主机的存储很可能有问题?
还有个奇怪的地方,我又拉了今天9点到10点的数据,昨天出问题的相同时间段,业务是相似的,但今天DB很快。昨天占物理IO40%的那句SQL bmt4znqvbgcx7,昨天运行了8次,每次10597秒,物理读352,962块。今天它仍是最耗时的SQL,运行了18次,但每次只有29秒,物理读362块。而且gets是差不多的,每次2百万-3百万,也就是说这些昨天耗IO的SQL突然“变快”了。
不知道是不是遇到了oracle的bug,或是内存管理有问题?

20130111_awr_09pm_10pm_正常状态用于参照.html

451.44 KB, 下载次数: 670

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-11-16 06:49 , Processed in 0.049346 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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