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

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

0

积分

1

好友

6

主题
1#
发表于 2013-7-2 14:47:30 | 查看: 4208| 回复: 11
本帖最后由 SKYLINE.LIU 于 2013-7-3 15:28 编辑

主要等待事件为 read by other session与db file sequential read
平时gv$session中这两种等待事件数为30左右,hang机时这两种等待事件数各达到了360,220
由于本人水平有限在AWR中找不到不出突破点,希望各位帮忙分析分析~

以下为系统hang机前一小时的AWR报告
awrrpt_1_15494_15495.html
awrrpt_2_15494_15495.html

以下为系统hang时的AWR报告
awrrpt_1_15495_15496.html
awrrpt_1_15496_15497.html
awrrpt_2_15495_15496.html
awrrpt_2_15496_15497.html

增加日常运行AWR方便对比

附:
应用系统每隔20~30天就会突发hang机一次

hang机AWR.rar

299.13 KB, 下载次数: 1180

平时AWR.rar

92.05 KB, 下载次数: 1120

2#
发表于 2013-7-2 20:06:42
你这个hang和sga震荡有关(SGA: allocation forcing component growth)
hard parse很多,导致shared pool增长

回复 只看该作者 道具 举报

3#
发表于 2013-7-2 23:45:13
本帖最后由 SKYLINE.LIU 于 2013-7-3 09:33 编辑

sg震荡从AWR中可以看出来,但2楼说的 hard parse很多就不理解了。
Load Profile 中的hard parse小于10/s,应该是硬解析不敏感的,望指教~

回复 只看该作者 道具 举报

4#
发表于 2013-7-3 02:21:35
通过Top 5 event 可以看到
在hang 阶段,enq: HW - contention 暴增
enq: HW - contention 这个等待时间占了8%的dbtime,平均等待98650毫秒,98秒
11.1.0.6.0根据你的系统版本,推断是否为 bug?
当然我也觉的自己推测的很简陋,算是mark一下,等待看最后的结果

回复 只看该作者 道具 举报

5#
发表于 2013-7-3 09:31:53
enq: HW - contention 事件在系统中主要反映上传照片材料的等待事件
hang机之后反查照片材料上传表,发现当时的照片材料上传与平时持平。

个人觉得不是主要影响事件。

回复 只看该作者 道具 举报

6#
发表于 2013-7-3 11:01:37
从hang机的时间段看session从200暴增到600  你可以采集一下别的时间相同时段的awr放上来看看对比一下

回复 只看该作者 道具 举报

7#
发表于 2013-7-3 21:51:20
hang时的物理读写:

Physical reads:         5,157.2         1,503.7                  
Physical writes:         65.7         19.2         
physical read total IO requests        8,199,980        2,264.68        660.33
physical write total IO requests        222,607        61.48                17.93

平时的物理读写:

Physical reads:         2,730.4         843.2                  
Physical writes:         33.8         10.4                  
physical read total IO requests        3,203,964        900.68        278.15
physical write total IO requests        122,186        34.35        10.61

Iops 差了三倍, 主要体现在物理读上


回复 只看该作者 道具 举报

8#
发表于 2013-7-3 21:53:40

问题快照中:

