今天AUL遇到了一个特别的数据, 虽然System表空间都是好的, 但却无法UNLOAD字典信息, 从而无法很好地恢复数据. 第一个特别的现象是, 数据库的第一个数据文件, SYSTEM表空间的第一个数据文件的RFILE#列不为1, 这是我第一次见到.
* ts# fno rfn ver bsize blocks filename
- ---- ---- ---- --- ----- ---------- -----------------
Y 0 1 4 02 8192 128000 system01.dbf
Y 0 10 10 02 8192 64000 system02.dbf
另外AUL所需要读的几个系统表也有特别的地方, 我从DBA_OBJECTS中查这几个表的DATA_OBJECT_ID, 发现他们都很大. 不明白的这些系统字典表的Data Object ID是如何被搞得这么大的?
11412 COL$
11424 OBJ$
11412 TAB$
11416 USER$
看来还是得从SYSTEM表空间数据文件的文件头取得BOOTSTRAP$的地址, 然后从BOOTSTRAP$中取得相关的系统表(USER$,OBJ$,TAB$,COL$)的信息进行处理.
此数据库为ERP数据库, 好象是Oracle Finacials数据库, 难道和我们普通创建的数据库的不一样?
留言 (11)
数据库是从Oracle 7升上来的，那时跑了migrate.bsq, 所以这些对象的Object ID和Data Object ID都很大.
Posted by anysql | Nov 14, 2007 9:06 AM
深，真的好像在自言自语啊
Posted by victor666666 | Nov 14, 2007 12:22 PM
意料之中啊.
Posted by anysql | Nov 14, 2007 12:27 PM
看来测试AUL要从0racle 7做起了。
Posted by vongates | Nov 19, 2007 11:12 AM
应该象真正的引导程序那样，读取bootstrap内容，分析数据字典的相关信息！我现在已经看到四个写unload程序的哥们都是固定读取bootstrap区,并且数据字典对象的id、头块都是固定的，这是不对的！尤其是对Oracle EBS系统，安装时的脚本和DBA正常实施数据库的习惯很不一样，一测便知！
Posted by truezxd | Nov 19, 2007 11:22 AM
因为EBS系统后台的库都是从Oracle 7升上来的.
Posted by anysql | Nov 19, 2007 11:30 AM
是个很奇怪的数据库，不过这个已经被我们恢复出来了。费了很长时间。DUL对这个数据库都不行，里面结构很奇怪，不仅仅上面的问题。
Posted by kh | Nov 20, 2007 11:03 PM
如果我在现场的话, 也是能恢复的, 后面搞清楚了, 只是远程操作太慢了.
Posted by anysql | Nov 21, 2007 6:27 AM
我们并没有现场,呵呵
Posted by kh | Nov 21, 2007 8:56 PM
还是用这类工具搞的.
Posted by anysql | Nov 21, 2007 9:07 PM
看来kh厉害阿，哈哈
Posted by TOM | Apr 22, 2008 11:14 AM