Oracle恢复（DUL+ODU）

背景：经分数据集市2库准备迁移，业务人员误操作将一个表空间从数据库中直接drop掉，且此部分数据为配置表，无法通过应用来恢复，需要通过其他手段来恢复数据。数据库中已经没有了表空间以及表空间中对象的定义，所以只能通过直接读取数据文件来进行恢复。本次恢复使用了两个工具，即是DUL和ODU。

环境：redhatlinux 5.6  oracle 10.2.0.4 单机裸设备

一、ORACLE官方恢复工具DUL

DUL 是oracle内部使用的一个工具，不是一个商用化的产品，Oracle不卖、不提供也不支持它的使用。DUL只有在Oracle 的内部网站才可以下载到，一般只能从Oracle售后才能获取到。不同的平台、不同版本的数据库都有相应的DUL 软件，版本9.x 及之前DUL 是没有License 限制的，也就是有这个工具可以无限制的使用，从版本10.x开始用了时间限制，一般到手只能用一个月，不过可以通过修改系统时间来规避（用到的数据文件的日期也要通过工具来做相应修改）。

1、配置文件

1.1 参数据文件:init.dul

参数文件是dul运行必需的文件，用于设定DUL运行中的各个参数及指定DUL的运行模式等内容，例如缓存的大小、Oracle数 据块的大小及输出文件格式等参数。Dul的运行参数分为四类，即数据库配置参数、数据字典缓存信息参数、操作系统相关参数及其它常用参数。

[root@blade34 dul4x86-linux]# cat init.dul

osd_big_endian_flag=false

osd_dba_file_bits=10

osd_c_struct_alignment=32

osd_file_leader_size=1

osd_word_size=32

control_file=/bi_bak/dul4x86-linux/control.dul

db_block_size=8192

compatible=10

dc_columns=20000000

dc_tables=100000

dc_objects=1000000

dc_users=1400

dc_segments=100000

export_mode=false

注释：

OSD_BIG_ENDIAN_FLAG

确定dul所工作的操作系统平台是不是byte-swapped的，通常HP,SUN平台machine word是big endian的，即osd_big_endian_flag=TRUE，DEC和Intel平台是little endian的，即osd_big_endian_flag=FALSE。

OSD_DBA_FILE_BITS

数值类型。这个参数表示的是数据块地址中用于文件数低次序部分的位数。不太好理解，不过这不是问题的关键，知道如何设置，设置多大的值就可以了。

执行如下的语句，不同的返回结果这个参数该设成不同的值。

SQL>select dump(chartorowid(‘0.0.1’)) from dual;

Typ=69 Len=6: 8,0,0,0,0,0 -> osd_dba_filebits = 5 (SCO)

Typ=69 Len=6: 4,0,0,0,0,0 -> osd_dba_filebits = 6 (Sequent , HP)

Typ=69 Len=6: 1,0,0,0,0,0 -> osd_dba_filebits = 8 (NCR,AIX)

Typ=69 Len=6: 0,16,0,0,0,0 -> osd_dba_filebits = 12 (MVS)

Typ=69 Len=10: 0,0,0,0,0,64,0,0,0,0 ->osd_dba_filebits = 10

OSD_C_STRUCT_ALIGNMENT

数值类型。这个参数表示的是数据文件头的结构布局，取值有三个0,16和32，大部分的平台这个值要设成32。可以通过如下的查询确定这个参数该设成哪个值。

OSD_FILE_LEADER_SIZE

数值类型。这个参数表示的是在Oracle数据文件中，真实的数据文件头块之前的块/字节的数量，可以参照如下进行设置：

平台 值

Unix 1

Desktop 512

OSD_WORD_SIZE

数值类型。表示的是machine word的大小，除一些特别的平台如MS-DOS这个值需设置为16外，其它的都为32。

control_file

用于指定dul控制文件的名字，控制文件默认的名字为control.dul，保险起见最好使用全路径

db_block_size

数据库的db_block_size，一般是8K

Compatible

数据库版本号，只写大版本，前提是所用的dul支持此oracle db 版本

dc_columns

dc_tables

dc_objects

dc_users

dc_segments

