DUL is Life

on

系统情况如下:
1. Oracle版本是10.2.0.1,操作系统是Linux x86-64
2. 数据文件存储在OCFS2上
3. 需要恢复的表是普通表
4. 未知故障引起online日志文件损坏,使用隐含参数启动数据库之后,已经将大部分表通过exp导出到新库中,但是个别表无论是使用exp还是使用select都会报ORA-01555 snapshot too old错误,很明显回滚段数据存在不一致。

由于只有小部分数据无法导出,因此决定使用DUL直接从数据块中读取数据。

对于OCFS2文件系统无需特殊处理,在control.dul中按照路径写入系统表空间数据文件和故障表所处的用户表空间数据文件即可。

由于system表空间正常,数据字典都存在,因此unload table的过程很简单,bootstrap之后直接unload table即可。

这次unload出的表中最多记录数为580万多。

最后将生成的dat文件通过SQL Loader加载回新建的数据库中,对于中文的处理需要将操作系统NLS_LANG环境参数设置为跟数据库字符集相同。

本来这次想测试老熊的ODU执行效率,很可惜,在执行linux版本的odu时报无法找到某lib,因此作罢(由于时间充裕,在等待后续处理的过程中,将系统表空间文件和其中一个数据文件ftp到windows中,然后使用windows版本的odu测试了一下,unload table功能完全正常)。

5 Comments Add yours

  1. anysql says:

    昨天整了一把, DUL/AUL is not Life, 用正常方式搞定.

  2. 老熊 says:

    昨天修改了一下编译选项,使用静态链接,不再需要那个动态链接库了。

  3. Kamus says:

    @anysql
    案例不同,适合的解决方案也不同。

    @老熊
    一会儿去下载新版 😀

  4. hoterran says:

    其实dul/aul 都该静态编译,程序大点又有何妨呢。否则恢复的时候,还要设置一大堆的LD_LIBRARY_PATH。

  5. tiffany says:

    yes, i think so too, this is a very amazing website, something really worth to read.

Leave a Reply

Your email address will not be published. Required fields are marked *