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

本文详细记录了此次测试的整个过程，包括遇到的问题和调试过程，比较零乱。所以整理出了简洁版：http://blog.csdn.net/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%';