四个数据字典缓存参数，用于存放col$,tab$,obj$以及user$这几个数据字典表，可以设置大一些，不过即使设的小一 点也没有关系，dul会自动升为需要的值，在屏幕打出告警信息，不影响正常的操作。不过这几个参数对本次恢复没有任何用处，因为待恢复的表空间已经不在数据库中了，system表空间中的字典没有待恢复的表空间的信息。

EXPORT_MODE

dul的输出格式，默认值为FALSE。当其取值为FALSE时输出格式为sql*loader方式。当其取值为TRUE时，输出格式为exp/imp方式，即.dmp文件。

1.2 control.dul

控制文件也是dul运行必需的文件，默认的名字为control.dul，包含了要做unload的数据文件的相关信息，dul通过它，把数据文件号对应到相应的数据文件。包含3个字段，Ts#、Relative_file、# Data_file_name ，对应表空间编号，数据文件编号，数据文件名。可以通过v$datafile来获得。还有几个可选参数，就不详述了。

本次恢复中，因为表空间已经从数据库中drop掉了，所有查不到相应的Ts#和Relative_file，可以只写file_name，dul工具会自动从数据文件的头信息中读取相应的标号。Data_file_name可以通过裸设备的最后修改日期大概知道此表空间有那些数据文件。

root@blade34 dul4x86-linux]# cat control.dul

/bi_bak/wangyq/lvdm2_16g_268

/bi_bak/wangyq/lvdm2_16g_269

/bi_bak/wangyq/lvdm2_16g_270

/bi_bak/wangyq/lvdm2_16g_271

/bi_bak/wangyq/lvdm2_16g_272

/bi_bak/wangyq/lvdm2_16g_273

/bi_bak/wangyq/lvdm2_16g_274

/bi_bak/wangyq/lvdm2_16g_275

/bi_bak/wangyq/lvdm2_16g_276

/bi_bak/wangyq/lvdm2_16g_277

/bi_bak/wangyq/lvdm2_16g_278

/bi_bak/wangyq/lvdm2_16g_279

/bi_bak/wangyq/lvdm2_16g_280

/bi_bak/wangyq/lvdm2_16g_281

/bi_bak/wangyq/lvdm2_16g_282

/bi_bak/wangyq/lvdm2_16g_283

注：待恢复的数据库使用的裸设备，为方便操作，并避免误操作带来的麻烦，我提前将lv都dd成文件了。

2、恢复操作

Dul恢复会自动成一个dul.lo日志文件，恢复过程中可以查看。

[root@blade34 dul4x86-linux]# ./dul

./dul: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./dul)

[root@blade34 dul4x86-linux]# strings /lib/libc.so.6|grep GLIBC

GLIBC_2.0

GLIBC_2.1

GLIBC_2.1.1

GLIBC_2.1.2

GLIBC_2.1.3

GLIBC_2.2

GLIBC_2.2.1

GLIBC_2.2.2

GLIBC_2.2.3

GLIBC_2.2.4

GLIBC_2.2.6

GLIBC_2.3

GLIBC_2.3.2

GLIBC_2.3.3

GLIBC_2.3.4

GLIBC_2.4

GLIBC_2.5

GLIBC_PRIVATE

GLIBC版本不够高，需要安装更高一点的版本，找个高版本装上继续恢复

[root@sdbi131 dul4x86-linux]# ./dul

Data UnLoader: 10.2.0.6.16 - Internal Only - on Wed Dec 30 21:28:01 2015

with 64-bit io functions

Copyright (c) 1994 2015 Bernard van Duijnen All rights reserved.

Strictly Oracle Internal Use Only

DUL: Warning: Recreating file "dul.log"

Reading SCANNEDLOBPAGE.dat

DUL: Warning: Increased the size of DC_SCANNED_LOB_PAGES from 10000 to 32768 entries

DUL: Warning: Increased the size of DC_SCANNED_LOB_PAGES from 32768 to 65536 entries

DUL: Warning: Increased the size of DC_SCANNED_LOB_PAGES from 65536 to 98304 entries

DUL: Warning: Increased the size of DC_SCANNED_LOB_PAGES from 98304 to 131072 entries

DUL: Warning: Increased the size of DC_SCANNED_LOB_PAGES from 131072 to 163840 entries

