informix常用故障处理操作

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

-a -d -s -i 即可在当前逻辑日志后增加新的逻辑日志，并且不需要执行 0 级备份。 频繁的锁冲突 故障现象： 在正常的数据库操作中会经常出现－243、－244 等一类的锁错误码出现 -243 Could not position within a table table-name. -244 Could not do a physical-order read to fetch next row. 故障分析： 数据库在进行修改操作的时候为了防止其他用户的同时修改，都会在修改所涉及的数据上设置对应的锁，如果其他用户再访问到这些已经被放置上锁的数据，就会出现锁失败。例如如果需要知道在指定的表上是有哪些用户具体占用了锁，可以通过以下的步骤： 1. 首先确定表的 partnum，可以通过查询 systables 里面的 partnum，也可以通过执行 oncheck –pt database:tabname 查看 Partition partnum 来获得，该数据为十进制数，需要转换为十六进制； 2. 执行 onstat –k | grep partnum 来查找相应的信息，partnum 为上一个步骤获得的结果，需要使用具体的十六进制值来替换，观察其 owner 字段的地址信息； 3. 执行 onstat –u | grep address 来获得实际的 session 信息，address 为上一个步骤获得的结果，这是就可以找到具体的锁的拥有者。 oncheck -pt stores:customer … Partition partnum 2097201 2097201＝0x200031 onstat -k| grep 200031 5409bed4 0 54d93878 5409be7c HDR+IX 200031 0 0 5409bf2c 0 54d93878 5409bed4 HDR+U 200031 100 0 onstat -u | grep 54d93878 54d93878 Y--P--- 6 informix 12 5558e720 0 3 113 0 故障处理：

调整数据库隔离级别，例如使用 dirty read；将数据库表的缺省页级锁修改为行级锁；设置锁等待时间；调整应用 SQL，提高执行效率，尽量快的完成事务处理，释放资源；如果需要快速处理锁冲突的情况，在确定锁的实际拥有者以后可以确定是否应该终止其操作，执行 onmode –z Kill specified session id，以达到释放锁资源的目的。

长事务

故障现象：

在数据库日志里面出现发现长事务的提示，受影响的事务处于回滚状态，个别情况下会导致整个数据库实例的其他数据库会话都停止执行。

故障分析：

当一个活动事务它所占用的逻辑日志个数的比例达到或超过 LTXHWM 所设定的值，数据库就会判定该事务为一个长事务，对该事务进行回滚操作，如果这个时候逻辑日志的使用个数仍然持续上涨达到或超过 LTXEHWM 所设定的值，则数据库会停止其他会话的正常运转，全力保证该长事务的回滚操作。

故障处理：

根据数据库日志里面所提供的信息可以很方便的发现具体是那一个事务造成了长事务。系统在将某个事务判定为长事务以后就会自动对其进行回滚操作。事后可以有针对性的调整应用将大的事务划分为小事务进行提交；避免一个活动事务长时间没有后续的操作；提供充足的逻辑日志空间，这里所指出的不仅是空间的总量需要增加，逻辑日志的个数也是应该增加的，因为判断的标准是以逻辑日志的使用个数所占比例来确定的。在 INFORMIX 9.3X 以后的版本中可以通过动态增加逻辑日志的手段避免由于长事务带来的一些不良影响，在长事务回滚过程中如果逻辑日志空间被消耗完毕，如果 DYNAMIC_LOGS 设置为 2，数据库服务器会自动在最后创建的逻辑日志所存在的 dbspace 上查找空余空间，按照最后创建的逻辑日志的大小自动在当前逻辑日志之后新增逻辑日志，如果不能满足需要则会创建失败，需要管理员手工添加。

数据库 chunk 出现异常，I/O 失败 故障现象： 数据库日志中出现 chunk IO 错误，使用 onstat –d 观察 chunk flag 的状态是 down 的状态，数据库操作中不能操作包含在这些 chunk 中的数据，如果使用到这些数据可能会返回错误，严重情况下会导致数据库宕机。例如： onstat –d … Dbspaces 554241a0 2 0x1 2 2 N D informix datadbs … 54dd2610 2 2 0 25000 23964 PD-- /home/informix/940/dsk/data_chk1 故障分析： 由于发生 IO 错误，数据库不能正常的操作包含在受影响 chunk 中的数据，所有的操作请求都将失败。这可能是由于磁盘设备出现问题、chunk 所使用的设备不存在、使用的链接设备不存在、设备的权限错误等可能性。 故障处理： 根据前面所列出的可能性逐一进行检查。一个快速确定存储设备是否可用的办法是：使用 dd 命令实际读取该设备，这里需要强调的是只能做读取操作，不能写入，严禁在 of 设备项指定为 chunk 路径，因此我们也只能验证其存储设备是否可读，例如： dd if=/home/informix/940/dsk/data_chk1 of=/dev/null bs=2048k 在确定所有硬件或设置都已经恢复正常以后，可以首先尝试使用 onspaces –s 进行恢复，如果还不能恢复成功，请联系 IBM 相关人员技术支持。 回页首 不能插入数据 故障现象： 在向数据库表插入数据的时候报没有空间或不能创建新的 extent，其返回错误码可能是： -131 ISAM error: no free disk space. -136 ISAM error: no more extents. -271 Could not insert new row into the table. 故障分析：

由于表所存在的 dbspaces 上没有足够的连续空间来创建新的 extent；达到每个单片表的 extents 个数上限；达到每个单片表记录数的上限，以上 3 种可能都会导致不能插入数据情况的发生。

故障处理：

在出现这种问题以后，首先应该查看应用日志、应用程序，也可以通过查看当前正在执行并返回错误的 SQL 以确定到底是哪张表不能插入数据。在定位受到影响的表以后应该确定表所存在的 dbspace 是否有足够的连续空闲空间，如果没有请相应的增加 chunk 空间以扩充其数据库存储空间。在确认存在足够的连续空闲空间以后再检查是否达到后续的 2 个上限，可以使用一些脚本工具或数据库命令来实现这一点。在确认问题的原因以后，理想的解决方法是为数据库表提供更多的使用空间，例如增加 chunk、将表进行重建、将表进行合理的分片等；应急的处理原则是：小批量、小批量地删除部分数据，尽量将需要处理的数据限制在较小的范围内，通过多次的操作来达到删除数据的目的，避免出现大事务、长时间不能完成的情况出现。

本文来源：https://www.bwwdw.com/article/6x8a.html