oracle基于backup control的完全恢复

误删除表空间(有备份),利用备份的控制文件恢复

一、模拟环境

07:59:14 SQL> select count(*) from scott.dept2;

 COUNT(*)

----------

12

07:59:50 SQL> drop tablespace lxtbs1 including contents and datafiles;

Tablespace dropped.

07:59:56 SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

08:00:58 SQL> !

Fri Mar 23 18:50:06 2012

drop tablespace cuug including contents and datafiles

Fri Mar 23 18:50:08 2012

Deleted file /u01/app/oracle/oradata/anny/cuug01.dbf

Completed: drop tablespace cuug including contents and datafiles

二、转储所有数据文件

[oracle@cuug14 ~]$ cp /orabak/orcl/cold_bak/*.dbf /disk1/oradata/orcl

08:03:26 SQL> recover database until time '2012-02-12 07:59:53' using backup controlfile;

ORA-01034: ORACLE not available

08:04:12 SQL> startup mount

ORACLE instance started.

Total System Global Area  167772160 bytes

Fixed Size                  1218316 bytes

Variable Size              75499764 bytes

Database Buffers           88080384 bytes

Redo Buffers                2973696 bytes

Database mounted.

三、recover  database

08:04:36 SQL> recover database until time '2012-02-12 07:59:53' using backup controlfile;

ORA-00279: change 831098 generated at 02/12/2012 06:32:28 needed for thread 1

ORA-00289: suggestion : /arch/orcl/arch_1_6_775023202.log

ORA-00280: change 831098 for thread 1 is in sequence #6

08:04:45 Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

auto

ORA-00279: change 832010 generated at 02/12/2012 07:55:37 needed for thread 1

ORA-00289: suggestion : /arch/orcl/arch_1_1_775036537.log

ORA-00280: change 832010 for thread 1 is in sequence #1

ORA-00279: change 832995 generated at 02/12/2012 07:58:39 needed for thread 1

ORA-00289: suggestion : /arch/orcl/arch_1_2_775036537.log

ORA-00280: change 832995 for thread 1 is in sequence #2

ORA-00278: log file '/arch/orcl/arch_1_1_775036537.log' no longer needed for this recovery

ORA-00279: change 832997 generated at 02/12/2012 07:58:40 needed for thread 1

ORA-00289: suggestion : /arch/orcl/arch_1_3_775036537.log

ORA-00280: change 832997 for thread 1 is in sequence #3

ORA-00278: log file '/arch/orcl/arch_1_2_775036537.log' no longer needed for this recovery

ORA-00279: change 833000 generated at 02/12/2012 07:58:43 needed for thread 1

ORA-00289: suggestion : /arch/orcl/arch_1_4_775036537.log

ORA-00280: change 833000 for thread 1 is in sequence #4

ORA-00278: log file '/arch/orcl/arch_1_3_775036537.log' no longer needed for this recovery

ORA-00279: change 833017 generated at 02/12/2012 07:59:13 needed for thread 1

ORA-00289: suggestion : /arch/orcl/arch_1_5_775036537.log

ORA-00280: change 833017 for thread 1 is in sequence #5

ORA-00278: log file '/arch/orcl/arch_1_4_775036537.log' no longer needed for this recovery

ORA-00279: change 833019 generated at 02/12/2012 07:59:14 needed for thread 1

查看本栏目更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/database/Oracle/

时间: 2024-08-22 14:40:57

oracle基于backup control的完全恢复的相关文章

Oracle 基于 RMAN 的不完全恢复(incomplete recovery by RMAN)

      Oracle 数据库可以实现数据库不完全恢复与完全恢复.完全恢复是将数据库恢复到最新时刻,也就是无损恢复,保证数据库无丢失的恢复.而不完全恢复则是根据需要特意将数据库恢复到某个过去的特定时间点或特定的SCN以及特定的Sequence.我们可以通过基于用户管理的不完全恢复实现,也可以通过基于RMAN方式来实现.本文主要描述是基于RMAN的不完全恢复的几种情形并给出示例.有关数据库备份恢复,RMAN备份恢复的概念与实战可以参考文章尾部给出的链接.   一.不完全恢复的步骤    a.关闭

Oracle基于用户管理的不完全恢复(五)误删除表空间

案例4--误删除表空间(有备份) 通过备份的控制文件找到与表空间有关的信息进行恢复,因为新的控制文件里面已经没有该表空间的信息了.实际上在整个恢复过程中还是利用归档日志进行恢复,如果删除表空间之前的操作有及时写入到归档信息,就会全部恢复出来.下面的案例分切换日志和不切换日志两种. 1.基于backup control 的不完全恢复 SQL> select file_id,file_name,tablespace_name from dba_data_files; FILE_ID FILE_NAM

Oracle 基于备份控制文件的恢复(unsing backup controlfile)

    Oracle 基于备份控制文件的恢复(unsing backup controlfile)     有关RMAN的备份恢复与管理请参考     RMAN 概述及其体系结构     RMAN 配置.监控与管理     RMAN 备份详解     RMAN 还原与恢复     RMAN catalog 的创建和使用     基于catalog 创建RMAN存储脚本     基于catalog 的RMAN 备份与恢复     RMAN 备份路径困惑     使用RMAN实现异机备份恢复(WIN

Oracle基于用户管理的不完全恢复(一)不完全恢复的特性

Oracle 数据恢复从恢复类型来说,抛开具体的文件,总共可分为两大类型的恢复,一是完全恢复,一个是不完全恢复.其实,熟悉了Oracle体系结构之后,对于 Oracle恢复就会有一个总体的概念.因为Oracle组成的外围部分,主要由不同的文件来组成,每种不同类型的文件有不同的作用,因此只要了解了其作 用,更利于了解与掌握Oralce数据库的备份与恢复.言归正传,完全恢复即是把数据库恢复到最新的SCN,出故障前的那一刻,是无损恢复.而不完全恢复即是有损恢复,多用于恢复用户误操作,归档日志丢失等情形

Oracle 基于用户管理的不完全恢复

    Oracle 数据恢复从恢复类型来说,抛开具体的文件,总共可分为两大类型的恢复,一是完全恢复,一个是不完全恢复.其实,熟悉了Oracle体系结构之后,对于Oracle恢复就会有一个总体的概念.因为Oracle组成的外围部分,主要由不同的文件来组成,每种不同类型的文件有不同的作用,因此只要了解了其作用,更利于了解与掌握Oralce数据库的备份与恢复.言归正传,完全恢复即是把数据库恢复到最新的SCN,出故障前的那一刻,是无损恢复.而不完全恢复即是有损恢复,多用于恢复用户误操作,归档日志丢失等

Oracle基于用户管理的不完全恢复(四)完全恢复时丢失部分归档日志

案例3--在做完全恢复时,丢失了部分归档日志 (recover database until cancel;) 1.基于cancel 的不完全恢复 --模拟环境 SQL> col table_name for a20 SQL> col tablespace_name for a10 SQL> select table_name,tablespace_name from user_tables; TABLE_NAME           TABLESPACE ---------------

Oracle 基于用户管理恢复的处理

--================================ -- Oracle 基于用户管理恢复的处理 --================================       Oracle支持多种方式来管理数据文件的备份与恢复来保证数据库的可靠与完整.除了使用RMAN工具以及第三方备份与恢复工具之外,基于 用户管理的备份与恢复也是DBA经常使用的方式之一.本文首先介绍了恢复的相关概念,接下来详细讲述了在归档模式下使用基于用户管理恢 复的处理过程.    一.恢复的相关概念  

基于SCN的不完全恢复

        有几天没写了,呵呵!这几天比较忙,赶着做关于一个桌面搜索的软件.做了基于取消的不完全恢复和基于SCN的不完全恢复,一直没写成博客,现在可以补一下了. 先介绍一下:基于SCN 的不完全恢复是指将数据库恢复到某个特定的SCN 点的状态.当用户误执行了 drop table 或truncate table 之后,如果我们知道在这些操作点的SCN 的值,那么就可以使用基于SCN的不完全恢复方法了. 实验步骤如下: 1)先获取数据库当前的SCN值,模拟误删除实验表t1. SQL> sele

基于取消的不完全恢复

基于取消的不完全恢复是指数据库恢复到特定日志序列号之前的状态.当因丢失归档日志或重做日志完全恢复失败时,可以使用这种方法. 在做这个实验时我是将序列号位 23的日志文件删除了.实验表t1: SQL> select * from t1;        NUM                                                                      ----------