关于Informix数据库页损坏的问题与处理建议

问题

Informix数据库的页损坏是一种比较常见故障，损坏的位置可能是表的索引页、表的数据页以及系统页，而系统页又以用于Chunk空间管理的Chunk Free List页为主。

数据库页损坏并不是指存储数据的磁盘页有问题，而是指数据库相应页上的内容不对，包括时间戳不匹配或与相应的数据页不符等。如果是磁盘设备有问题，一般会体现在I/O操作错误上。

引起数据库页损坏的原因是多方面的，主要有数据库产品的BUG、操作系统以或硬件（主要是磁盘设备）的故障以及应用特点等。故障所引起的后果和处理的方式也不尽相同。

近期有多个省的Informix数据库出现了页损坏的情况，造成了一定的损失，这里针对一些典型的故障和处理进行介绍。

索引页损坏

索引页损坏是后果最轻的一种故障，一般在使用有问题的索引时才会发生，会造成操作的终止，但一般对该表的数据以及整个数据库没有什么影响。出现索引页损坏时，一般会在消息日志文件中进行记录，典型的日志信息如下所示：

20:34:20 Who: Session(559914, npmuser@npmdb, 9442, 4a123bfb0)
Thread(1651930, sqlexec, 4a90aa520, 6)
File: exfmsupp.c Line: 947
20:34:20 Results: Delete failed
20:34:20 Action: Run 'oncheck -cI npmdb:"informix".tac_task_monitor# 1405_11482'

索引页损坏与数据库内部对索引的处理机制有关，一般在更新数据时，相应的索引更新并不是同步的，在修改数据的同时，只是对相应的索引键值项进行标记，并由数据库的其他线索来进行事后的更新，因此当某些特定的数据库异常发生后，有可能会造成索引与数据不符的情况。

当发生索引页损坏时，一般在消息日志中会准确地记录有问题的表和索引，并提示相应的oncheck –cI命令，通过此命令可以确认索引是否有问题。

针对索引页损坏的情况，采取的措施是首先删除该索引，然后重建些索引，即可消除此故障。

数据页损坏

数据页损坏是指存放实际数据的页出现问题，一般是指页的首、尾时间戳不匹配，系统会认为该页并没有完整地从内存刷新到磁盘上，因而认为该页的内容有问题。

数据库页损坏的典型现象是在访问有问题的表或记录时报-243（无法定位一条记录）的错误，同时在消息日志中也有明确的记录。一般数据页的损坏只会影响对该页上的记录的访问，而同一表中的其他记录仍然可以访问。

数据页的损坏一般是由于操作系统或硬件的内部不稳定造成的，从实际的案例来看，往往是一个系统出现一次之后，还可能会反复出现，因此应该及时检查操作系统和硬件以及更新系统PATCH。

出现数据页损坏后，该页所存放的记录会丢失，如果有最新的数据备份，可以通过备份来恢复。由于只是一张表出现问题，可以使用文本格式的数据备份来进行恢复，如dbexport或unload的数据。

如果没有备份发，或备份较旧，则需要先将该表的数据卸载下来，如unload命令。但要注意的是，当访问到有问题的页时，卸载操作本身也会终止，此 时应记录下已经卸载的数据，通过选择条件跳过有问题的记录，然后将其它的数据卸载下来。（建议使用ROWID作为选择条件，有问题的记录的ROWID是连 续的，这样可以通过不断尝试来跳过该组记录。）

卸载完成后，可以通过删除并重建该表的方式消除此故障。

系统页损坏

虽然发生的可能性不大，但系统页损坏的后果是最严重的，根据出现的位置不同，造成的损失以及采取的措施也不尽相同。

目前在移动中出现的系统页损坏出现是用于chunk管理的chunk free list页出现问题。造成的原因主要是产品的BUG以及应用中高强度的数据修改引起频繁的空间分配操作所造成的。典型的消息日志如下所示：

04:41:19 Assert Failed: Page Check Error in challoc:bad chunk free list page
04:41:19 Who: Session(12493234, npmuser@sxmd6, 10202, 199204160)
Thread(21614998, sqlexec, 1991cd6b8, 3)
File: rsdebug.c Line: 1047
04:41:19 Results: Possible inconsistencies in a Chunk Freelist page
04:41:19 Action: Run 'oncheck -ce' and/or restore affected DBSpace

chunk free list页损坏的结果是无法进行新的空间分配，即无法进行数据的插入操作，严重时系统会直接将该chunk标记为DOWN，不再使用该设备。

chunk free list页损坏一般只有通过重建该chunk的方式解决，即先将该chunk从数据库中删除再重新加入，此时系统会对该chunk进行初始化。IBM有一些内部工具可以对chunk的状态进行调整，但由于相应页的数据已经被破坏，修复的可能比较小。

由于目前移动网管的数据量较大，卸载和恢复数据的时间较长，因此这类故障对业务的影响是比较大的。

系统页损坏的情况很多，原因也比较复杂，有一些原因已经明确为产品BUG，有些则还不能确认是已知的BUG，因此应在适当的时候对数据库产品进行更新，以避免可能的BUG。

管理建议

• 在适当的时候将数据库系统升级到同系列的最高版本，目前IDS　7系列的最高版本是7.31，而IDS　9系列的最高版本是9.4FC6。
• 加强数据备份的管理，考虑到数据量较大，除备份频率较低的系统备份外，还应针对特定的数据（如汇总后的数据）制定相应的应用数据备份方案。
• 适当扩充系统资源，主要是磁盘设备，如果磁盘设备充分，可以采用快速建立应急数据库实例或空间的方式，加快数据卸载和恢复进程，从而缩短业务中断时间。