昨天晚上忙乎解决智能网客户系统遇见如下报错，现在对这类问题予以总结：
Sun Jun 19 15:30:19 2011

15:30:19  Warning: ONCONFIG dump directory (DUMPDIR) '/opt/informix/temp' has insecure permissions
15:30:19  Event alarms enabled.  ALARMPROG = '/opt/informix/etc/alarmprogram.sh'
15:30:19  Booting Language <c> from module <>
15:30:19  Loading Module <CNULL>
15:30:19  Booting Language <builtin> from module <>
15:30:19  Loading Module <BUILTINNULL>
15:30:25  Requested shared memory segment size rounded from 1176KB to 2048KB
15:30:25  IBM Informix Dynamic Server Version 9.40.UC7     Software Serial Number AAA#B000000
15:30:30  IBM Informix Dynamic Server Initialized -- Shared Memory Initialized.

15:30:30  Physical Recovery Started at Page (3:36643).
15:30:31  Physical Recovery Complete: 3555 Pages Examined, 3424 Pages Restored.
15:30:31  Logical Recovery Started.
15:30:31  20 recovery worker threads will be started.
15:30:32  Assert Warning: I/O read chunk 13, pagenum 9449, pagecnt 1 --> errno = 9
15:30:32  IBM Informix Dynamic Server Version 9.40.UC7    
15:30:32   Who: Session(12, informix@itellin2, 0, 9105f1d8)
        Thread(61, xchg_1.6, 910339f8, 7)
        File: rsbuff.c Line: 5070
15:30:32   Action: Please notify IBM Informix Technical Support.
15:30:32  stack trace for pid 17514 written to /opt/informix/temp/af.425a598
15:30:32   See Also: /opt/informix/temp/af.425a598
15:30:32  I/O read chunk 13, pagenum 9449, pagecnt 1 --> errno = 9
15:30:32  Rollforward of log record failed. iserrno = 172
15:30:32  Log Record: log = 215146, pos = 0xa332c4, type = OLDRSAM:HINSERT(40), trans = 14
15:30:42  Assert Warning: Chunk 5 is being taken OFFLINE.  //关键信息
15:30:42  IBM Informix Dynamic Server Version 9.40.UC7    
15:30:42   Who: Session(12, informix@itellin2, 0, 9105f1d8)
        Thread(61, xchg_1.6, 910339f8, 7)
        File: rsmirror.c Line: 1887
15:30:42   Results: Dynamic Server will block at next checkpoint
15:30:42   Action: Shutdown (onmode -k) or override (onmode -O)
15:30:42  stack trace for pid 17514 written to /opt/informix/temp/af.425a598
15:30:42   See Also: /opt/informix/temp/af.425a598
15:30:42  Chunk 5 is being taken OFFLINE .   //关键信息
15:30:42  Rollforward of log record failed. iserrno = 172
15:30:42  Log Record: log = 215146, pos = 0xa332c4, type = OLDRSAM:HINSERT(40), trans = 14
15:30:42  Rollforward of log record failed. iserrno = 101
15:30:42  Log Record: log = 215146, pos = 0xa3e130, type = OLDRSAM:DELITEM(29), trans = 101
15:30:42  Rollforward of log record failed. iserrno = 101
15:30:42  Log Record: log = 215146, pos = 0xa3e130, type = OLDRSAM:DELITEM(29), trans = 101
15:30:42  Rollforward of log record failed. iserrno = 101
15:30:42  Log Record: log = 215146, pos = 0xa3e184, type = OLDRSAM:DELITEM(29), trans = 101
15:30:42  Rollforward of log record failed. iserrno = 101
15:30:42  Log Record: log = 215146, pos = 0xa3e184, type = OLDRSAM:DELITEM(29), trans = 101
15:30:42  Rollforward of log record failed. iserrno = 101
15:30:42  Log Record: log = 215146, pos = 0xa3e6e4, type = OLDRSAM:DELITEM(29), trans = 101
15:30:42  Rollforward of log record failed. iserrno = 101
如果总是关注后面的问题，那么就上当了，其实问题还在上面标注的关键信息列。

