AnySQL.net

    在AUL中有几个命令(OSDUMP, UNLOAD, ORADUMP, BCHECK, CORRUPT, ROWID)可以用RDBA来指定一个Block的地址, 很多人都知道相对块地址(RDBA, 一个32Bit的不带符号的正数, Relative Data Block Address)其实由文件号(RFILE#, 前10个Bit)和块号(BLOCK#, 后22个Bit)组成, 在DUMP或其他很多地方, 引用RDBA时都是用十六进制的数值来表示的. 在本文之前, 在AUL中不能指定一个十六进制的值, 你必须先换算成十进制的值来指定, 这具有一定的不方便性, 因此我对这个作了一点改进, 可以用0x开始来指定一个十六进制的值.

    下面的这个例子来恢复某一个块的记录:

AUL> unload object 10102 rdba 0x0180000f column number char char;
2007-01-29 23:38:38
10|ACCOUNTING|NEW YORK
20|RESEARCH|DALLAS
30|SALES|CHICAGO
40|OPERATIONS|BOSTON
2007-01-29 23:38:38

    接下来再看一下另一个很有用的命令, 构造或分解一个Oracle Row ID:

AUL> rowid create object 10102 rdba 0x0180000f slot 0

OBJD  = 10102
RDBA  = 0x0180000f = 25165839
RFN#  = 6
BID#  = 15
SLOT  = 0
ROWID = AAACd2AAGAAAAAPAAA

AUL> ROWID PARSE AAACd2AAGAAAAAPAAA

OBJD  = 10102
RDBA  = 0x0180000f = 25165839
RFN#  = 6
BID#  = 15
SLOT  = 0
ROWID = AAACd2AAGAAAAAPAAA

    忽以善小而不为, 发现有需要并且能改进的地方, 一律改进.

    今日eygle发现一个AUL的小问题, 在没有SYSTEM表空间时运行"SCAN TABLE"命令的输出中的UNLOAD命令居然没有列的类型信息, 按理说应当是有的. 在仔细思考后, 在本机成功地模拟出类似情况. 这是因为SCAN TABLE命令在跑时, 总是从文件头读到文件未, 当发现有一个块是表的数据或IOT的数据后, 就根据块中记录的记录条数字节来确定是否用这个块为猜测的样本块, 而实际上, 这个记录条数字节中的记录数也包括了已经删除的记录.

    假设有一前一后两个数据块都属于同一个表, 在前一个块中的记录都已经被全部清楚掉了, 只有后面一个数据块有真实的数据, 这时运行SCAN TABLE将不能得到列的信息, 因为AUL只扫描了第一个数据块, 并将这个块对应的Data Object ID记录在完成列表中, 下次遇到同样的Data Object ID的块时, 就跳过去了, 因此当扫描到第二个数据块时, AUL就不作这个块的分析了.

    为此我在程序中新增了一个计算有效记录数的函数. 有效记录必须是:

1, 字段数大于0的, 以防止所有字段全为空的记录.

2, 不能是标记为已被删除的记录.

3, 必须是整个记录的第一段, 记录可能存在链接(Chain)的情况.

    接下来在扫描块之前检查一下这个块有没有有效记录, 如果有分析它, 否则跳过这个块, 这样输出的信息将有用很多. 鉴于这个改进, 将版本升级到了3.2.4.

    对于AUL 4也作了同样的改进, 并将版本改成了4.0.1.

    周四晚上先将电脑背回家并开机上网, 然后和朋友一起出去吃饭, 回来时发现有陌生人加了我的MSN和Skype, 用英文说是要购买一个AUL的许可证(来自意大利). 将其加入到好友列表中后, 就问他遇到了什么问题, 对方说是有一个1TB大小的数据库坏了, 刚听到时我开心, 这下年终奖有着落了. 当然紧张的心情也是有的, 因为AUL从没有遇到过那么大的数据, 最大的一次是05年70GB的恢复. 于是我继续问他到底是什么回事, 原来是遇到了ORA-01221错误, 这个错误是指Oracle认为这个数据文件的格式是坏的, 从错误手册上可以找到这样的解释:

When the database writer opens the datafile, it is accessing a different physical file than the foreground doing the recovery. The timestamp set in the file header by the foreground was not found by the background. It may be that the background process could not read the file at all.

    于是我要求他将alert_sid.log中的最后1000行给我, 最后他给了5000行, 没有发现有用信息, 因为他从周三开始就一直在用open resetlogs, 说是Oracle Forum上的一个Oracle Expert建议的. 最后我上传了AUL, 打开了几个文件, 用"ORADUMP FILE n BLOCK 1"去看这几个文件头情况, 发现了很奇怪的情况, 在文件头中其他的字段都能读出来, 就只有DBID读不出来, 值全为0, 如下所示:

AUL> oradump file 1 block 1
RDBA=0x00400001(1/1),type=0x0b,fmt=0xa2,seq=0x01,flag=0x04
DBID=0x00000000=0,db=ORCL,ts#=0,ts=SYSTEM,file#=1, blksiz=8192, blks=344320, ver=0x0a200100, fzy=--O-
AUL>

    连续看了几个文件都是这样, 一开始以为是AUL的问题, 我就让他用AUL去看一下刚建好的数据库文件的文件头, 发现是可以成功地取出DBID的信息的, 对方进一步用AUL检查了从1个月以前备份中恢复出来的文件, DBID也是好的. 他在SHUTDOWN IMMEDIATE时遇到这个错误, 其中Online Fuzzy标志又被设上, 因此可能的原因是在数据为打开时, 数据文件的文件头被改掉了, 因此在关闭时失败, 从尔保留了Online Fuzzy这个标记, 这个猜测很有道理. 附合ORA-01221这个错误号.

    他找我的原因是以为AUL可以重建SYSTEM01.DBF, 但是AUL只能从数据文件中读出数据, 并不可能去更改数据文件中的任何地方. 一个数据仓库的10g版本数据库运行在基于x86-64硬件平台的RH 4上面, 不知道会是什么原因将文件头改掉了, 我从10.2.0.2和10.2.0.3的Bug修复列表, 也没有找到有关的Bug. 当我告诉他AUL不能重建SYSTEM01.DBF, 并且最好的方法是从备份中恢复, 然后重新装载最近一个月左右的记录(因为是数据仓库, 这是完全可能的)后, 他再次去请示了老板, 最后没有购买许可证. 虽然我没有赚到年终奖, 但我们应当为客户作出最佳的方案, 其实在这个例子中, AUL也可以用于去恢复最近一个月的数据, 省下他们的ETL的时间.

    做技术的也不能靠欺骗去赚人家的钱, 或纳税人的钱.

    一月份在网上发现AUL被破解的信息, 周五早上一网友发给我如下消息:

AUL> set licence 00EFBFBF
  Registered, Elapsed: 725

    这证明了AUL的确被破解了! 整个程序中最弱的环节可以就是在这儿了, 虽然这个许可证的模型很好. 我不是计算机科班出生的, 大学时数学这门课还学得特差, 要不也搞个比较复杂的线性代数, 距阵运行等算法进去. 不过破了就破了好了, 连Microsoft的Vista都在几天内遭人破解(Keznews论坛上一个名为"Snooza"成员日前破解了Vista的正版验证程序. 方法很简单: 暴力破解. Snooza所开发的一款软件程序可以生成Windows Vista密钥, 并可以成功激活Vista. 经过该论坛的其他成员测试, 该破解方法是有效的.).

    这一破解对我会有什么影响呢? 我想不多. 第一, 破解者说只是个人玩玩而已. 第二, 我会经常改进程序的. 第三, 将暂停AUL用户指南的编写. 第四, 这软件用的机会很少. 第五, 没有我的支持, 很难进行复杂的恢复. 所以我无所谓.

    下次等他上线时, 我问问他是如何破的, 看这个样子, 好象是直接读出了我计算好的Licence的值的, 而不是反向搞出算法, 如果这样只有在运行AUL的机器上才能进行破解. 正在思考改变这种方法, 这个结果可能不好玩, 但过程肯定是不错的.

    AUL 4是在AUL 3的基础上加上了对Oracle BLOB/CLOB数据类型的支持, 于2006年12月份开始修改工作, 于2007年1月份发布了Beta版本. 在经历一次正式的恢复需求后会将Beta版本发布为正式版本, 现在已经到时间了. 不久前成功地为一个外国客户恢复了一个有BLOB字段的表, 总共恢复了12922个图片/PDF/DOC等文件, 恢复出来的数据成功地得到了客户的认同, 图片打开没有问题, 只有少数(小于10个)的PDF文件打开后是空白页, 这就不确定是谁的问题了. 因此郑重宣布AUL 3退役, AUL 4版本正式开始战斗, 最新的版本是4.0.2.

    需要非常感谢客户对我的支持, 在这一次恢复中, 原来用的是Beta版本直接拷贝出来的4.0.1版本, 在恢复过程中遇到了两处Bug问题, 客户很仔细很耐心地支持我对Bug的修改, 这种配合精神我在国内的客户中少有遇到. 除了遇到Bug找过我之外, 这位国外客户仔细阅读我的英文Blog上的文档, 没有问过我什么问题, 这一点我们更需要向他们学习了. 这次修复的Bug主要有两处:

• 1, 在Chained或Migrated行中存放的LOB字段不能恢复.
    原因: 没有将LOB索引的信息传给处理Chained和Migrated记录的子程序.
• 2, 一个表中有多个LOB字段时, 第二个及以后的LOB字段不能恢复.
    原因: 没有准确地取得第二个及以后的LOB字段的索引信息.

    在我的主页上已经下载不到AUL 3了, AUL 3的下载连接入口已经被指向了AUL 4的下载地址. 下一个版本5将要增加压缩表和压缩索引的支持, 但不知道哪是何年何月的事情了.