Oracle误删除表空间drop tablespace该如何恢复？

ALLSTARS_ORACLE

HOW TO RECOVER A DELETED TABLESPACE ?
1，ORACLE 10.2 + WINDOWS 2003
2，ARCHIVELOG ON , FLASHBACK DATABASE ON
3, HAVE USED RMAN BACKUP THE TABLESPACE TST BEFORE DELETE  IT. BUT THERE IS  

NO FULL DATABASE BACKUP HEREIN.
4, DELETE TABLESPACE TST INCLUDING DATAFILES.
QUESTION:
WHAT SHOULD I DO FOR RECOVERING THE DELETED TABLESPACE TST ?

THANKS IN ADVANCE!


控制文件没有丢。也没有备份。只是对表空间做了备份。
那么， 备份表空间的本质是什么？ 它包含 表空间的字典信息吗？同时也包含表空间数据文件中的有效数据及对应的段的字典信息？

ALLSTARS_ORACLE

某企业核心业务数据库由于误操作导致多个业务表空间被意外DROP，这些业务表空间存放了300多张表，且无任何形式的有效物理、逻辑备份。
诗檀软件工程师赴用户现场。 具体了解了本问题的细节信息：
数据库采用归档模式，但当时未找到有效的物理或逻辑备份。
多个表空间被DROP ，但因为DROP TABLESPACE没有指定inlucding datafiles，故相关数据文件仍保留在文件系统中未被删除。
尝试使用flashback query闪回查询OBJ$、TAB$等表以便获取被DROP TABLESPACE所删除的字典信息时出现ORA-01555错误，说明相关UNDO数据已过期，无法通过闪回查询挽救DROP TABLESPACE相关的字典数据。
尝试使用bbed观察dbf上的字典表，发现OBJ$、TAB$等字典表仅仅残存少量已删除数据，无法通过特殊恢复已删除数据行的手段来恢复字典数据
以上场景信息，由于DROP TABLESPACE后已无法通过闪回查询或bbed特殊手段来恢复对应的数据字典信息，故恢复数据字典来回退drop tablespace操作已不可能。
针对此种场景，在无有效物理或逻辑备份的情况下，使用ORACLE PRM-DUL工具是唯一有效的恢复途径。

注意：针对此类无有效物理备份的场景采用DUL特殊恢复的，并无法保证100%恢复数据。其恢复数据的比例主要取决于数据空间在被ORACLE回收后是否有被重用或覆盖。DROP TABLESPACE操作本身包含一系列的递归操作，即包括递归地DROP该表空间上的所有数据表，在完全DROP该表空间上的所有数据表后才能真正意义上DROP TABLESPACE，则此DROP TABLESPACE持续的时间内其回收的空间可能被重用或覆盖。

由于字典数据已丢失且不可挽回，故在使用ORACLE PRM-DUL时需采用非字典模式(NON-SYSTEM TABLESPACE)，即直接扫描已被DROP TABLESPACE的数据文件，扫描这些数据文件的SEGMENT HEADER或 SEGMENT EXTENTS数据。这些原始数据中虽然包含着实际表上的行数据，但并不包含例如表的名字TABLE_NAME或COLUMN_NAME字段名字或字段类型等元数据。故非字典模式下UNLOAD抽取出来的表的表名为OBJ+其DATA_OBJECT_ID的形式 例如OBJ9999，代表此表为DATA_OBJECT_ID=9999的数据表。故非字典模式下的UNLOAD出来的表，需要人工识别其数据具体属于哪个表，或通过其他手段来识别。

采用PRM-DUL的非字典模式 存在2种扫描方式，基于SEGMENT HEADER 表头或 EXTENT 盘区模式。 对于一个表空间无任何数据文件丢失的且确认表头未丢失的场景优先采用SEGMENT HEADER 表头模式。 PRM-DUL在表头模式下正常 SCAN DATABASE ; SCAN TABLES; 操作后扫描发现了超过190张表，通过业务人员识别和之前获取的表对应关系，优先恢复了部分业务表，但在SEGMENT HEADER 表头模式下未找到5张业务核心表。

通过SEGMENT HEADER 表头模式下未找到五张表，说明了这五张表的SEGMENT HEADER 表头由于DROP TABLESPACE而已损坏或被重用，这说明了DROP TABLESPACE过程中已重用/覆盖部分回收空间。由于扫描SEGMENT HEADER 表头模式下未找到需要的表，故后续采用扫描EXTENT模式。

