ODU恢复测试二：drop表恢复（troubleshoot版）

本文详细记录了此次测试的整个过程，包括遇到的问题和调试过程，比较零乱。所以整理出了简洁版：http://blog.youkuaiyun.com/tanqingru/article/details/7767669，适于以后参考，因为过程解决了一些问题，做为个人笔记值得记录在此。

此次恢复基于测试1的表odu_test进行，将测试的ODU版本为“4.1.3 试用版 for Windows”，结果发现试用版在恢复时有1000行左右的限制，超出的无法恢复。

可从这下载：http://www.laoxiong.net/odu或http://www.oracleodu.com/cn/
可参考老熊自己的博客：http://www.laoxiong.net/odu_recover_drop_table.html

1.环境准备：

D:\Downloads\odu\data>sqlplus "/as sysdba"

SQL*Plus: Release 11.2.0.1.0 Production on 星期五 7月 20 08:42:37 2012

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

连接到:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter system checkpoint;
系统已更改。
SQL> select count(*) from bamuta.odu_test;

  COUNT(*)
----------
     72259
SQL> drop table bamuta.odu_test;
表已删除。
SQL>

2.恢复：

2.1将该表空间离线（保证删除的表的位置不被重写）

SQL> alter tablespace users offline;
表空间已更改。

2.2 通过logmnr，找出data_object_id

安装logmnr

SQL> @?/rdbms/admin/dbmslm.sql;

程序包已创建。
授权成功。
同义词已创建。
SQL> @?/rdbms/admin/dbmslmd.sql;
程序包已创建。
同义词已创建。

设置utl_file_dir

SQL> alter system set utl_file_dir='C:\Users\Administrator\Desktop\20120719ODU' scope=spfile;

系统已更改。

SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup
ORACLE 例程已经启动。


Total System Global Area  535662592 bytes
Fixed Size                  1375792 bytes
Variable Size             360710608 bytes
Database Buffers          167772160 bytes
Redo Buffers                5804032 bytes
数据库装载完毕。
数据库已经打开。
SQL>

开始日志挖掘：

SQL> select group#,status from V$log;
    GROUP# STATUS
---------- --------------------------------
         1 CURRENT
         2 INACTIVE
         3 INACTIVE
SQL> select member from V$logfile where group#=1;
MEMBER
--------------------------------------------------------------------------------
G:\APP\ADMINISTRATOR\ORADATA\TAN01\REDO01.LOG
SQL> exec sys.dbms_logmnr.add_logfile(logfilename=>'G:\APP\ADMINISTRATOR\ORADATA\TAN01\REDO01.LOG');
PL/SQL 过程已成功完成。
SQL> exec sys.dbms_logmnr.start_logmnr(options=>sys.dbms_logmnr.dict_from_online_catalog);
PL/SQL 过程已成功完成。
SQL> select scn,timestamp,sql_redo from V$logmnr_contents where operation='DDL'
     and sql_redo like '%odu_test%';
       SCN TIMESTAMP
---------- --------------
SQL_REDO
--------------------------------------------------------------------------------
   1142133 19-7月 -12
create table odu_test as select * from dba_objects;

   1142295 19-7月 -12
truncate table odu_test;


   1148190 20-7月 -12
drop table bamuta.odu_test AS "BIN$b2GaC5SYTJKF1s56AxZTKA==$0" ;

这说明没有drop干净，表还在回收站里，为了测试的实际性，将表完全删除，要么重新做，使用drop table odu_test purge;要么清空回收站

SQL> purge dba_recyclebin;

DBA 回收站已清空。

SQL> flashback table bamuta.odu_test to before drop;
flashback table bamuta.odu_test to before drop
*
第 1 行出现错误:
ORA-38305: 对象不在回收站中