DUL: Warning: Increased the size of DC_SCANNED_LOB_PAGES from 163840 to 196608 entries

DUL: Warning: Increased the size of DC_SCANNED_LOB_PAGES from 196608 to 229376 entries

DUL: Warning: Increased the size of DC_SCANNED_LOB_PAGES from 229376 to 262144 entries

DUL: Warning: Increased the size of DC_SCANNED_LOB_PAGES from 262144 to 294912 entries

263663 entries loaded and sorted 263663 entries

Reading SEG.dat 527 entries loaded

Reading EXT.dat 5384 entries loaded and sorted 5384 entries

Reading COMPATSEG.dat 0 entries loaded

Found db_id = 1099671526

Found db_name = SDCITYDM

DUL> scan database;

Scanning tablespace 28, data file 2 ...

3 segment header and 82990 data blocks

tablespace 28, data file 2: 2096639 blocks scanned

Scanning tablespace 28, data file 272 ...

11 segment header and 79277 data blocks

tablespace 28, data file 272: 2096639 blocks scanned

Scanning tablespace 28, data file 273 ...

0 segment header and 71786 data blocks

tablespace 28, data file 273: 2096639 blocks scanned

Scanning tablespace 28, data file 274 ...

0 segment header and 70977 data blocks

tablespace 28, data file 274: 2096639 blocks scanned

Scanning tablespace 28, data file 275 ...

19 segment header and 69854 data blocks

tablespace 28, data file 275: 2096639 blocks scanned

Scanning tablespace 28, data file 281 ...

120 segment header and 69076 data blocks

tablespace 28, data file 281: 2096639 blocks scanned

Scanning tablespace 28, data file 282 ...

16 segment header and 70032 data blocks

tablespace 28, data file 282: 2096639 blocks scanned

Scanning tablespace 28, data file 283 ...

101 segment header and 68109 data blocks

tablespace 28, data file 283: 2096639 blocks scanned

Scanning tablespace 28, data file 284 ...

13 segment header and 69823 data blocks

tablespace 28, data file 284: 2096639 blocks scanned

Scanning tablespace 28, data file 285 ...

43 segment header and 72504 data blocks

tablespace 28, data file 285: 2096639 blocks scanned

Scanning tablespace 28, data file 286 ...

170 segment header and 72425 data blocks

tablespace 28, data file 286: 2096639 blocks scanned

Scanning tablespace 28, data file 287 ...

13 segment header and 74423 data blocks

tablespace 28, data file 287: 2096639 blocks scanned

Scanning tablespace 28, data file 288 ...

3 segment header and 74447 data blocks

tablespace 28, data file 288: 2096639 blocks scanned

Scanning tablespace 28, data file 289 ...

11 segment header and 72380 data blocks

tablespace 28, data file 289: 2096639 blocks scanned

Scanning tablespace 28, data file 290 ...

2 segment header and 74061 data blocks

tablespace 28, data file 290: 2096639 blocks scanned

Scanning tablespace 28, data file 291 ...

2 segment header and 83468 data blocks

tablespace 28, data file 291: 2096639 blocks scanned

Reading EXT.dat 5384 entries loaded and sorted 5384 entries

Reading SEG.dat 527 entries loaded

Reading COMPATSEG.dat 0 entries loaded

## scan database，这个命令会扫描control.dul中所有数据文件中的数据块，并生成了如下两个文件：

01：seg.dat 扫描到的段(segment)的段头信息 (index/cluster/table):

02：ext.dat 扫描到的相邻的table/cluster的数据块信息。

从命令执行结果中可以看到dul已经从数据文件中读取到了相应的信息。

UL> scan tables;

Scanning tables with segment header

## scan tables以SCAN DATABASE生成的两个文件seg.dat and ext.dat做为输入，扫描所有数据段中的所有的表。 会生成一下日志，如：

Analyzing segment: data object id 506701 segment header at ( file 272 block 53539)

heap organized table

Col    Seen  Max PCT  PRINT  NUMBERS DATES TIMESTAMP WITH TZ INTRVAL  ROWIDS LOB

no   count Size NUL 75%100% AnyNice AnyNice AnyNice AnyNice Y2M D2S AnyNice

1      30   11   0 100 100   0   0   0   0   0   0   0   0   0 100   0   0   0

