如何清理hung住的分布式事务
[清理两阶段提交不能完成的事务]
环境:
IDS 分布式数据库,遵循两阶段提交协议
问题描述:
重启IDS后仍然不能清理一些XA事务
解答:
通过onstat -G可以获得所有XA分布式事务的信息,如下所示:
onstat -x:
============
Transactions
address flags userthread locks beginlg curlog logposit isol retrys coord
cd18018 A---- cce7018 0 0 41 0xc0018 COMMIT 0
cd181f8 A---- cce7630 0 0 0 0x0 COMMIT 0
cd183d8 A---- cce7c48 0 0 0 0x0 COMMIT 0
cd185b8 A---- cce8260 0 0 0 0x0 COMMIT 0
cd18798 -LX-G 0 13 41 41 0x2b5758 COMMIT 0
cd18978 A---- cce94a8 0 0 0 0x0 COMMIT 0
cd18b58 A---- cce8e90 0 0 0 0x0 COMMIT 0
7 active, 128 total, 8 maximum concurrent
onstat -G:
==============
Global Transaction Identifiers
address flags isol timeout fID gtl bql data
cd18798 -LX-G COMMIT 0 4478019 16 48 30313233343536373839616263646566303132333435363738396162636465663031323334353637383961626364656630303030303030303030303030303031
1 active, 128 total
方法:
(1)可以使用onmode -Z 0xcd18798,杀掉不能结束的全局事务。
(2)两阶段事务不能结束,可能是由于第二阶段提交事务由于某些原因不能接收到commit或者是rollback的命令,所以会hung住。所以我们需要手工发起一个commit或者rollback命令来让这个事务完成。 特殊情况下,需要联系IBM技术支持中心得到帮助。
本日志由 flyinweb 于 2011-02-12 10:03:58 发表,目前已经被浏览 1620 次,评论 0 次;
作者添加了以下标签: 分布式事务,distributed transaction;
引用通告:http://www.517sou.net/Article/577/Trackback.ashx
而且直接配置文件是效率最高的,通过其它驱动效率都相对较低,BDB
这个测试不太准确,看官方的测试结果:http://bind-dlz.sourceforg
为什么使用BDB时QPS这么低? 我在bind版本基本相似的环境中测试的
It is quite useful and interesting too.
VIRT 的上限是64G,也就是36位, cat /proc/cpuinfo的结果是:addre
昨天要准备用线程重写webbench,试验了下Fedora Linux 2.6.35.14
不明白您的具体的意思是什么?
已经发送到你QQ邮箱