以前别的系统同样发生过如下故障情况如此发生：发现workdbs空间满了，就给其加chunk文件，然后会话柱塞，整个系统hang住，立即重启后，发生数据库处于检查点阻塞状态，在观察dbspace状态后发现，整个workdbs都是处于异常状态，不过现场的当时发生一个磁盘存在问题，所以是造成i/o问题，具体分析应该是worksbs的第一个chunk所在的磁盘发生异常，导致整个dbspace状态异常。好在备份完整。
Dbspaces
address  number   flags    fchunk   nchunks  flags    owner    name
d671e158 1        1        1        1        N        informix rootdbs
d6749090 2        1        2        1        N        informix logdbs
d6749150 3        1        3        1        N        informix phydbs
d6749210 4        2001     4        2        N T      informix tempdbs
d67492d0 5        5        6        30       ND       informix workdbs
 5 active, 2047 maximum
Chunks
address  chk/dbs offset   size     free     bpages   flags pathname
d671e218 1   1   20       63500    62409             PO-   /dev/vgdata/rlvrootdbs
d671e920 2   2   20       500000   349947            PO-   /dev/vgdata/rlvlogdbs
d671ea28 3   3   20       500000   199947            PO-   /dev/vgdata/rlvphydbs
d671eb30 4   4   20       250000   249947            PO-   /dev/vgdata/rlvtempdbs1
d671ec38 5   4   20       250000   249997            PO-   /dev/vgdata/rlvtempdbs2
d671ed40 6   5   20       1000000  0                 PD-   /dev/vgdata/rlvworkdbs1
d671ee48 7   5   20       1000000  0                 PD-   /dev/vgdata/rlvworkdbs2
...
d6748f88 35  5   20       1000000  0                 PD-   /dev/vgdata/rlvworkdbs30
 35 active, 2047 maximum

对于这类问题，可以总结如下，均可归类为chunk状态监控存在异常的问题，整个过程中处理思路可以如下：

1  处理问题的思路

1.1 在相关的chunk进行I/O操作时如果相应的Chunk有问题，数据库会报相应的I/O错误，并将CHUNK置为“PD”，另外当数据库启动或是进行数据库备份时，Informix数据库会对所有空间进行例行的健康检查“sanity check”，
如果相应的chunk有错误，Informix数据Informix online.log中输出如下的错误信息：

08:39:58 IBM Informix Dynamic Server Version 9.40.FC4 08:39:58
Who: Session(1, informix@HBDB84_1, 0, c000000000b63028)
Thread(15, main_loop(), c000000000b21028,
3)File: rspartn.cLine: 7747 08:39:58
Results: Chunk 117 is being taken OFFLINE.08:39:58
Action: Restore chunk from archive.08:39:58
stack trace for pid9747 written to /tmp/af.3f7f15e 08:39:58
See Also: /tmp/af.3f7f15e 08:39:59 chunk failed sanity check 08:39:59 I/O error,
Primary Chunk '/opt/informix/chunks/npmhis2008 _data/npmdb_npmchk_07' --Offline (sanity)

1.2 “Oncheck–pr”输出当数据库停止后，数据库的所有状态信息都会写到相应的Informix保留页中，此时离线状态下运行oncheck-pr可以准确的看到相关已经被置
为"offline"的空间信息“oncheck-pr |grepffline”的输出：
Chunk number 73 Flags 0x10020 Chunk is offline  
Chunk path /opt/informix/chknew/npm/hpmchk1_b Chunk offset 5
(p) Chunk size 10000000
(p) Number of free pages 6723197 DBspacenumber 38

1.3 “Onstat–d”输出当Chunk 离线后，“onstat -d”输出的"free"栏中的值通常是0，有时会被误认为是空间满不可用了，其实是chunk异常PD后导致的。“onstat-d |grepPD”的输出：
Chunksaddress chunk/dbsoffset size free bpagesflags pathnamec00000020a8434f0 73 38 5 10000000 0 PD-B /opt/informix/chknew/npm/hpmchk1_b
1.4、相应的堆栈函数中我们可以看到“sane_chopen”，“afwarn_interface”函数，表示对chunk进行sanity check,发现了错误相应的堆栈输出：
( 0) legacy_hp_afstack
( 1) afstack
( 2) afhandler
( 3) afwarn_interface
( 4) sane_chopen
( 5) chopen_util
( 6) chopen
( 7) rscon
( 8) aud_iscon
( 9) chgstat
(10) onspace
(11) startup
(12) resume
Chunk/Dbspace离线的原因多种多样，在数据库DBA寻找Informix 技术支持工程之前，应该排除诸如：物理磁盘设备损坏、硬件设备状态异常、操作系统异常导致的Informix 空间异常的情况

