AUL除两个月之前增加并行扫描数据文件功能, 以节约大型数据库的恢复时间外, 最近一年内没有做过什么其他源代码修改, 不过这也并不表示AUL是十全十美的, 连十全九美都达不到. 在最近的一次恢复中就一下遇到了两处缺陷, 虽然可以绕过去, 最后成功恢复, 但缺陷还是存在的.

    当表和索引同名时, 在执行UNLOAD TABLE命令, 是根据对象名及子对象名去定位对象信息的, 因为表和索引同名, 因此要恢复表时, 会错误地取得索引的段信息, 取决于AUL读取字典生成文件时是表信息在前还是索引信息在前. 虽然早就知道表和索引可以同名, 但在自已的经历中, 创建的所有表和索引都是不重名的, 一开始也没有想到这一点. 另外在早期的版本中是不支持IOT的, UNLOAD命令只读取表, 表分区, 表子分区类型的段对象. 后来支持了IOT, 就要多读取索引, 索引分区, 索引子分区类型的段对象, 由于数据重复而引起了这个问题. 这个问题现在已经在程序上做了改进了, 当时的解决方案是生成一个只包表分区, 表子分区类型段信息的AULOBJ字典文件.

    AUL在设计初期, 还曾查阅比较多的数据库, 发现当数据库的数据文件个数小于1000个时, 数据库文件的相对文件号(RFILE)基本上是不会重复出现的, 因此就只根据相对文件号来定位, 可惜我的发现不是真理, 在一个只有几十个文件的数据库中, 居然发现相对文件号重复的情况. 实际上要根据, 表空间号和相对文件号一起来定位, 要在AUL中修复这一点则相当困难. 解决方法是一个表空间一个表空间地恢复, 不过目前为止只遇到最近的这一次, AUL还没有参与过大于1000个数据文件的恢复, 由于这个缺陷会, 当数据分成两个表空间存放, 象IOT与IOT Overflow, 象表与LOB等, 并且这两个表空间中的文件有重复的相对文件号时, AUL将无法恢复数据.

    最近这次恢复了150GB的数据, 以Dmp格式恢复, 都能正常导入, AUL5的改进相当成功.

Relative Posts:

Zemanta