"18605420016"

"18605420017"

"18605427168"

"18606350038"

"18606350363"

UNLOAD TABLE OBJNO506701 ( COL001 UNKNOWN )

STORAGE( DATAOBJNO 506701 );

所有生成的日志都会记录的dul.log文件中，从日志看，Dul已经读取到了表的各个字段的类型，并给出几条示例的记录，同时也给出来unload的语句。通过这条unload语句就可以将此表导出为dmp文件。如果能确切知道表名的话，也可以修改此语句的表名为实际table name。可惜表太多了，没办法做到一一map上，只能导出后根据数据再做map了。

DUL> UNLOAD TABLE OBJNO535600 ( COL001 VARCHAR2(11) )

2      STORAGE( DATAOBJNO 535600 );

. unloading table               OBJNO535600     361 rows unloaded

DUL>

OBJNO535600表已经导出 ，此表有361行数据。Dul工具的目录下也生成了OBJNO506701.dmp

可以从dul.log中找到多个表的恢复语句，然后可以逐一进行unload操作。

剩下的工作就很简单了，将dmp文件导入到数据中，应用再对恢复的表逐个甄别 ，进行数据的修复。本次成功恢复恢复了120张表。

3、恢复中的问题

DUL> UNLOAD TABLE OBJNO928534 ( COL001 LOB INFORMATION )STORAGE( DATAOBJNO 928534 );

Dul: parse error: column type expected, when parsing <LOB>

File "standard input" line number 1 column 34

DUL>

对于带有lob字段的表，始终没法恢复，尝试了dul4和dul10两个版本都报同样的错误，不知道最新版本的dul是不是可以在没有system表空间的情况恢复带有lob字段的表，有14张表没有恢复成功。

二、第三方恢复工具ODU

是由 OracleODU开发的类似于Oracle的DUL的一款恢复软件，用于直接从Oracle数据库的数据文件中获取表数据。在各种原因造成的数据库不能 打开时，用于抢救数据，最大限度地减少数据丢失。以前的版本是免费的，最新的4.x版本需要liscence 。具体用法可以参照官方网站的手册，和DUL使用方法类似。

1、配置文件config.txt ，control.txt，参数设置和DUL类似，就不多介绍了

[root@sdbi131 odu]# cat config.txt

byte_order little

block_size  8192

db_timezone -7

client_timezone 8

data_path   data

charset_name AL32UTF8

ncharset_name AL16UTF16

output_format text

lob_storage infile

clob_byte_order little

[root@sdbi131 odu]# cat control.txt

#ts #fno   #rfno     filename                                          block_size

28      2       2       /bi_bak/wangyq/lvdm2_16g_268

28      272     272     /bi_bak/wangyq/lvdm2_16g_269

28      273     273     /bi_bak/wangyq/lvdm2_16g_270

28      274     274     /bi_bak/wangyq/lvdm2_16g_271

28      275     275     /bi_bak/wangyq/lvdm2_16g_272

28      281     281     /bi_bak/wangyq/lvdm2_16g_273

28      282     282     /bi_bak/wangyq/lvdm2_16g_274

28      283     283     /bi_bak/wangyq/lvdm2_16g_275

28      284     284     /bi_bak/wangyq/lvdm2_16g_276

28      285     285     /bi_bak/wangyq/lvdm2_16g_277

28      286     286     /bi_bak/wangyq/lvdm2_16g_278

28      287     287     /bi_bak/wangyq/lvdm2_16g_279

28      288     288     /bi_bak/wangyq/lvdm2_16g_280

28      289     289     /bi_bak/wangyq/lvdm2_16g_281

28      290     290     /bi_bak/wangyq/lvdm2_16g_282

28      291     291     /bi_bak/wangyq/lvdm2_16g_283

2、恢复操作

步骤

scan extent

unload object all sample

sample.txt查找需要的恢复语句，如unload object 535601 tablespace 28 column VARCHAR2 xxx

恢复需要的表：unload object data_object_id column coltype coltype…

3、问题

ODU工具可以完美的恢复带lob字段的表，最终将134张表全部恢复了出来。

---摘在同事一故障处理

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/229689/viewspace-2062602/，如需转载，请注明出处，否则将追究法律责任。