2013-05-23修改数据未提交引发的性能问题

      今天上午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行锁的会话。