一个客户的数据库出现了严重的性能问题，根据awr的报告，系统性能问题与回滚的争用有关系。






正常情况下，客户数据库的AWR的DB TIME信息为：


Elapsed: 119.92 (mins)


DB Time: 22.99 (mins)


而出现问题的时刻，DB TIME信息变成了：


Elapsed: 120.07 (mins)


DB Time: 37,447.52 (mins)


数据库服务器存在32颗CPU，可以看到，在采样期间，这32颗CPU几乎都是处于100%的工作状态。


Top 5 Timed Events


Event                          Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class


enq: US – contention      1,995,867 943,404          473              42.0 Other


row cache lock               568,341 699,241        1,230              31.1 Concurrency


gc buffer busy               389,944 227,279          583              10.1 Cluster


enq: TX - index contention   393,340 171,647          436               7.6 Concurrency


buffer busy waits            186,159 107,135          576               4.8 Concurrency


观察TOP 5等待事件，发现大部分等待发生在enq: US – contention和row cache lock上。根据这些信息判断，数据库可能碰到了bug：7291739。


根据metalink上这个bug的描述，这个bug会出现大量的enq: US – contention等待，而且还是出现latch: row cache objects的等待。而在dc_rollback_segments上会出现比较严重的latch锁。


检查正常时刻awr报告中dc_rollback_segments统计信息：


Cache               Get Requests Pct Miss Scan Reqs Pct Miss Mod Reqs Final Usage


dc_rollback_segments     185,406    0.00        0                0      3,615


而对于问题时刻，dc_rollback_segments统计为：


Cache               Get Requests Pct Miss Scan Reqs Pct Miss Mod Reqs Final Usage


dc_rollback_segments   4,805,587    0.01        0            3,073      3,613


显然，出现问题时刻的dc_rollback_segments是正常时刻的50倍左右。


而另一方面，由于问题时刻之前，系统中出现了长运行的SQL语句，是的系统中回滚的争用大幅度的增长：


Undo Segment Stats


End Time    Num Undo Blocks Number of Transactions Max Qry Len (s) Max Tx Concy


05-May 18:08          7,608                45,560           301        1,748


05-May 17:58          5,187                24,909             0        1,364


05-May 17:48          1,229                 7,471             0          307


05-May 17:38          2,942                16,753             0        1,002


05-May 17:28          1,119                 5,293             0          382


05-May 17:18          2,446                 6,925           898          502


05-May 17:08          2,137                 8,464           349          273


05-May 16:58          2,874                27,562             0            6


05-May 16:48          2,625                25,278             0            7


05-May 16:38          2,496                23,711         1,006            8


05-May 16:28          2,194                21,037           404            6


05-May 16:18          1,877                17,981             0            5


05-May 16:08          1,883                17,215             0            5


唯一的疑问是这个问题在10.2.0.4.4、10.2.0.5、11.2.0.1中被FIXED，而当前数据库补丁打到了10.2.0.4.7，因此当前问题就是这个bug还存在疑问。


而除了bug:7291739之外，Oracle的Bug 8268775也都存在比较大的可能性。这个数据库确实是一个RAC环境，而且在bug发生期间，确实存在大量程序会话连接到实例的情况发生。


如果要是碰到了这个bug，那么在10.2中解决这个bug的可能性不大，至少要升级到11g才能解决这个问题。


oracle视频教程请关注:http://u.youku.com/user_video/id_UMzAzMjkxMjE2.html