用不完全恢复找回被误删除表空间 （一)

  • huyi_tony

    2014-07-07 10:25:33
  • Oracle
  • 原创
当表空间被操作员误操作，用 drop tablespace的方式删除了。
可以通过备份，做不完全恢复来找回。

做不完全恢复之前，有一个问题要先解决。就是如何让 控制文件 识别出该表空间和它的数据文件。

点击(此处)折叠或打开

  1. sys@BJDB>select tablespace_name from dba_tablespaces;                   -- NEWTS表空间还存在

  3. TABLESPACE_NAME
  4. ------------------------------
  5. SYSTEM
  6. SYSAUX
  7. TEMPTS1
  8. TS_ASSM
  9. SMALL_UNDO
  10. NEWTS

  12. 6 rows selected.

  14. sys@BJDB>select current_scn from v$database;                                -- NEWTS被删除前的一个SCN。 通常应该做日志挖掘来确定这个点

  16. CURRENT_SCN
  17. -----------
  18.     8486756

  20. sys@BJDB>drop tablespace newts including contents and datafiles;            -- 删除表空间NEWTS 连同数据文件

  22. Tablespace dropped.

  24. sys@BJDB>select tablespace_name from dba_tablespaces;                       -- NEWTS表空间已经查不到了

  26. TABLESPACE_NAME
  27. ------------------------------
  28. SYSTEM
  29. SYSAUX
  30. TEMPTS1
  31. TS_ASSM
  32. SMALL_UNDO

在这个案例里。事先做好了数据库的备份（其中含有 NEWTS表空间的备份  已经 controlfile的备份 （这个备份的controlfile 是能够识别NEWTS表空间的）

1，把系统重新启动到nomount状态。

2，转储备份的controlfile （ 该controlfile能够识别 NEWTS表空间）

点击(此处)折叠或打开

  1. [oracle@Redhat55 hot]$ cp /u02/backup/BJDB/hot/control.backup /oradata/BJDB/control01.ctl
  2. [oracle@Redhat55 hot]$ cp /u02/backup/BJDB/hot/control.backup /oradata/BJDB/control02.ctl
用备份的控制文件加载数据库

点击(此处)折叠或打开

  1. sys@BJDB>alter database mount;

  3. Database altered.

  5. sys@BJDB>select name from v$tablespace;              -- 这里能够识别出 NEWTS表空间了

  7. NAME
  8. ------------------------------
  9. SYSTEM
  10. SYSAUX
  11. NEWTS
  12. TS_ASSM
  13. SMALL_UNDO
  14. TEMPTS1

  16. 6 rows selected.

3， 转储所有的数据文件