Physical Reads        Executions        Reads per Exec        %Total        CPU Time (s)        Elapsed Time (s)         SQL Id        SQL Module        SQL Text
1,294,501        18        71,916.72        6.93        59.47        777.25        fy2psy6kfpd6z                 select ((select cast(max(OPERA...
1,164,508        2        582,254.00        6.24        83.19        960.20        06v3m2kw9m60y         JDBC Thin Client        select * from ( SELECT * FROM ...
1,158,918        2        579,459.00        6.21        79.06        892.13        0hbp8gktm7t1d         JDBC Thin Client        SELECT COUNT(*) as CT FROM ( S.


正常快照
Physical Reads        Executions        Reads per Exec        %Total        CPU Time (s)        Elapsed Time (s)         SQL Id        SQL Module        SQL Text
1,084,389        2        542,194.50        11.16        42.90        228.91        adsmud3xqtu0v         JDBC Thin Client        SELECT COUNT(*) as CT FROM ( S...
555,498        1,665        333.63        5.72        74.94        6022.89        fw5dncbpz9atf         JDBC Thin Client        SELECT COUNT(*) as CT from T_...
484,420        2        242,210.00        4.99        107.13        2192.45        bxyxa2nnpf0tp         JDBC Thin Client        SELECT COUNT(*) as CT from (se...


fy2psy6kfpd6z
语句  原来每次物理读 为3400  问题时为71,916

回复 只看该作者 道具 举报

9#
发表于 2013-7-3 21:57:08
memory_target        32749125632

你用了AMM

问题时的快照中:

        Begin        End               
Buffer Cache:         6,144M         6,144M        Std Block Size:         8K
Shared Pool Size:         16,128M         16,128M        Log Buffer:         117,268K



正常时的快照:

        Begin        End               
Buffer Cache:         9,216M         9,728M        Std Block Size:         8K
Shared Pool Size:         13,056M         12,544M        Log Buffer:         117,268K


显然 buffer cache 缩小了, 而shared pool增加了。

造成物理读明显增多的原因 很显然是 buffer cache shrink.


观察sga breakdown可以发现更多信息:
Pool        Name        Begin MB        End MB        % Diff
java        free memory        512.00        512.00        0.00
large        free memory        254.97        254.97        0.00
shared        CCursor        234.26        255.38        9.02
shared        KGH: NO ACCESS        3,270.09        3,270.09        0.00
shared        KGL handle        2,217.43        2,226.11        0.39
shared        PCursor        411.85        430.84        4.61
shared        free memory        7,578.08        6,837.33        -9.77
shared        gcs resources        334.55        334.55        0.00
shared        gcs shadows        238.09        238.09        0.00
shared        kglsim object batch        179.39        179.39        0.00
shared        sql area        1,174.94        1,351.53        15.03
streams        free memory        256.00        256.00        0.00

回复 只看该作者 道具 举报

10#
发表于 2013-7-3 21:58:32
Buffer Pool Advisory
Only rows with estimated physical reads >0 are displayed
ordered by Block Size, Buffers For Estimate
P        Size for Est (M)        Size Factor        Buffers for Estimate        Est Phys Read Factor        Estimated Physical Reads
D        768        0.10        91,320        10.58        100,993,584,071
D        1,536        0.19        182,640        8.14        77,714,392,776
D        2,304        0.29        273,960        5.71        54,468,607,298
D        3,072        0.39        365,280        3.27        31,249,716,487
D        3,840        0.48        456,600        2.80        26,737,161,010
D        4,608        0.58        547,920        2.33        22,235,941,700
D        5,376        0.68        639,240        1.86        17,744,348,329
D        6,144        0.77        730,560        1.39        13,261,273,662
D        6,912        0.87        821,880        1.22        11,665,946,875
D        7,680        0.97        913,200        1.06        10,073,627,933
D        7,936        1.00        943,640        1.00        9,545,363,287
D        8,448        1.06        1,004,520        0.89        8,483,921,823
D        9,216        1.16        1,095,840        0.72        6,896,397,415
D        9,984        1.26        1,187,160        0.64        6,136,977,744
D        10,752        1.35        1,278,480        0.56        5,378,309,115
D        11,520        1.45        1,369,800        0.48        4,620,181,434
D        12,288        1.55        1,461,120        0.40        3,862,589,823
D        13,056        1.65        1,552,440        0.33        3,106,252,692
D        13,824        1.74        1,643,760        0.25        2,350,308,794
D        14,592        1.84        1,735,080        0.17        1,594,696,432
D        15,360        1.94        1,826,400        0.09        839,278,194



Buffer Pool Advisory 显示增大buffer cache可以减少大量的 物理读

回复 只看该作者 道具 举报

11#
发表于 2013-7-3 21:59:40
总结一句就是 在本身存储能力不太好的情况下, 使用AMM ,且发生了从buffer cache 到shared pool的transfer , 数量大约为3G  引发了大量物理读 ,造成read by other session和 db file sequential read等等待,造成系统HANG

回复 只看该作者 道具 举报

12#
发表于 2013-7-8 18:02:01
非常感谢刘大的详尽的分析解答,学习了~

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-11-16 18:40 , Processed in 0.059237 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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