2 寻求问题处理的一般思路

2.1 检查相应的硬件日志、操作系统日志看是否有磁盘或硬件报错的信息；
2.2 对相应的磁盘物理设备进行硬件级检查，排除磁盘物理损坏的可能；
2.3 使用操作系统命令对相应的磁盘设备进行I/O读取检查例如:
   dd  if=/opt/informix/chknew/npm/hpmchk1_b of=/dev/null count=20000
2.4 检查相应物理磁盘设备的属组是否为 "informix:informix  660
  “例如:
   ls-lt/opt/informix/chknew/npm/hpmchk1_b
   通过上述步骤的逐一排查，将会定位空间离线的原因，根据不同的原因我们将采取不同的方法进行修复

3 如何解决、修复空间离线问题

3.1 如果是磁盘物理损坏导致了数据丢失或损坏，最终导致的Informix数据库空间异常离线，需通过磁盘修复和数据库恢复进行修复或是强行将坏掉的空间从数据库删除修复；
3.2 如果是LV切换或是LV状态异常导致的Informix数据库空间离线，而磁盘硬件未有任何的损坏，则DBA可以通过如下命令自行修复离线的空间;
     例如：onspaces-s <spacename> -p <path> -o <offset> -O -y
3.3 如果是相关的属组权限的问题，修改为正确的属组和权限（客户在进行相应的磁盘维护和划分时，有时会改变相应磁盘空间的属组和权限导致Informix数据库的离线）；
     例如：chown  informix:informix  /opt/informix/chknew/npm/hpmchk1_bchmod660 /opt/informix/chknew/npm/hpmchk1_b
3.4 如果磁盘修复后，数据并未损坏，DD操作也没有报错，备份恢复时间过长，此时可以考虑需求Informix技术支持使用内部工具尝试修复，但前提是内部工具存在风险，客户一定要有备份，以备不时之需；
3.5 按照原有的onstat -d情况，重建相关空间，备份恢复；
     备注：当部分空间离线后，建议立刻停掉所有的业务操作，因为虽然有些空间依然在线可用，但离线的空间此时不可操作，数据的一致性和业务的一致性在这种情况下很难保障。
 
4 删除作废空间的方法

Informix 空间(Chunk/Dbspace)里边存放着客户重要的生产数据和索引，非到万不得已，不建议进行空间删除操作，关键的数据库空间例如“rootdbspace”、“physical log dbspace”和“logical log dbspace”不能删除。进行删除操作前最好做好相关的备份，以便需要时进行恢复。
4.1 Informix不允许删除非空的数据库空间，所谓的非空并不是指什么信息都没有，而是指除了系统所需的53页外不允许有其他的页被使用，如果数据库空间（rootdbspace除外）仅有53页被使用，则认为是“空”可以通过“onspaces-d”删除；
例如：/home/informix/940:oncheck -petestdbsDBspaceUsage Report: testdbsOwner:
     informixCreated: 10/13/2009Chunk Pathname Size Used Free2 ./dsk/gydbs1000 53 947 
     Description Offset Size RESERVED PAGES 0 2
     CHUNK FREELIST PAGE 2 1testdbs:'informix'.
     TBLSpace3 50FREE 53 947
     Total Used: 53Total Free: 947
4.2 临时表空间可以直接通过“onspaces -d”删除；
4.3 如果有异常表或数据库存在，
通过drop table或drop database无法正常删除相关使用的空间，使用Informix技术支持内部工具强行删除，但此操作存在一定风险

本系统中数据库中参数设置如下：

ONDBSPACEDOWN   2               # Dbspace down option: 0 = CONTINUE, 1 = ABORT, 2 = WAIT
DATASKIP        off             # List of dbspaces to skip
所以第一个chunk出现问题整个dbspace就会处于D状态，虽然不是关键dbspace,但是数据库会一直等待用户dbspace正常，所以磁盘修复数据库还是可以恢复到一致性状态。

纵观解决问题的方法思路，查日志，查日志，还是查日志，包括以前的日志也要差，大胆自信的用事实说话，不要被众口铄金所误导，相信自己的判断，根本上解决问题