Informix 计算长事务回滚时间及解决办法
如何估算长事务回滚的时间 环境:
IDS9.40及其以上版本 问题描述:
用户往往由于一次操作的数据量过大，导致长事务，使整个数据库服务器暂时挂起而不可用。用户需要估算长事务回滚完成的时间，以便做出安排。 解答:
可以使用onstat -x -r 10监控该事务的回滚状态.并通过日志回滚的速率来估算回滚的时间。 “-r 10”表示每10秒显示一次。下面是两次的间隔10秒输出：
address flags userthread locks beginlg curlog logposit isol retrys coord d745b58 A-R-- d715e7c 4904 51 53 0x8f61c8 COMMIT 0
address flags userthread locks beginlg curlog logposit isol retrys coord d745b58 A-R-- d715e7c 4904 51 53 0x5a1acc COMMIT 0
从输出可以看到，该事务起始的逻辑日志号是51，当前回滚到53，还需要继续回滚2个逻辑日志。在这10秒中回滚的逻辑日志大小可以通过两次的logposit相减得出，方法为：去掉每个logposit的后三位，剩下的数字相减就是日志回滚的page数目，再乘以page size 就可得到这10秒回滚的日志大小。例如：
（0x8f6 - 0x5a1）*4 = 3412 K (4表示当前系统的page size是4K),那么一分钟逻辑日志能够回滚 3412/10*60=20472 K
假设每个逻辑日志的大小为50M，则该长事务还需要回滚的时间大约是5.28分钟 (（1024*50) * 2 + 0x5a1*4)/20472 =5.28
一、查看数据库状态 正常情况下是 onstat -
IBM Informix Dynamic Server Version 9.40.FC7 -- On-Line -- Up 35 days 16:51:16 -- 3920896 Kbytes 长事务情况下是 onstat -
IBM Informix Dynamic Server Version 9.40.FC7 -- On-Line (LONGTX) -- Up 35 days 16:41:40 -- 3920896 Kbytes Blocked:LONGTX
二、显示事务（transaction）信息
其中flag字段中第三个标志位为R说明事务在rollback，说明这个事务是长事务 onstat -x
IBM Informix Dynamic Server Version 9.40.FC7 -- On-Line (LONGTX) -- Up 35 days 16:41:56 -- 3920896 Kbytes Blocked:LONGTX Transactions
1cf0a6748 A-R-- 1cd55c618 642073 119403 119405 0x1aa91e4 DIRTY 0
三、通过长事务的userthread值找出session id onstat -u |grep 1cd55c618
1cd55c618 --RPX-- 1880841 informix - 0 0 642073 256446 323049
四、显示会话连接信息，找出造成长事务的SQL语句，并优化 onstat -g ses 1880841
informix锁表处理步骤：
锁表处理步骤：
1、onstat -ks|grep HDR+X //查询是那个表被锁
address wtlist owner lklist type tblsnum rowid key#/bsiz c1809510 0 d656e774 c181cb3c HDR+X 6002e1 2c602 0 需要关注lklist和type项，从上面来看tblsnum为6002e1（6292193十六进制转换成十进制）的表被锁了。可以重查询是那个表被锁：
dbaccess ：select * from systables where partnum='6292193'得到 tabname basetab_mvpn owner smpmml partnum 6292193 tabid 12813 rowsize 464 ncols 61 nindexes 1 nrows 2984 created 12/10/2002 version 839843846 tabtype T
locklevel R npused 746 fextsize 16 nextsize 16 flags 0
2、onstat -u，将owner(address)为d656e774的线程找出来
address flags sessid user tty wait tout locks nreads nwrites d656e774 Y--P--- 4261 smp20 - d6ad2330 0 180 99620 16 3、onstat -g sql d656e774可以将这个线程执行过的sql语句打印出来。 4、只要用informix用户执行onmode-z sessid干掉线程 onmode-z 4261
重点说明：onstat -g ses sessid找个进程PID来,然后ps -ef|grep Pid; kill -9 pid 在处理这些问题时还会遇到表被锁是因为该线程还没有执行完毕，此时就不能简单的 onmode -z杀线程
Informix常见问题处理
概述
在实际的生产运行环境中，笔者在国内很多客户现场都看到开发人员和系统管理人员遇到很多有关 Informix 常见的问题，进而被多次问起如何处理这些常见的 Informix 问题，笔者根据自己在工作中对 Informix 数据库的使用经验积累写下这篇文章。
Informix 常见的问题有以下几种：
? ?
逻辑日志满 频繁的锁冲突
? ? ?
长事务问题
数据库 chunk 出现异常，I/O 失败 不能插入数据
下面我们分别针对以上问题来一一讲解如何处理。
逻辑日志满
故障现象：
数据库不再进行任何操作，使用 onstat –l 命令观察逻辑日志状态，所有的逻辑日志都处于已使用未备份状态，即 flags 为 U------ 标志。
故障分析：
由于数据库的大部分操作都需要记录逻辑日志，所以如果逻辑日志由于各种各样的原因被充满都会导致数据库停止正常的操作，等待逻辑日志空间的释放、重新再利用。这一般会由于数据库逻辑日志没有及时备份、数据库逻辑日志空间分配过小、逻辑日志里面包含活动事务、包含检查点信息等原因。
故障处理：
检查是否是由于逻辑日志备份出现问题，如果是不能备份请查找不能备份的原因，可能是由于磁带满或磁带机出现故障，或者是磁带设备繁忙；个别情况下即使逻辑日志标志为已备份但是仍然是不可使用的，包括：
1. 该逻辑日志包含活动的事务信息，由于数据库需要考虑其可能的回滚操作，因此是不会让该逻辑日志的内容被覆盖的，可以通过 onstat –x 检查其 beginlg 来确定事务的逻辑日志起始位置；
2. 包含检查点信息，可以通过 onstat –l 观察 flags 的最后一位为 L 的逻辑日志的位置，在它之后的逻辑日志即使已经备份也是不可使用的，因为这些逻辑日志内容将会在快速恢复中使用到。
在这些情况出现以后如果暂时不能快速的处理，在 IDS 9.3x 或以后的版本上可以使用逻辑日志联机增加的功能，只要有空闲的 chunk 空间，使用 onparams