由于扫描EXTENT模式将扫描出数据文件上所有存有数据行的数据块，而无需一个SEGMENT HEADER 表头，故采用扫描EXTENT模式可以找到最大量的数据，同时由于其扫描范围更广故可能找到更多无需恢复的数据表。由于每一次扫描均需要针对超过1TB数据的数据文件，故每一次扫描均耗费较多时间。
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com
ORACLE PRM是诗檀软件独立研发的ORACLE数据库灾难恢复软件，其具有全程图形化界面、简单高效等特点。

biotwang

Oracle 11.2之前的解决方案

RMAN duplicate命令不能用于恢复一个被drop掉的表空间，因为当前数据库控制文件并没有被删除的表空间的相关数据文件信息。

在Oracle 11g release 2之前，你不能使用表空间时间点恢复（TSPITR）来恢复一个被删除的表空间。
因此，对于现有数据库来说，你有以下两种可考虑的恢复方式：

方案1. 将整个数据库恢复到表空间被删除的时间点。
数据库中的所有数据将被回退到此时间点，不仅仅是对于某个表空间。

方案2. 将目标库克隆到新位置上，进行数据库时间点恢复后导出表空间数据，然后将导出的数据导入回原数据库。这不会影响现有数据库中的其它数据。

方案1：数据库时间点恢复

1. 判断使用restore恢复的'set until'时间点：
- 查看数据库alert.log找到当时'drop tablespace'命令以找到当时的执行时间
- 在此时间点上减去5分钟，并记录此时间以用于RMAN 'set until'语句。

例如：

1. Thu Aug 23 10:21:01 2007
   
2. Thread 1 advanced to log sequence 243
   
3. Current log# 2 seq# 243 mem# 0: /u01/V102_oradata/redo02.log
   
4. Thu Aug 23 10:21:16 2007
   
5. drop tablespace test including contents and datafiles
   
6. Thu Aug 23 10:21:19 2007
   
7. Deleted file /u01/temp/test01.dbf
   
8. Completed: drop tablespace test including contents and datafiles

复制代码

以上alert.log日志中显示表空间在10:21，Aug 23 2007被删除。同时我们看到在drop前，写入的在线重做日志序列号为sequence 243。因此对应RMAN 'set until'可以是：

时间点方式:

1. ---------------
   
2. run
   
3. {
   
4. set until time "to_date('2007 Aug 23 10:15','yyyy mon dd hh24:mi')";
   
5.   ........
   
6.   ........
   
7. }
   

复制代码

使用日志序列方式:

1. ------------------------
   
2. run
   
3. {
   
4.   set until sequence 243 thread 1;
   
5.   ........
   
6.   ........
   
7. }

复制代码

请注意：以上语法告知RMAN recover到sequence 242。

2. 关闭目标数据库并以nomount状态重启：

1. RMAN> shutdown immediate;
   
2. RMAN> startup nomount;

复制代码

3. 使用相同的'set until'方式恢复控制文件.

1. RMAN> run
   
2. {
   
3.   set until ........................;
   
4.   restore controlfile;
   
5. }
   

复制代码

4. mount数据库

1. RMAN> alter database mount;

复制代码

5. 进行数据库时间点恢复

1. RMAN> run
   
2. {
   
3.   set until ........................;
   
4.   restore database;
   
5.   recover database;
   
6. }

复制代码

6. 使用resetlogs项打开数据库

1. RMAN> alter database open resetlogs;

复制代码

方案2: 从克隆数据库中获取被删除的表空间

数据库的时间点恢复和之前方案1中的基本相同，不同的仅仅是不同的恢复位置。
具体步骤则可以查看MOS下的
Note 223543.1 How to Recover From a DROP / TRUNCATE / DELETE TABLE with RMAN

biotwang

Drop tablespace 如果没有写including contents and datafiles的话，那么对应数据文件应该还在。如果写了的话。那么首先推荐使用磁盘扫描工具或prm-scan将数据文件找回来。
由于drop tablespace已经清除了数据字典中的相关信息，因此之后推荐使用prm-dul对数据文件进行非字典模式扫描，然后将数据抽取出来。