今天上午9:41，接到客户反馈数据库出现性能问题，有大量的行锁等待。经过分析，原因是实施组昨天下午删除了两条业务单据，一直没有提交导致。
此次性能事件影响范围：
确认没有接到大量用户投诉系统慢的电话，但分析weblogic一个节点的日志，nohup.out日志中发现某模块有38次stuck线程，可以推断出还是影响了少部分用户收到了影响。
| Snap Id | Snap Time | Sessions | Cursors/Session | |
|---|---|---|---|---|
| Begin Snap: | 23222 | 23-5月 -13 08:00:29 | 338 | 20.0 |
| End Snap: | 23223 | 23-5月 -13 09:00:41 | 410 | 18.1 |
| Elapsed: | 60.21 (mins) | |||
| DB Time: | 387.28 (mins) |
|
Event |
Waits |
Time(s) |
Avg Wait(ms) |
% Total Call Time |
Wait Class |
|---|---|---|---|---|---|
|
enq: TX - row lock contention |
5,482 |
16,064 |
2,930 |
69.1 |
Application |
|
CPU time |
|
7,115 |
|
30.6 |
|
|
db file sequential read |
55,948 |
46 |
1 |
.2 |
User I/O |
|
db file scattered read |
7,927 |
37 |
5 |
.2 |
User I/O |
|
log file sync |
9,884 |
37 |
4 |
.2 |
Commit |
在SQL ordered by Elapsed Time中发现被堵塞会话的SQL。
事件回顾：
5月22日
17:30 实施组在PL/SQL删除了单号为DA261408和502F4DA3的业务单，没有提交，此时数据库会将这两条锁住。
5月23日
8:41 有用户修改单号为DA261408和502F4DA3的单据，由于记录被锁住，形成行锁等待（access.log中可以查到访问记录）。此后不断有用户操作这两张单据(access.log中可以看到)，形成的行锁越来越多,可以从数据库报告上可以看到相应的现象，同时nohup.out日志中出现stuck。
5月23日
9:41 监控到数据库性能负载高。
5月23日
10:40 kill行锁的会话。