蝴蝶效应

8月1日
16点30分左右，田老师看到监控日志中出现了大量的锁等待。

反映给开发部门后开始进行问题的诊断。

一直到17点15分时，快要下班了，问题依旧。

没办法，总不能问题没解决就先行回家吧。于是看看到底是啥问题。

先看看现在的会话在等待什么？
看到大部分会话因为执行了insert into gonotion表格以及update gwwflog这两个语句发生了行级事务等待。

首先查看这两个表是否有外键的约束造成。结果发现这两个表只有主键，没有外键，并且本身的主键也没有被当做外键。这方面的因素可以排除。

现在的问题关注那个insert，insert造成行级事务锁，那么原因肯定在于是多行插入了一个相同的主键值。
要么这个事务提交，然后其他等待的事务就报主键冲突错误，要么这个事务回退，那么其他等待的会话中又有一个会出现一个会话持有锁，造成其他会话继续等待。-----这是后话了。

 

到底是什么原因造成多个会话插入相同的值呢？根据以前经验，该系统问题多数在与取号算法（即主键）有问题。很多因素下造成取号相同。

但是开发部门矢口否认取号算法有问题。问他们影响范围是一个机构还是全国的，给我的回答是全国范围。

于是继续查看是否有其他线索，检查操作系统日志，数据库日志，操作系统负载，表空间大小等，均未发现问题。
继续监控看锁的等待列表，发现一个很奇特的问题，列表上面的持有锁的会话会随时间做一些变化，过几分钟后，另外的会话会变成持有锁的会话，这个会话是先前等待锁的会话中的一个。
这一现象很像事务回退的症状。

开发部门最终检查中间件日志，发现可能是由于取号是根据应用访问平台时获取的内容，如果应用与平台的网络断掉也就是应用无法访问到平台数据，那么会造成取的号都由空值生成，最终造成主键冲突。

所以应用与平台的网络问题，算号问题，最终导致了看到的数据库的的等待现象。

看来某些时候的坚持还是自己要相当有底气才行。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/288166/viewspace-705048/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/288166/viewspace-705048/