AnySQL.net

    通过二十分钟的发呆, 进入了研究Oracle压缩(Compress)表的大门, 随之而来的这几天, 研究得很顺利, AUL 5的测试版发布了. 知道Oracle DUL 10版本支持压缩表后, 心中一直就有一个结, 如今这结已经打开, 剩下的只是多做些测试去发现Bug并解决Bug了. 在对Oracle文件格式的研究中, 我找到了自已的DBA激情, 那就是研究Oracle的兴趣, 给平静的DBA生活增加了一些特有的颜色.

    由于程序设计当初没有考虑压缩表的需求, 这一次的变动很大, 处理一个数据块内记录的函数(如printDataRows函数), 已经全部重写. 因此在最近一段时间内, AUL 5还不适合作为正式数据恢复的版本, 除非你需要恢复Compress表. 当然欢迎大家来对AUL 5进行测试, 测试方法如下:

1, 创建一个压缩表T_COMPRESS

2, 用AUL 5进行恢复(恢复步骤)

3, 将恢复出来的记录装载到非压缩表T_NOCOMPRESS中

4, SELECT * FROM T_COMPRESS MINUS SELECT * FROM T_NOCOMPRESS

5, SELECT * FROM T_NOCOMPRESS MINUS SELECT * FROM T_COMPRESS

    理想的结果是第四步和第五步中的SQL都返回0条记录. 开发这个功能时, 用于测试的数据库版本是Oracle 10g, 欢迎大家在Oracle 9i和Oracle 11g上进行测试.

    Update: Linux版本下载, Solaris版本下载

    在完成对Compress表的支持后, AUL/MyDUL已经相当完美了. 很有必要来回忆一下它的版本发展历史, 从2004年年底开始构思以来, 已经经历三个春秋了. 很多人知道我这个人也是因为这个工具, 否则我不名一文.

年份	版本	简介
2004年底	1.0.0	因为看见ITPub上Block格式Dump的文章, 加点注释, 就成了精华贴了, 于是想能不能进一步发展一下, 想想中国不备份的数据库那么多, Oracle DUL是那么地难以获得, 就决定动手了. 那时我只会用Java, 于是就用Java去写了, 到后来取名为MyDUL时, 难怪有人硬要说我是抄jDUL开源项目的.
2005	2.0.0	当用Java编的第一版能读出数据后, 发现Java用来处理这个并不方便, 同时也在考虑做成后, 如何保护我的代码, 因为我也用jad轻松地反向编译过少量的Java类, 因此觉得不保险. 另个一个是觉得第一版的程序结构不合理, 要从头再来, 就换成十多年没有用的C了. 同时也接到了从香港来的第一个恢复请求.
2005	3.0.0	在测试Long及Long raw数据类型时, 发现文本方式对他们不是很合适, 因此加上了对DMP格式的支持. 但DMP格式的支持还是不成熟的, 因为用这个进行恢复时, 数据库上或多或少地都存在一些块坏, 恢复出来的dmp文件很容易不被imp接受. 在这一年中花了很多时间去测试和发现Bug, 并修复他们, 那是研究和开发得最累的一年, 都感觉要少活几年了, 常常为了它睡不好觉.
2006	4.0.0	偶儿遇到了少量带LOB的表需要恢复, 在那以前, 都是跳过这些表的, 但为了让AUL活得更久, 必须要加上对它的支持. 加上这部份功能所花的时间很短, 也很轻松. 因为在05年时我已经开始思考LOB类型和Compress表了. 作过两次正式的LOB恢复, 每次都是大约1万张图片左右.
2007	5.0.0	由于Compress的复杂性, 一直不得要领, 直接今年年底的某一天, 发呆了20分钟后发现了门路. 花了一个星期搞出支持Compress表AUL 5的Beta测试版了.

    在这三年中, 我体会到了坚持两个字, 也从坚持中体会到快乐.

    为了加上压缩(Compress)表的支持, 完全重写了几个处理块内记录的重要函数, 没想到改完后测试, 发现对DMP格式恢复支持的更好了. 用最新的AUL 4去将"SYS.IND$"恢复成DMP文件, 在导入时发现这个DMP文件不能使用, 遇到了以下错误.

import done in UTF8 character set and AL16UTF16 NCHAR character set
export client uses US7ASCII character set (possible charset conversion)
. importing MYDUL's objects into SH2
. . importing table                         "IND$"
IMP-00020: long column too large for column buffer size (22)
IMP-00028: partial import of previous table rolled back: 1100 rows rolled back
Import terminated successfully with warnings.

    而我用AUL 5测试版本时, 导入就完全没有问题.

import done in UTF8 character set and AL16UTF16 NCHAR character set
export client uses US7ASCII character set (possible charset conversion)
. importing MYDUL's objects into SH2
. . importing table                         "IND$"       1176 rows imported
Import terminated successfully without warnings.

    在SQL*Plus中用两个Minus操作去检验一下恢复出来的结果.

SQL> show user
USER is "SYS"
SQL> select * from ind$ minus select * from sh2.ind$;

no rows selected

SQL> select * from sh2.ind$ minus select * from ind$;

no rows selected

    可以看到恢复的结果完全准确, 这真是意外的收获, 热列推荐使用AUL 5来进行恢复.

    今天比较好奇地统计了一下AUL源代码的行数, 想想自已这三年以来为这个软件写了多少行代码, 发现并没有我想象的那么多. 以为早到了一万行了, 原来还差一些.

    DMP格式文件的接口部分.

C:\mydul-b5>wc -l dmpfile.*
    245 dmpfile.c
     41 dmpfile.h
    286 total

    解释Oracle块格式的部分.

C:\mydul-b5>wc -l block.*
   5795 block.c
    438 block.h
   6233 total

    AUL命令行软件部份.

C:\mydul-b5>wc -l mydul.*
   3443 mydul.c
    105 mydul.h
   3548 total

    的确, 对一个产品来说, 大约一天写10行代码就足够了. 最近AUL还被用了一次问题追踪.

    本想将这种情况下的恢复步骤永远藏在心中的, 因为它在实际生活中太难以恢复了. 看到有人真的遇到了这种情况, 我还是将恢复的步骤写一下吧. 先来创建一个表空间及带BLOB字段表.

SQL> CREATE TABLESPACE LOBDATA
  2    DATAFILE 'C:\oracle\oradata\db10g\lobdata01.dbf' size 24m
  3    extent management local uniform size 128K
  4    segment space management manual;

Tablespace created.

SQL> CREATE TABLE T_LOB (COL1 NUMBER, COL2 BLOB) TABLESPACE LOBDATA;

Table created.

    接下来插入几条记录, 并提交, 再进行Checkpoint和Drop表的操作. 然后我们拷出这个表空间的文件进行恢复. 先来看一下这个表空间中有什么Segment.

AUL> scan header
2008-02-21 19:39:16
RDBA=0x02000009(8/9),type=0x10,fmt=0xa2,seq=0x01,flag=0x04
seg/obj=0x00002ef0=12016

RDBA=0x02000029(8/41),type=0x10,fmt=0xa2,seq=0x01,flag=0x04
seg/obj=0x00002ef2=12018

2008-02-21 19:39:16
AUL>

    在这里可以找到两个, 一个是表的, 一个是LOB索引的, 无法区分? 那就扫描一下数据好了.