ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 蝴蝶效应

蝴蝶效应

原创 Linux操作系统 作者:lsl031 时间:2011-08-17 09:18:49 0 删除 编辑

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

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

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

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

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

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


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

 

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

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

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


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


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

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

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

请登录后发表评论 登录
全部评论

注册时间:2009-03-24

  • 博文量
    56
  • 访问量
    799650