点击(此处)折叠或打开

  1. cp /u02/backup/BJDB/hot/*.dbf /oradata/BJDB/
4， 把数据恢复到误删除之前。

点击(此处)折叠或打开

  1. sys@BJDB>recover database until change 8486756 using backup controlfile; -- 8486756是drop tablespace 前的scn。 恢复时用的备份的控制文件  
  2. ORA-00279: change 8486573 generated at 07/06/2014 21:36:39 needed for thread 1
  3. ORA-00289: suggestion : /u02/backup/BJDB/disk1/1_12_852176132.dbf
  4. ORA-00280: change 8486573 for thread 1 is in sequence #12


  7. Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
  8. auto
  9. ORA-00279: change 8486675 generated at 07/06/2014 21:38:09 needed for thread 1
  10. ORA-00289: suggestion : /u02/backup/BJDB/disk1/1_13_852176132.dbf
  11. ORA-00280: change 8486675 for thread 1 is in sequence #13
  12. ORA-00278: log file \'/u02/backup/BJDB/disk1/1_12_852176132.dbf\' no longer needed for this recovery


  15. ORA-00279: change 8486678 generated at 07/06/2014 21:38:11 needed for thread 1
  16. ORA-00289: suggestion : /u02/backup/BJDB/disk1/1_14_852176132.dbf
  17. ORA-00280: change 8486678 for thread 1 is in sequence #14
  18. ORA-00278: log file \'/u02/backup/BJDB/disk1/1_13_852176132.dbf\' no longer needed for this recovery


  21. ORA-00279: change 8486681 generated at 07/06/2014 21:38:12 needed for thread 1
  22. ORA-00289: suggestion : /u02/backup/BJDB/disk1/1_15_852176132.dbf
  23. ORA-00280: change 8486681 for thread 1 is in sequence #15
  24. ORA-00278: log file \'/u02/backup/BJDB/disk1/1_14_852176132.dbf\' no longer needed for this recovery


  27. Log applied.
  28. Media recovery complete.
5， 用resetlogs 的方式打开数据库

点击(此处)折叠或打开

  1. sys@BJDB>alter database open resetlogs;

  3. Database altered.

  5. sys@BJDB>select tablespace_name from dba_tablespaces;                  -- 恢复到 删除前。 NEWTS表空间被找回。

  7. TABLESPACE_NAME
  8. ------------------------------
  9. SYSTEM
  10. SYSAUX
  11. TEMPTS1
  12. TS_ASSM
  13. SMALL_UNDO
  14. NEWTS

  16. 6 rows selected.

第四步可能会出现下列情况


点击(此处)折叠或打开

  1. sys@BJDB>recover database until change 8487247 using backup controlfile;
  2. ORA-00279: change 8487168 generated at 07/06/2014 22:13:13 needed for thread 1
  3. ORA-00289: suggestion : /u02/backup/BJDB/disk1/1_5_852242502.dbf
  4. ORA-00280: change 8487168 for thread 1 is in sequence #5


  7. Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
  8. auto
  9. ORA-00279: change 8487245 generated at 07/06/2014 22:13:27 needed for thread 1
  10. ORA-00289: suggestion : /u02/backup/BJDB/disk1/1_6_852242502.dbf
  11. ORA-00280: change 8487245 for thread 1 is in sequence #6
  12. ORA-00278: log file \'/u02/backup/BJDB/disk1/1_5_852242502.dbf\' no longer needed for this recovery


  15. ORA-00308: cannot open archived log \'/u02/backup/BJDB/disk1/1_6_852242502.dbf\'
  16. ORA-27037: unable to obtain file status
  17. Linux-x86_64 Error: 2: No such file or directory
  18. Additional information: 3
这里实际上是因为 做该不完全恢复，需要用的某个 日志序列 还没用归档。处理方法，把相应的联机日志文件名 贴上去做恢复。
由于我们用的是备份的控制文件，该控制文件并不知道该选择哪个联机日志文件来恢复。这里，我们到 数据库目录下，一般情况下，最后更新时间最新的那个日志文件，就是我们要的那个 还未归档的日志文件。

点击(此处)折叠或打开

  1. [oracle@Redhat55 hot]$ ll -lt /oradata/BJDB | grep log
  2. -rw-r----- 1 oracle oinstall 104858112 Jul 6 22:13 redo02a.log                 -- 最新的那个就 redo02a.log
  3. -rw-r----- 1 oracle oinstall 104858112 Jul 6 22:13 redo01a.log
  4. -rw-r----- 1 oracle oinstall 104858112 Jul 6 22:12 redo04.log
  5. -rw-r----- 1 oracle oinstall 104858112 Jul 6 22:12 redo03a.log
  6. -rw-r----- 1 oracle oinstall 52429312 Jul 4 21:51 redo05a.log
  7. -rw-r----- 1 oracle oinstall  52429312 Jul  4 21:51 redo04a.log
用该联机日志文件来恢复

点击(此处)折叠或打开

  1. sys@BJDB>recover database until change 8487247 using backup controlfile;
  2. ORA-00279: change 8487245 generated at 07/06/2014 22:13:27 needed for thread 1
  3. ORA-00289: suggestion : /u02/backup/BJDB/disk1/1_6_852242502.dbf
  4. ORA-00280: change 8487245 for thread 1 is in sequence #6


  7. Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
  8. /oradata/BJDB/redo02a.log
  9. Log applied.
  10. Media recovery complete.

这案例的前提：
1， NEWTS表空间有备份
2， NEWTS表空间被删除前， 控制文件做了备份
3， 不完全恢复需要的日志不缺



























请使用浏览器的分享功能分享到微信等