AnySQL.net

    周四晚上先将电脑背回家并开机上网, 然后和朋友一起出去吃饭, 回来时发现有陌生人加了我的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的时间.

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