Informix杀掉死锁的方法和查看死锁的sql语句(转)
2011-01-21 10:01
567 查看
Informix锁表产生的原因,要么是多个用户同时访问数据库导致该问题,要么是因为某个进程死了以后资源未释放导致的。如果是前一种情况,可以考虑将 数据库表的锁级别改为行锁,来减少撞锁的机会;或在应用程序中,用set lock mode wait 3这样的语句,在撞锁后等待若干秒重试。如果是后一种情况,可以在数据库端用onstat -g ses/onstat -g sql/onstat -k等命令找出锁表的进程,用onmode -z命令结束进程;如果不行,就需要重新启动数据库来释放资源。 1:$ onstat -k | grep HDR+X
获得sessid,其中HDR+X 为排他锁,HDR 头,X 互斥 ,sessid 是会话标识符编号。 2:$ onstat -g ses sessid
根据sessid得到进程pid,其中pid 是与此会话的前端关联的进程标识。
(可通过$ onstat -g sql sessid 命令查看执行的sql语句) 3:$ ps -ef |grep pid 由此,我们可得到锁表的进程,可根据实际锁表进程的重要程度的具体情况采取相映处理方法:
对于重要且该进程可以自动重联数据库的进程,可以用onmode -z sesid 的方法杀掉锁表session:
$ onmode –z sessid 否则也可直接杀掉锁表的进程 kill pid:
$ kill -9 pid 至此,死锁即被清除掉。 ————————————————————————- 查找锁定的表名称 通过onstat -k 查找的rowid 等于0的表锁信息的 tblsnum 信息查找表名。
如 tblsnum等于500e19 执行 select * from systables where hex(partnum)=’0×00500e19′ 查找到当前锁表的表名。 Informix -244 错误 : Could not do a physical-order read to fetch next row. 具体错误解释: #finderr -244 原因: a.锁表 b.记录太多 c.页损坏 d.某个进程死了以后资源未释放导致 在数据库端用 onstat –g ses/onstat –g sql / Onstat –k 等找出锁表进程,用onmode –z结束该进程, 不行,重启数据库释放。 锁方式: 行方式(row),页方式(默认page),表方式(table)。 解决: 1.降低锁级别 2.减少加锁事务的时间跨度 3.设置等待解琐时间 相关命令: )检查索引及页损坏情况 #oncheck –cID database_name:table_name ) 查看锁级别 #oncheck –pt database_name:table_name )设置锁级别(行方式) #alter table table_name lock mode(row) )设置隔离级别 #set isolation to dirty read )设置等待解锁时间(不宜过大) #set lock mode to wait second(秒) 不等待 #set lock mode to not wait
获得sessid,其中HDR+X 为排他锁,HDR 头,X 互斥 ,sessid 是会话标识符编号。 2:$ onstat -g ses sessid
根据sessid得到进程pid,其中pid 是与此会话的前端关联的进程标识。
(可通过$ onstat -g sql sessid 命令查看执行的sql语句) 3:$ ps -ef |grep pid 由此,我们可得到锁表的进程,可根据实际锁表进程的重要程度的具体情况采取相映处理方法:
对于重要且该进程可以自动重联数据库的进程,可以用onmode -z sesid 的方法杀掉锁表session:
$ onmode –z sessid 否则也可直接杀掉锁表的进程 kill pid:
$ kill -9 pid 至此,死锁即被清除掉。 ————————————————————————- 查找锁定的表名称 通过onstat -k 查找的rowid 等于0的表锁信息的 tblsnum 信息查找表名。
如 tblsnum等于500e19 执行 select * from systables where hex(partnum)=’0×00500e19′ 查找到当前锁表的表名。 Informix -244 错误 : Could not do a physical-order read to fetch next row. 具体错误解释: #finderr -244 原因: a.锁表 b.记录太多 c.页损坏 d.某个进程死了以后资源未释放导致 在数据库端用 onstat –g ses/onstat –g sql / Onstat –k 等找出锁表进程,用onmode –z结束该进程, 不行,重启数据库释放。 锁方式: 行方式(row),页方式(默认page),表方式(table)。 解决: 1.降低锁级别 2.减少加锁事务的时间跨度 3.设置等待解琐时间 相关命令: )检查索引及页损坏情况 #oncheck –cID database_name:table_name ) 查看锁级别 #oncheck –pt database_name:table_name )设置锁级别(行方式) #alter table table_name lock mode(row) )设置隔离级别 #set isolation to dirty read )设置等待解锁时间(不宜过大) #set lock mode to wait second(秒) 不等待 #set lock mode to not wait
还可以这样解决: 如果是日志型数据库,在执行的时候,可以先锁定 begin work; lock table tab_name in exclusive mode; 要执行的sql语句; commit work; 如果是非日志的数据 lock table table_name in exclusive mode; 要执行的sql语句; unlock table tab_name;
中间件全局事务锁问题 中间件与informix连接时会出现onstat -k 中 owner 内容为0的现象。 这是应该查看全局事务onstat -x 和onstat -G DATABASE sysmaster; select hex(tx_addr) trans_addr,hex(tx_lklist) lock_addr from systrans
where hex(tx_addr) like '%c00000006e329778%'; 需要说明的是,c000000007674c58是使用onstat -x 或 onstat -G得到的全局事务的地址。 上面SQL语句提供出该全局事务对应的锁地址,这时如果得到的锁地址与锁表的锁地址相同的话,
你就必需从应用端(通常是三层结构的中间件)发命令让该全局事务回滚或提交,否则该锁会被一直持有,直到你执行oninit。
onstat -k 的owner 列中的地址与onstat -x 中的userthread 对应。地址:http://www.timetoyou.com/tag/informix%E6%9F%A5%E7%9C%8B%E6%AD%BB%E9%94%81%E7%9A%84sql%E8%AF%AD%E5%8F%A5
相关文章推荐
- 查看死锁的SQL语句
- 查看LINQ生成SQL语句的几种方法
- 在SQLServer上查看SQL语句的执行时间的方法
- Yii调试查看执行SQL语句的方法
- set explain on--Informix 11.5 SQL 语句性能监控方法及实现
- oracle 中--怎么查看当前表空间在作什么操作?--查锁,死锁,当前执行时间长的Sql语句,没提交的事务,对象为哪些进程所用
- SQLServer 2008数据库查看死锁、堵塞的SQL语句
- oracle 中--怎么查看当前表空间在作什么操作?--查锁,死锁,当前执行时间长的Sql语句,没提交的事务,对象为哪些进程所用
- SQLServer 2008数据库查看死锁、堵塞的SQL语句
- Oracle 查看表空间的大小及使用情况sql语句和oracle增加表空间大小两种实现方法
- MySQL 查看正在执行的sql语句的方法
- Informix 11.5 SQL 语句性能监控方法及实现
- NHibernate 查看生成的sql语句的方法
- SQLServer 2008数据库查看死锁、堵塞的SQL语句
- 在SQLServer上查看SQL语句的执行时间的方法
- mybatis 查看sql语句的方法
- Oracle之查看最近最消耗CPU的SQL语句及会话信息的方法
- 查看LINQ生成SQL语句的几种方法