« DBA警世录:有些习惯DBA需要养成 | Blog首页 | ITPUB年会回顾-阿里巴巴的数据库管理优化体系 »
终极恢复孰弱孰强-DUL vs AUL
作者：eygle |【转载时请务必以超链接形式标明文章原始出处和作者信息及本声明】链接：http://www.eygle.com/archives/2007/02/dul_vs_aul.html
这几天在帮朋友作数据恢复，由于已经到了无可救药的地步，只能使用终极手段进行恢复，直接从文件中读取数据进行恢复。
在恢复过程中反复对比了DUL和dcba的AUL，感觉到了两者的不同。
DUL在处理文件损坏的情况下，如文件部分缺失、数据块损坏的恢复明显要弱于AUL，AUL经过几次修正之后已经能够很好的处理这些情况。
DUL可以通过如下设置跳过文件的损坏部分:
0 1 D:\DUL\DATAFILE\SYS1ORCL.DBF
1 2 D:\DUL\DATAFILE\USR1ORCL.DBF startblock 1 endblock 1000000
1 2 D:\DUL\DATAFILE\USR1ORCL.DBF startblock 1000001 endblock 2000000
1 2 D:\DUL\DATAFILE\USR1ORCL.DBF startblock 2000001 endblock 2550000
但是在扫描存在大量坏块的文件时，大量的错误信息让人崩溃；而AUL可以很容易的安静地处理这些损坏。
在处理LOB对象时，我做过测试AUL在存在SYSTEM的情况下，能够非常完美的恢复图片对象：
D:\oradata\EYGLE\DATAFILE>aul4b.exe
Register Code: 25FV-NFCH-B53H-RO9V-SZHV
AUL : AnySQL UnLoader(MyDUL) for Oracle 8/8i/9i/10g, release 4.0.1
(C) Copyright Lou Fangxin 2005-2006 (AnySQL.net), all rights reserved.
AUL> open crl.txt
* ts# fno rfn ver bsize blocks filename
- ---- ---- ---- --- ----- ---------- -----------------------------------
Y 4 4 4 a2 8192 640 O1_MF_USERS_2G8OJYYS_.DBF
AUL> scan extents
2007-02-02 10:52:09
2007-02-02 10:52:09
AUL> scan table to table.txt
2007-02-02 10:52:29
2007-02-02 10:52:29AUL> list table eygle;
UNLOAD TABLE eygle.EYGLE TO EYGLE.txt;
UNLOAD TABLE eygle.EYGLE_BLOB TO EYGLE_BLOB.txt;
AUL> UNLOAD TABLE eygle.EYGLE_BLOB TO EYGLE_BLOB.txt;
2007-02-02 10:58:16
Unload OBJD=14367 FILE=4 BLOCK=19 CLUSTER=0 ...
2007-02-02 10:58:16
AUL>
这个数据卸载或加载之后，与原数据完全相符：
E:\rec\blobtest>sqlldr eygle/eygle control=EYGLE_BLOB_sqlldr.ctlSQL*Loader: Release 10.2.0.1.0 - Production on 星期五 2月 2 11:43:32 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL*Loader-292: 加载 XML, LOB 或 VARRAY 列时忽略 ROWS 参数
加载完成 - 逻辑记录计数 2。
E:\rec\blobtest>sqlplus "/ as sysdba"
SQL*Plus: Release 10.2.0.1.0 - Production on 星期五 2月 2 11:43:41 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
连接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining optionsSQL> connect eygle/eygle
已连接。
SQL> desc eygle_blob;
名称 是否为空? 类型
----------------------------------------- -------- ----------------------------
FID NUMBER
FNAME VARCHAR2(50)
FDESC VARCHAR2(200)
FPIC BLOBSQL> select fid,fname,length(fpic) from eygle_blob;
FID FNAME LENGTH(FPIC)
---------- -------------------------------------------------- ------------
1 1.jpg 333769
2 2.jpg 300332
1 1.jpg 333769
2 2.jpg 300332SQL>
当然，DUL也有很强大的地方，比如转储文件格式等方面要优于AUL。
不过AUL最大的好处在于可以很快地得到技术支持，DCBA最近正在编写完备AUL的手册用于指导用户恢复，而且DCBA修复Bug的速度也是超快的，在这次恢复中他就为我修复了一个Bug，感谢DCBA对我的大力支持。
其实很多时候，到达用户现场后，你就只剩下一个想法，尽快帮用户最大程度的恢复数据，因为到了最后的阶段，数据已经影响到了很多人的生活，我们能做的就是尽最大可能以最快速度进行恢复。
-The End-
By eygle on 2007-02-03 20:22 | Comments (21) | Posted to Backup&Recovery | Edit |Pageviews:
留言 (21)
IT医生哦~
Posted by: Julia at February 4, 2007 12:44 AM
dcba's AUL这么牛，有机会要好好学习学习。
Posted by: ricky at February 4, 2007 9:00 PM
很多人认为自已写不出好的软件, 我当时也一样.
Posted by: anysql at February 4, 2007 9:12 PM
相信AUL会越来越强。
Posted by: eygle at February 4, 2007 9:31 PM
我自己也用dul for win ,dul for linux 都用过。aul没有用过，但去dcba 那也看过，始终有一点在脑袋里面想，如果能将用户的存储过程那些也能导出来，那就n了
Posted by: freddie wang at February 6, 2007 9:10 AM
存储过程导出来不是很容易的吗？
只要把source$表导出来就行了。
Posted by: logzgh at February 6, 2007 9:30 AM
DUL在处理文件损坏的情况下，如文件部分缺失、数据块损坏的恢复明显要弱于AUL，AUL经过几次修正之后已经能够很好的处理这些情况。
DUL无法跳过文件的损坏部分（也许是我不知道），在扫描文件时大量的错误信息让人崩溃；而AUL可以很容易的安静地处理这些损坏。
it's wrong
Posted by: good at February 7, 2007 2:01 PM
to good,
DUL可以怎样处理?请指教!谢谢!
Posted by: eygle at February 7, 2007 2:07 PM
比如我执行:
DUL> unload user bankcode ;
About to unload WANGHUI's tables ...
. unloading table TEST 24608 rows unloaded
DUL> exit
得到着个文件
2007-02-08 20:21 2,636,800 dump001.dmp
其实还有很多,我想知道,我怎么知道dump001.dmp 对应是那张表呢?
Posted by: freddie wang at February 8, 2007 8:28 PM
有字典的话，对应关系很容易建立啊!
Posted by: eygle at February 8, 2007 8:59 PM
昨日遇到一个1TB的数据仓库, system坏了. 在文件头中的DBID居然变成0了, Oracle不认这些文件了, 如果是OLTP的库, 估计我就爽了.
不过最后建议他们从1个月以前的备份中恢复,然后重新装入这一个月的数据,因为这是最好的方法.
Posted by: anysql at February 9, 2007 8:37 AM
1TB,这个AUL起来也够恐怖的了。
Posted by: eygle at February 9, 2007 10:18 AM
真要有非用不可的情况, AUL还是敢上的.
Posted by: anysql at February 9, 2007 1:32 PM
DUL> unload user bankcode ;
About to unload BANKCODE's tables ...
. unloading table TEST 24608 rows unloaded
DUL> exit
Life is DUL without it
得到文件dump001.dmp
SQL> select user#,name from user$ where name='BANKCODE';
USER# NAME
---------- ------------------------------
41 BANKCODE
SQL> select obj#,owner#,name from obj$ where owner#=41;
OBJ# OWNER# NAME
---------- ---------- ------------------------------
24825 41 TEST
SQL>
请问到底哪个编号和dump001.dmp有关系呢？请问我从哪里可以知道dump001.dmp
这个文件对应哪个表呢？
Posted by: freddie wang at February 11, 2007 5:54 PM
你在unload user bankcode时
输出的表名和导出文件是按顺序命名的。
. unloading table TEST 24608 rows unloaded
Posted by: eygle at February 11, 2007 6:28 PM
data object id
Posted by: anysql at February 12, 2007 10:35 AM
C:\>sqlldr 'sys/whi@db001 as sysdba' control='F:\data-work\dul\dul8\OBJ.ctl'
log='c:\log.txt'
SQL*Loader: Release 8.1.7.0.0 - Production on 星期三 2月 14 11:58:12 2007
(c) Copyright 2000 Oracle Corporation. All rights reserved.
SQL*Loader-601: 對 INSERT 選項而言, 表格必須是空的. 表格 "OBJ$" 上有錯
C:\>sqlldr 'sys/whi@db001 as sysdba' control='F:\data-work\dul\dul8\USER.ctl'
log='c:\log.txt'
SQL*Loader: Release 8.1.7.0.0 - Production on 星期三 2月 14 12:22:27 2007
(c) Copyright 2000 Oracle Corporation. All rights reserved.
SQL*Loader-601: 對 INSERT 選項而言, 表格必須是空的. 表格 "USER$" 上有錯
C:\>
我创建了新库,但数据怎么导不进去,请问这里该采用append ?
Posted by: freddie wang at February 14, 2007 12:27 PM
晕，系统对象你还load进去干嘛?
user$表是字典表啊!
Posted by: eygle at February 14, 2007 1:55 PM
C:\>imp 'sys/change_on_install@db001 as sysdba' file='F:\data-work\dul\dul8\dump
001.dmp' log='c:\dump.log' buffer=1000000 ignore=y feedback=10000 grants=N full=
y
Import: Release 8.1.7.0.0 - Production on 星期三 2月 14 14:17:31 2007
(c) Copyright 2000 Oracle Corporation. All rights reserved.
連接到: Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
經由傳統路徑, 由 EXPORT:V07.00.07 建立的匯出檔
警告: 這些物件是由 Bernard's DUL (而非您) 匯出的
. 正在將 Bernard's DUL 的物件匯入 SYS 中
. . 正在匯入表格 "TEST"
..
匯入了 24608 列
匯入作業在不含任何警告的情況下順利終止
C:\>sqlplus /nolog
SQL*Plus: Release 8.1.7.0.0 - Production on 星期三 2月 14 14:18:17 2007
(c) Copyright 2000 Oracle Corporation. All rights reserved.
SQL> connect / as sysdba ;
已連接
SQL> select count(*) from test ;
COUNT(*)
----------
24608
============================================================================
数据我已可以导进取，我是想将user$和source$的信息能拿出来，请问是不是
unload table sys.user$
unload table sys.source$
出dump文件，imp进取呢？
Posted by: freddie wang at February 14, 2007 2:25 PM
已经都搞明白了,谢谢大家.
Posted by: freddie wang at February 15, 2007 10:12 AM
请问DUL要unload出ASSM的表空间是不是有特殊的要求呢？
scan database
后我执行的时候总是得到类似错误：
DUL> unload user ykk1;
About to unload YKK1's tables ...
. unloading table USERINFO
DUL: Error: Block Type 35, not a segment header type
DUL: Error: While processing block ts#=9, file#=37, block#=311699
0 rows unloaded
.......
对于segment space management manual的表空间uload就没有问题。
Posted by: overmars at February 16, 2007 7:20 PM
