首次遇到AUL恢复失败。经过一天一夜的恢复偿试，未能恢复全部记录，11月18日第一次恢复时，AUL恢复程序一直不结束，恢复出来的DMP文件一直在增长，直到用掉了所有的可用空间。11月19日用调试模式运行恢复进程，发现AUL恢复程序处于一种死循环的状态，当时的输出如下：

……
Recover rows from chained block RDBA=29371932 …
Recover rows from chained block RDBA=29371771 …
Recover rows from chained block RDBA=29371579 …
Recover rows from chained block RDBA=29371868 …
Recover rows from chained block RDBA=29371884 …
Recover rows from chained block RDBA=29371900 …
Recover rows from chained block RDBA=29371916 …
Recover rows from chained block RDBA=29371932 …
……

    由于要恢复的表中含有LONG RAW字段，里面存放的都是比较大的图片，PDF文档或WORD文档的二进制文件，从1MB到8MB不等，所以需要链接块（Chained Blocks）来用多个块存放一条记录。从上面截取的调试信息中，红色的第一行和最后一行，访问的数据块是相同的，这一点是不能理解的。当我们通过标记第一个块为损坏块后，后面又出现了类似的情况，通过求助于Oracle官方的支持网站，进行资料查找，发现有一个Bug和这种情况息息相关：

Bug 7705591 Corruption with self-referenced row in MSSM tablespace

    这个Bug已经确认会在10.2.0.2和10.2.0.4上遇到，并且目前的所有版本中都可能遇到，Oracle在这个Bug上写明，要到未来版本才能修复。这个Bug详细的英文解说如下：

A chained row (logical row continued in another row) in a table can be corrupted where the next row piece (nrid) points to itself.Data corruption resulting from a lost row piece can occur very intermittently in blocks experiencing high concurrency in MSSM tablespaces (dba_tablespaces.segment_space_management=MANUAL). It is most likely to happen but not limited to tables with a large number of columns (e.g. more than 255 columns). Without the fix of Bug 8720802 tools like DBVERIFY / RMAN / ANALYZE don’t detect this logical corruption. The fix for this bug does not repair existent corruptions.

    简单地说就是CHAINED BLOCKS形成了一个环路, 无法跳出去，如果没有打上8720802这个补丁，连Oracle的工具DBV/RMAN/ANALYZE命令等都检测不出这种情况。并且修复这个Bug也不能纠正现有的记录。在Metalink上还有其他一些有关行链接的Bug, 可以用关键字“oracle chained row corruption bug”去搜索，也可能造成记录头的混乱。

    而恢复软件能顺利恢复的基础是，要么块是完好的，要么块能免被检查出来是损坏的，但按照现状，这个Bug引起的问题，很多工具都不能检测到这种情况。AUL现在可以检测出来行链接进行死循环的情况，但无法应对其他一些有关行链接的Bug引起的逻辑损坏，目前来讲逻辑损坏会导致，恢复出来的DMP文件无法导入，引起恢复失败。