实刚才我做了个错误的操作其
SQL> purge recyclebin;
回收站已清空。
然后做闪回成功了。所以必须得重新做上面的一些操作。最后重新挖掘出来的结果如下：
SQL> select scn,timestamp,sql_redo from V$logmnr_contents where operation='DDL'
  2       and sql_redo like '%odu_test%';


       SCN TIMESTAMP
---------- --------------
SQL_REDO
--------------------------------------------------------------------------------
   1142133 19-7月 -12
create table odu_test as select * from dba_objects;


   1142295 19-7月 -12
truncate table odu_test;


   1148190 20-7月 -12
drop table bamuta.odu_test AS "BIN$b2GaC5SYTJKF1s56AxZTKA==$0" ;

       SCN TIMESTAMP
---------- --------------
SQL_REDO
--------------------------------------------------------------------------------
   1149982 20-7月 -12
drop table bamuta.odu_test purge;

调整时间格式：

SQL> select scn,to_char(timestamp,'yyyy-mm-dd hh24:mi:ss'),sql_redo
    from V$logmnr_contents where operation='DDL'
    and sql_redo like '%odu_test%';

       SCN TO_CHAR(TIMESTAMP,'YYYY-MM-DDHH24:MI:S
---------- --------------------------------------
SQL_REDO
--------------------------------------------------------------------------------
   1142133 2012-07-19 15:55:07
create table odu_test as select * from dba_objects;

   1142295 2012-07-19 15:57:15
truncate table odu_test;

   1148190 2012-07-20 08:44:04
drop table bamuta.odu_test AS "BIN$b2GaC5SYTJKF1s56AxZTKA==$0" ;

       SCN TO_CHAR(TIMESTAMP,'YYYY-MM-DDHH24:MI:S
---------- --------------------------------------
SQL_REDO
--------------------------------------------------------------------------------
   1149982 2012-07-20 09:18:19
drop table bamuta.odu_test purge;

SQL>
SQL> select sql_redo from V$logmnr_contents where timestamp=to_date('2012-07-20 09:18:19','yyyy-mm-dd hh24:mi:ss')
    and operation='DELETE';


SQL_REDO
--------------------------------------------------------------------------------
/* No SQL_REDO for temporary tables */
delete from "SYS"."OBJ$" where "OBJ#" = '73639' and "DATAOBJ#" = '73640' and "OW
NER#" = '86' and "NAME" = 'ODU_TEST' and "NAMESPACE" = '1' and "SUBNAME" IS NULL
 and "TYPE#" = '2' and "CTIME" = TO_DATE('19-7月 -12', 'DD-MON-RR') and "MTIME"
= TO_DATE('20-7月 -12', 'DD-MON-RR') and "STIME" = TO_DATE('20-7月 -12', 'DD-MON
-RR') and "STATUS" = '1' and "REMOTEOWNER" IS NULL and "LINKNAME" IS NULL and "F
LAGS" = '0' and "OID$" IS NULL and "SPARE1" = '6' and "SPARE2" = '3' and "SPARE3
" = '86' and "SPARE4" IS NULL and "SPARE5" IS NULL and "SPARE6" IS NULL and ROWI
D = 'AAAAASAABAAAU+BAAm';

可以看出删除的表ODU_TEST的object_id是73639，data_object_id是73640，目前我还不清楚是需要哪个ID，经过后面的户口测试可以知道。

2.3通过ODU恢复：

配置config.txt，如下：

byte_order little
block_size  8192
block_buffers 1024
db_timezone -7
client_timezone 8
asmfile_extract_path   e:\asmfile
data_path   data
lob_path    e:\odu\data\lob
charset_name ZHS16GBK
ncharset_name AL32UTF8
output_format text
lob_storage infile
clob_byte_order big
trace_level 1
delimiter |
unload_deleted no
file_header_offset 0
is_tru64 no
record_row_addr no
convert_clob_charset yes
use_scanned_lob  yes
trim_scanned_blob yes
lob_switch_dir_rows 20000
db_block_checksum yes
db_block_checking yes
rdba_file_bits 10
compatible 10


 SQL> select ts#,file_id fno#,file_id rfno#,file_name,value
  2  from V$tablespace t,dba_data_files d,v$parameter p
  3  where t.name=d.tablespace_name
  4  and p.name='db_block_size';


       TS#       FNO#      RFNO# FILE_NAME                                                                        VALUE
---------- ---------- ---------- -------------------------------------------------------------------------------- --------------------------------------------------------------------------------
         0          1          1 G:\APP\ADMINISTRATOR\ORADATA\TAN01\SYSTEM01.DBF                                  8192
         1          2          2 G:\APP\ADMINISTRATOR\ORADATA\TAN01\SYSAUX01.DBF                                  8192
         2          3          3 G:\APP\ADMINISTRATOR\ORADATA\TAN01\UNDOTBS01.DBF                                 8192
         4          4          4 G:\APP\ADMINISTRATOR\ORADATA\TAN01\USERS01.DBF                                   8192

配置control，如下：

#ts fno   rfno     filename                                          block_size  is_big_file header_offset blocks 
        0          1          1 G:\APP\ADMINISTRATOR\ORADATA\TAN01\SYSTEM01.DBF                                  8192
         1          2          2 G:\APP\ADMINISTRATOR\ORADATA\TAN01\SYSAUX01.DBF                                  8192
         2          3          3 G:\APP\ADMINISTRATOR\ORADATA\TAN01\UNDOTBS01.DBF                                 8192
         4          4          4 G:\APP\ADMINISTRATOR\ORADATA\TAN01\USERS01.DBF                                   8192


control中的有些值不用填，在open时自己会补上。

使用ODU

Oracle Data Unloader trial version 4.1.3
Copyright (c) 2008,2009,2010,2011 XiongJun. All rights reserved.
Web: http://www.oracleodu.com
Email: magic007cn@gmail.com
loading default config.......
byte_order little
block_size  8192
block_buffers 1024
error at line 3.
db_timezone -7
Invalid db timezone:-7
client_timezone 8
Invalid client timezone:8
asmfile_extract_path   e:\asmfile
data_path   data
lob_path    e:\odu\data\lob
charset_name ZHS16GBK
ncharset_name AL32UTF8
output_format text
lob_storage infile
clob_byte_order big
trace_level 1
delimiter |
unload_deleted no
file_header_offset 0
is_tru64 no
record_row_addr no
convert_clob_charset yes
use_scanned_lob  yes
trim_scanned_blob yes
lob_switch_dir_rows 20000
db_block_checksum yes
db_block_checking yes
rdba_file_bits 10
compatible 10
load config file 'config.txt' successful
loading default asm disk file ......

grp# dsk# bsize ausize disksize diskname        groupname       path
---- ---- ----- ------ -------- --------------- --------------- ----------------------------------------

load asm disk file 'asmdisk.txt' successful
loading default control file ......

 ts#   fn  rfn bsize   blocks bf offset filename
---- ---- ---- ----- -------- -- ------ --------------------------------------------
   0    1    1  8192    89600 N       0 G:\APP\ADMINISTRATOR\ORADATA\TAN01\SYSTEM01.DBF
   1    2    2  8192    76800 N       0 G:\APP\ADMINISTRATOR\ORADATA\TAN01\SYSAUX01.DBF
   2    3    3  8192    65920 N       0 G:\APP\ADMINISTRATOR\ORADATA\TAN01\UNDOTBS01.DBF
   4    4    4  8192     2560 N       0 G:\APP\ADMINISTRATOR\ORADATA\TAN01\USERS01.DBF
load control file 'control.txt' successful
loading dictionary data......done

loading scanned data......done

ODU> scan extent tablespace 4;


scan extent start: 2012-07-20 09:44:25
scanning extent...
scanning extent finished.
scan extent completed: 2012-07-20 09:44:26
 
使用object_id:73639

ODU> unload object 73639 sample

Unloading Object,object ID: 73639,  Cluster: 0
output data is in file :  'data\ODU_0000073639.txt'

Sample result:
  object id: 73639
  no data.
直接恢复：
ODU> unload table bamuta.odu_test object 73639
table 'bamuta.odu_test' does not exist.

使用上面的DATA_OBJECT_ID：73640

通过ODU的抽样来自动判断数据的类型
ODU> unload object 73640 sample

Unloading Object,object ID: 73640,  Cluster: 0
output data is in file :  'data\ODU_0000073640.txt'

Sample result:
  object id: 73640
  tablespace no: 4
  sampled 947 rows
  column count: 14
  column    1  type: VARCHAR2
  column    2  type: VARCHAR2
  column    3  type: VARCHAR2
  column    4  type: NUMBER
  column    5  type: NUMBER
  column    6  type: VARCHAR2
  column    7  type: DATE
  column    8  type: DATE
  column    9  type: VARCHAR2
  column   10  type: VARCHAR2
  column   11  type: VARCHAR2
  column   12  type: VARCHAR2
  column   13  type: VARCHAR2
  column   14  type: NUMBER

COMMAND:
unload object 73640 tablespace 4 column VARCHAR2 VARCHAR2 VARCHAR2 NUMBER NUMBER VARCHAR2 DATE DATE VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 NUMBER

恢复，下面方法不可行：

ODU> unload table bamuta.odu_test object 73640
table 'bamuta.odu_test' does not exist.
ODU>
使用下面的方法恢复：
ODU> unload object 73640 tablespace 4 column VARCHAR2 VARCHAR2 VARCHAR2 NUMBER NUMBER VARCHAR2 DATE DATE VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 NUMBER

Unloading Object,object ID: 73640,  Cluster: 0
1025 rows unloaded
 但这样只有1025行恢复，和72259差很多

做进一步的验证：
SQL> @ODU_0000073640.sql;

表已创建。

D:\Downloads\odu\data>sqlldr bamuta/bamuta control=ODU_0000073640.ctl
SQL*Loader: Release 11.2.0.1.0 - Production on 星期五 7月 20 10:48:39 2012
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

达到提交点 - 逻辑记录计数 224
达到提交点 - 逻辑记录计数 448
达到提交点 - 逻辑记录计数 672
达到提交点 - 逻辑记录计数 896
达到提交点 - 逻辑记录计数 1025

D:\Downloads\odu\data>
结果更是失败：
D:\Downloads\odu\data>sqlplus bamuta/bamuta
SQL*Plus: Release 11.2.0.1.0 Production on 星期五 7月 20 10:49:12 2012
Copyright (c) 1982, 2010, Oracle.  All rights reserved.

连接到:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options


SQL> select count(*) from ODU_0000073640;


  COUNT(*)
----------
         0


仔细检查是忘记online表空间了：


SQL> alter tablespace users online;

D:\Downloads\odu\data>sqlldr bamuta/bamuta control=ODU_0000073640.ctl
SQL*Loader: Release 11.2.0.1.0 - Production on 星期五 7月 20 10:52:24 2012
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

达到提交点 - 逻辑记录计数 224
达到提交点 - 逻辑记录计数 448
达到提交点 - 逻辑记录计数 672
达到提交点 - 逻辑记录计数 896
达到提交点 - 逻辑记录计数 1025


D:\Downloads\odu\data>sqlplus bamuta/bamuta

SQL> select count(*) from ODU_0000073640;


  COUNT(*)
----------
      1025


经过验证，数据确实是有丢失，这是不希望的。打算再做一遍来发现问题出在哪里。

2.4再进行一次：

SQL> create table odu_test as select * from dba_objects;


Table created


SQL> select count(*) from odu_test;


  COUNT(*)
----------
     72259


SQL> alter system checkpoint;


System altered


SQL> alter tablespace users offline;


表空间已更改。
SQL> select group#,status from V$log;


    GROUP# STATUS
---------- ----------------
         1 INACTIVE
         2 INACTIVE
         3 CURRENT


SQL> exec sys.dbms_logmnr.add_logfile(logfilename=>'G:\APP\ADMINISTRATOR\ORADATA\TAN01\REDO03.LOG');


PL/SQL 过程已成功完成。


SQL> exec sys.dbms_logmnr.start_logmnr(options=>sys.dbms_logmnr.dict_from_online_catalog);


PL/SQL 过程已成功完成。


SQL> select scn,to_char(timestamp,'yyyy-mm-dd hh24:mi:ss'),sql_redo
  2       from V$logmnr_contents where operation='DDL'
  3        and sql_redo like '%odu_test%';


       SCN TO_CHAR(TIMESTAMP,'YYYY-MM-DDH SQL_REDO
---------- ------------------------------ --------------------------------------------------------------------------------
   1161298 2012-07-20 13:54:04            create table odu_test as select * from dba_objects
                                          
                                      ;

   1161688 2012-07-20 14:00:41            drop table odu_test purge
                                          
     
SQL> select sql_redo from V$logmnr_contents where timestamp=to_date('2012-07-20 14:00:41','yyyy-mm-dd hh24:mi:ss')
  2      and operation='DELETE';


SQL_REDO
--------------------------------------------------------------------------------
/* No SQL_REDO for temporary tables */
delete from "SYS"."OBJ$" where "OBJ#" = '73649' and "DATAOBJ#" = '73649' and "OW

ODU> scan extent tablespace 4;

scan extent start: 2012-07-20 11:23:48
scanning extent...
scanning extent finished.
scan extent completed: 2012-07-20 11:23:49

ODU> unload object 73649 sample

Unloading Object,object ID: 73648,  Cluster: 0
output data is in file :  'data\ODU_0000073648.txt'

Sample result:
  object id: 73649
  tablespace no: 4
  sampled 1000 rows
  column count: 14
  column    1  type: VARCHAR2
  column    2  type: VARCHAR2
  column    3  type: VARCHAR2
  column    4  type: NUMBER
  column    5  type: NUMBER
  column    6  type: VARCHAR2
  column    7  type: DATE
  column    8  type: DATE
  column    9  type: VARCHAR2
  column   10  type: VARCHAR2
  column   11  type: VARCHAR2
  column   12  type: VARCHAR2
  column   13  type: VARCHAR2
  column   14  type: NUMBER


COMMAND:
unload object 73649 tablespace 4 column VARCHAR2 VARCHAR2 VARCHAR2 NUMBER NUMBER VARCHAR2 DATE DATE VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 NUMBER


ODU> unload object 73649 tablespace 4 column VARCHAR2 VARCHAR2 VARCHAR2 NUMBER NUMBER VARCHAR2 DATE DATE VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2
NUMBER


Unloading Object,object ID: 73649,  Cluster: 0
1029 rows unloaded


为什么还是1029行，比预期的少很多？

2.5成功的一次恢复

怀疑是因为ODU试用版本的限制，所以用了版本309，如下：
Oracle Data Unloader:Release 3.0.9

Copyright (c) 2008,2009 XiongJun. All rights reserved.


Web: http://www.laoxiong.net
Email: magic007cn@gmail.com


loading default config.......


byte_order little
block_size  8192
data_path   data
lob_path    lob
charset_name ZHS16GBK
ncharset_name AL32UTF8
charset name 'AL32UTF8' not found,will use default ncharset AL16UTF16
output_format text
lob_storage file
clob_byte_order little
trace_level 1
delimiter |

load control file 'config.txt' successful
loading default control file ......


 ts#   fn  rfn bsize   blocks bf offset filename
---- ---- ---- ----- -------- -- ------ --------------------------------------------
   0    1    1  8192    89600 N       0 G:\APP\ADMINISTRATOR\ORADATA\TAN01\SYSTEM01.DBF
   1    2    2  8192    76800 N       0 G:\APP\ADMINISTRATOR\ORADATA\TAN01\SYSAUX01.DBF
   2    3    3  8192    65920 N       0 G:\APP\ADMINISTRATOR\ORADATA\TAN01\UNDOTBS01.DBF
   4    4    4  8192     2560 N       0 G:\APP\ADMINISTRATOR\ORADATA\TAN01\USERS01.DBF
load control file 'control.txt' successful
loading dictionary data......


ODU> scan extent tablespace 4;


scan extent start: 2012-07-20 14:32:39
scanning extent...
scanning extent finished.
scan extent completed: 2012-07-20 14:32:40


ODU> unload object 73649 sample


Unloading Object,object ID: 73649,  Cluster: 0
output data is in file :  'data\ODU_0000073649.txt'


Sample result:
  object id: 73649
  tablespace no: 4
  sampled 1061 rows
  column count: 14
  column    1  type: VARCHAR2
  column    2  type: VARCHAR2
  column    3  type: RAW
  column    4  type: NUMBER
  column    5  type: NUMBER
  column    6  type: VARCHAR2
  column    7  type: DATE
  column    8  type: DATE
  column    9  type: VARCHAR2
  column   10  type: VARCHAR2
  column   11  type: VARCHAR2
  column   12  type: VARCHAR2
  column   13  type: VARCHAR2
  column   14  type: NUMBER


COMMAND:
unload object 73649 tablespace 4 column VARCHAR2 VARCHAR2 RAW NUMBER NUMBER VARCHAR2 DATE DATE VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 NUMBER


ODU> unload object 73649 tablespace 4 column VARCHAR2 VARCHAR2 RAW NUMBER NUMBER VARCHAR2 DATE DATE VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 NUMBER

Unloading Object,object ID: 73649,  Cluster: 0
72259 rows unloaded


此时，和之前的数据相同，说明该问题是试用版本的限制，超过一定量的数据将无法恢复，具体表现为行就是1030行左右。

2.6最后将数据恢复到表中：

SQL> alter tablespace users online;

Tablespace altered

SQL> @D:\Downloads\odu\data\ODU_0000073649.sql

Table created

D:\Downloads\odu\data> sqlldr bamuta/bamuta control=ODU_0000073649.ctl

SQL*Loader: Release 11.2.0.1.0 - Production on 星期五 7月 20 14:39:02

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights re

达到提交点 - 逻辑记录计数 224
达到提交点 - 逻辑记录计数 448
达到提交点 - 逻辑记录计数 672
达到提交点 - 逻辑记录计数 896
……
……
……
达到提交点 - 逻辑记录计数 71592
达到提交点 - 逻辑记录计数 71816
达到提交点 - 逻辑记录计数 72040
达到提交点 - 逻辑记录计数 72259


SQL> select count(*) from odu_0000073649;

  COUNT(*)
----------
     72259

和之前的数据条目完全一样，但有一点缺点就是column的名字变了：

SQL> desc odu_0000073649

Name  Type           Nullable Default Comments 
----- -------------- -------- ------- -------- 
C0001 VARCHAR2(4000) Y                         
C0002 VARCHAR2(4000) Y                         
C0003 RAW(2000)      Y                         
C0004 NUMBER         Y                         
C0005 NUMBER         Y                         
C0006 VARCHAR2(4000) Y                         
C0007 DATE           Y                         
C0008 DATE           Y                         
C0009 VARCHAR2(4000) Y                         
C0010 VARCHAR2(4000) Y                         
C0011 VARCHAR2(4000) Y                         
C0012 VARCHAR2(4000) Y                         
C0013 VARCHAR2(4000) Y                         
C0014 NUMBER         Y       


无论如何，数据是完整的恢复了。