« DBA警世录:有些习惯DBA需要养成 | Blog首页 | ITPUB年会回顾-阿里巴巴的数据库管理优化体系 »
终极恢复孰弱孰强-DUL vs AUL
链接:https://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) | Backup&Recovery | 1344 |
IT医生哦~
dcba's AUL这么牛,有机会要好好学习学习。
很多人认为自已写不出好的软件, 我当时也一样.
相信AUL会越来越强。
我自己也用dul for win ,dul for linux 都用过。aul没有用过,但去dcba 那也看过,始终有一点在脑袋里面想,如果能将用户的存储过程那些也能导出来,那就n了
存储过程导出来不是很容易的吗?
只要把source$表导出来就行了。
DUL在处理文件损坏的情况下,如文件部分缺失、数据块损坏的恢复明显要弱于AUL,AUL经过几次修正之后已经能够很好的处理这些情况。
DUL无法跳过文件的损坏部分(也许是我不知道),在扫描文件时大量的错误信息让人崩溃;而AUL可以很容易的安静地处理这些损坏。
it's wrong
to good,
DUL可以怎样处理?请指教!谢谢!
比如我执行:
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 对应是那张表呢?
有字典的话,对应关系很容易建立啊!
昨日遇到一个1TB的数据仓库, system坏了. 在文件头中的DBID居然变成0了, Oracle不认这些文件了, 如果是OLTP的库, 估计我就爽了.
不过最后建议他们从1个月以前的备份中恢复,然后重新装入这一个月的数据,因为这是最好的方法.
1TB,这个AUL起来也够恐怖的了。
真要有非用不可的情况, AUL还是敢上的.
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
这个文件对应哪个表呢?
你在unload user bankcode时
输出的表名和导出文件是按顺序命名的。
. unloading table TEST 24608 rows unloaded
data object id
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 ?
晕,系统对象你还load进去干嘛?
user$表是字典表啊!
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进取呢?
已经都搞明白了,谢谢大家.
请问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就没有问题。