eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« DBA警世录:有些习惯DBA需要养成 | Blog首页 | ITPUB年会回顾-阿里巴巴的数据库管理优化体系 »

终极恢复孰弱孰强-DUL vs AUL
modb.pro

这几天在帮朋友作数据恢复,由于已经到了无可救药的地步,只能使用终极手段进行恢复,直接从文件中读取数据进行恢复。

在恢复过程中反复对比了DULdcba的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:29

AUL> 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.ctl

SQL*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 options

SQL> connect eygle/eygle
已连接。
SQL> desc eygle_blob;
名称 是否为空? 类型
----------------------------------------- -------- ----------------------------
FID NUMBER
FNAME VARCHAR2(50)
FDESC VARCHAR2(200)
FPIC BLOB

SQL> 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 300332

SQL>

当然,DUL也有很强大的地方,比如转储文件格式等方面要优于AUL。

不过AUL最大的好处在于可以很快地得到技术支持,DCBA最近正在编写完备AUL的手册用于指导用户恢复,而且DCBA修复Bug的速度也是超快的,在这次恢复中他就为我修复了一个Bug,感谢DCBA对我的大力支持。

其实很多时候,到达用户现场后,你就只剩下一个想法,尽快帮用户最大程度的恢复数据,因为到了最后的阶段,数据已经影响到了很多人的生活,我们能做的就是尽最大可能以最快速度进行恢复。

-The End-


历史上的今天...
    >> 2006-02-03文章:
           DBA生存守则之三

By eygle on 2007-02-03 20:22 | Comments (21) | Backup&Recovery | 1344 |

21 Comments

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

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就没有问题。


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com