一个客户的数据库出现了严重的性能问题,根据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 �C 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 �C contention和row cache lock上。根据这些信息判断,数据库可能碰到了bug:7291739。
根据metalink上这个bug的描述,这个bug会出现大量的enq: US �C 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