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

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

0

积分

1

好友

7

主题
1#
发表于 2013-12-2 11:50:01 | 查看: 5275| 回复: 4
各位上午好:

环境:
OS: RHEL 5.8 X86
DB:11.2.0.3.7
盘阵:IBM DS5020  做的raid10
单实例ASM

12月1日上午10点数据库负载突然暴涨,应用部门确认过都是日常操作,没有特别的操作。当时系统CPU、内存都表现正常,根据awr报告也显示,CPU消耗不高,top等待事件都指向IO这块,因为存储之前出现过问题,后来恢复,所以怀疑与存储有关,但是系统日志没有和上次一样报存储错误。附件是问题时间段,数据库正常状态和问题状态AWR以及问题时间段系统日志。

请各位帮助分析,多谢。

问题日志.zip

454.47 KB, 下载次数: 2116

2#
发表于 2013-12-2 14:56:34
正常情况下的报告,以下部分
Wait Event Histogram Detail (64 msec to 2 sec)
Wait Event Histogram Detail (4 sec to 2 min)
可以看到 log file parallel write  ,这是不应该的,说明平时IO也是有问题的。在非正常时段,direct path read 变多,并且你们用的是单实例ASM,所以IO性能变差非常明显。

禁用direct path read,cache相关的表,调优SQL。

并且建议你们测试一下你们的存储,看看IOPS,MBPS的极限是多少,是否正常。

回复 只看该作者 道具 举报

3#
发表于 2013-12-2 18:48:50
table scans (direct read)        135        0.02        0.00
table scans (long tables)        1        0.00        0.00


vs

table scans (direct read)        523        0.07        0.02
table scans (long tables)        14        0.00        0.00


Total Disk Reads: 17,619,611

vs
Total Disk Reads: 55,710,607









Physical Reads        Executions        Reads per Exec        %Total        Elapsed Time (s)        %CPU        %IO         SQL Id        SQL Module        SQL Text
5,946,972        44        135,158.45        33.75        469.66        4.44        95.69        gkz1gdwyk1ubw         w3wp.exe        SELECT T.BILL_STATE, T.WAREHOU...
3,330,360        24        138,765.00        18.90        260.68        6.62        93.45        dn8w89jx7k958         oracle@db-bi-218 (TNS V1-V3)        SELECT /*+ OPAQUE_TRANSFORM */...
2,708,020        20        135,401.00        15.37        199.84        11.05        89.07        8mqu64chw8cmd         WZOLService.WindowsService.exe        Select Z.Mopocsalesorderbillid...
2,296,009        17        135,059.35        13.03        163.79        11.48        88.60        f2mwz1zyzc4uv         WZOLService.WindowsService.exe        Select Z.Mopocsalesorderbillid...



vs

Physical Reads        Executions        Reads per Exec        %Total        Elapsed Time (s)        %CPU        %IO         SQL Id        SQL Module        SQL Text
31,455,378        282        111,543.89        56.46        328,750.26        0.05        49.81        gkz1gdwyk1ubw         w3wp.exe        SELECT T.BILL_STATE, T.WAREHOU...
11,415,396        130        87,810.74        20.49        122,431.35        0.11        49.46        c412fnd0cdmc0         w3wp.exe        SELECT COUNT(1) FROM IF_SALESO...
7,698,555        67        114,903.81        13.82        52,739.71        0.07        56.82        837svcmjhsf06         WZOLService.WindowsService.exe        SELECT SALESORDER_BILLDETAIL.M...


回复 只看该作者 道具 举报

4#
发表于 2013-12-2 18:54:00
gkz1gdwyk1ubw  Executions 执行次数 44 到 282        次
c412fnd0cdmc0         执行次数  unknown 到 130次 ,这2个SQL 在问题快照中占了70%的物理读

gkz1gdwyk1ubw 属于 w3wp.exe
SQL 为:SELECT T.BILL_STATE, T.WAREHOUSEID, T.OWNERID FROM SALESORDER_BILL T WHERE T.MOPOCSALESORDERBILLID = :B1

MOPOCSALESORDERBILLID  的distinct 有多少 ? 很有可能执行计划有误 或者索引不可用引起了该问题
如果是 网页应用的话  调用的次数 是视乎用户界面上的操作

回复 只看该作者 道具 举报

5#
发表于 2013-12-5 23:10:25
继续学习

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-12-21 10:08 , Processed in 0.052555 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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