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/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/229689/viewspace-2062602/