This transaction has been rolled back, rather than only the current.

今天上午，收到运维组同事反映某应用系统的其中一个功能报错，不是偶然性事件，每个使用该功能的用户都报错。报错内容为：This transaction has been rolled back, rather than only the current.

为了进一步分析该问题，并解决问题，产生了如下对话：

“ 系统昨天晚上是否发布过程序或者做过相关较大的调整？ “

”没有。没有做过任何调整。“

”该功能涉及到了哪些表？主要是干嘛的？”

“该功能主要是向中间库发送数据的，但是中间库我试过访问是正常的。”

“我先看看中间库吧，你顺便帮我找一下是涉及到了哪些表。”

几分钟之后，相关数据库表已经搜集完毕，我登录上接口服务器，发现数据库确实正常，测试代理服务，所有连接都是正常的。根据搜集到的库表，在生产库上通过代理表尝试访问，没有报错。一切看起来都好像很正常的样子。

“这个表读写数据 应该是比较频繁吧？怎么会没有数据？”

”不知道哦，这个表不应该没有数据才对呀。”

根据以往经验，SYBASE有时候代理表会莫名其妙的出现“可连通，但是读写不了”的情况。

“你去试试在主库里通过客户端读写一下这个代理表（AAA），看看能否正常写入数据？”

“测试结果报错，内容跟程序客户端之前抛出的异常一样。”

到这里，十有八九就是代理表异常了。于是，通过管理端，把相关涉及到的代理表进行了删除、重建，在管理端里尝试读取数据，可以正常看到数据了。

”你再让客户重新发送一下数据看看是否正常？”

几分钟过后。。。。

“都OK了，一切正常！”

问题是否到此结束？差多了，但是还未确保完全结束。

“你把代理表都检查一下，看看哪些在管理端里都没办法看到数据的，全部都重建一下吧，说不准一会某些功能用到的表也有问题，又要一大片人跳起了。”

“好的。”

PS:代理表莫名其妙会出现读不到数据的情况，之前出现过，咨询过原厂的工程师，当时也并没有得到一个确切的答案。不过经过我们测试，重建就可以解决了。希望知道如何可以根本解决的大虾给予指点，小弟不胜感激：）