关于一个不完全恢复的疑惑

最近讨论恢复的贴子好多,所以我也拿个出来讨论讨论,恢复的场景是:误操作删除表,并且控制文件也被损坏了,讨论只是为了彻底搞懂内部原量,避免下次犯同样的错误!

下面是我详细的实验步骤:

第一步:恢复过程通过观察用户gyj下的T1表,有一行数据。

idle> conn gyj/gyj     Connected.

gyj@OCM> select * from t1;

ID NAME

---------- ----------------------------------------------------------------------------------------------------

1 BBBBBBBB

第二步:正常关闭数据库,做全库的冷备

gyj@OCM> conn / as sysdba

Connected.

sys@OCM> select * from v$dbfile;

FILE# NAME

---------- -------------------------------

6 /u01/app/oracle/oradata/ocm/undotbs01.dbf

5 /u01/app/oracle/oradata/ocm/example01.dbf

3 /u01/app/oracle/oradata/ocm/tp1.dbf

2 /u01/app/oracle/oradata/ocm/sysaux01.dbf

1 /u01/app/oracle/oradata/ocm/system01.dbf

4 /u01/app/oracle/oradata/ocm/tp2.dbf

6 rows selected.

sys@OCM> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

[oracle@ocm ~]$  cp -rf /u01/app/oracle/oradata/ocm/*  /backup/cold/

第三步:启动库,登录用户gyj,向T1表中插入一条数据

sys@OCM> startup

ORACLE instance started.

Total System Global Area  581750784 bytes

Fixed Size                  1337860 bytes

Variable Size             243271164 bytes

Database Buffers          314572800 bytes

Redo Buffers               22568960 bytes

Database mounted.

Database opened.

sys@OCM> conn gyj/gyj

Connected.

gyj@OCM>  insert into t1 values(2,'AAAAAAA');

1 row created.

gyj@OCM> commit;

Commit complete.

第四步:查当前数据库系统时间

gyj@OCM> select to_char(sysdate,'yyyy-mm-dd:hh24:mi:ss') from dual;

TO_CHAR(SYSDATE,'YY

-------------------

2013-05-01:20:11:39

第五步:再查一条数据到T1表

gyj@OCM>  insert into t1 values(3,'CCCCCCCCC');

1 row created.

gyj@OCM> commit;

Commit complete.

第六步:模拟用户误操作,做了drop,把不该drop的T1表给干掉了!!!!

gyj@OCM>   drop table t1;

Table dropped.

第七步:假设我的控制文件这时也损坏了

[oracle@ocm ocm]$ rm -rf control0*

第八步:数据库过会马上就宕机

sys@OCM> shutdown abort;

ORACLE instance shut down.

第九步:假设我现在要做不完全恢复,而且我做基于时间的不完全恢复,恢复到2013-05-01:20:11:39

预期的结果,不完全恢复后表里面应该是两条记录:

gyj@OCM> select * from t1;

ID NAME

---------- ----------------------------------------------------------------------------------------------------

1 BBBBBBBB

2 AAAAAAA

第十步:开始恢复

(1)还原控制文件

[oracle@ocm ~]$ cp  /backup/cold/*.ctl /u01/app/oracle/oradata/ocm/

(2)还原数据文件

[oracle@ocm ~]$ cp /backup/cold/*.dbf /u01/app/oracle/oradata/ocm/

(3)启动数据库到mount

sys@OCM> startup mount;

ORACLE instance started.

Total System Global Area  581750784 bytes

Fixed Size                  1337860 bytes

Variable Size             243271164 bytes

Database Buffers          314572800 bytes

Redo Buffers               22568960 bytes

Database mounted.

(4)不完全恢复

sys@OCM> recover database until time '2013-05-01:20:11:39';

Media recovery complete.

(5)用resetlogs打开数据库

 sys@OCM> alter database open resetlogs;

Database altered.

第十一步:验证T1表的结果是不是两条记录

sys@OCM> conn gyj/gyj

Connected.

gyj@OCM> select * from t1;

ID NAME

---------- ----------------------------------------------------------------------------------------------------

1 BBBBBBBB

只有一条记录,这是什么情况呢???????????

问题应该出在第十步:开始恢复的(4)不完全恢复这一步,如果在这步的恢复命令改为:

recover database until time '2013-05-01:20:11:39' using backup controlfile;

就可以了,但为啥Oracle这里不提示错误呢,在用户管理下对备份的控制文件做恢复应该必须加using backup controlfile.

但我这里没加using backup controlfile为啥没提示你加呢,恢复照样成功,但结果不是你想要的!!!

时间: 2024-10-07 08:39:55

关于一个不完全恢复的疑惑的相关文章

基于时间点的不完全恢复的例子

说到不完全恢复,一般有三种场景,基于时间点的不完全恢复,基于scn的不完全恢复,基于cancel的不完全恢复. 三种情况都是不完全恢复采用的方式,而不完全恢复都是在完全恢复的过程中出现了这样那样的错误,数不胜数,基本就是归档,redo损坏丢失,控制文件丢失,备份的问题,手工失误等等. 我们可以举一个不完全恢复的案例,其实在实际操作的过程中还是有一些值得总结和学习的地方. 第一步准备基本的数据.目前我们可以看到在表空间data上只有一个表new_recover SQL> select owner,

Listen Software解决方案 “How To” 系列5:日志文件

解决  Listen Software解决方案 "How To" 系列5:日志文件 用实例管理器创建数据库(Oracle9i中已废除,故略去) 创建开发环境(略去)  日志文件  所有有关日志文件 重设日志选项 完成一个完整冷备份 1)创建一个数据库原形,在所有数据库文件的头部放入一个新的scn. 2)重设日志序列号到1 3)如果存在,重新格式化联机重做日志  无意恢复联机重做日志 当恢复数据库时,可能偶然地恢复联机重做日志.这将迫使完成一个不完全恢复而不是完全恢复.  状态和位置: 

Oracle Flashback Database的操作示例

做操作前先备份数据库 RMAN> backup database; 1. 检查是否启动了flash recovery area:   SQL> show parameter db_recovery_file NAME                    TYPE        VALUE ------------------------------------  ----------- ------------------------------ db_recovery_file_dest

我的五年百度博客文章列表(带链接版)

五年前,懵懵懂懂进入百度空间,五年后,总结一下在百度上贡献的文章(技术贴)以及收藏的文章.数了数大约450篇. name   urlservlet过滤器2 解决用户非法在线filter http://hi.baidu.com/ae6623/item/617c46c5a96b6dd196445292servlet过滤器1 解决字符集乱码filter  http://hi.baidu.com/ae6623/item/a006f07f0813c615d1dcb366GBK和UTF-8之间的战争,web

oracle数据库掉电导致系统崩溃的恢复过程

这里简单记录一下,此次国庆加班恢复的某客户的2套Oracle RAC数据库,整个恢复过程中,2套rac差不多,因此这里以其中一套数据库的恢复过程为例进行简单分析说明.数据库由于为非归档,由于掉电导致重启之后系统无法正常open. 在正常open的过程中,报错如下错误: SQL> alter database open; alter database open * ERROR at line 1: ORA-00600: internal error code, arguments: [kcratr

Oracle RAC数据库掉电导致系统崩溃的恢复过程

这里简单记录一下,此次国庆加班恢复的某客户的2套Oracle RAC数据库,整个恢复过程中,2套rac差不多,因此这里以其中一套数据库的恢复过程为例进行简单分析说明.数据库由于为非归档,由于掉电导致重启之后系统无法正常open. 在正常open的过程中,报错如下错误: SQL> alter database open; alter database open * ERROR at line 1: ORA-00600: internal error code, arguments: [kcratr

Oracle 表空间时点恢复(TSPITR)

表空间时点恢复,是Oracle在基于冷备,热备恢复以外的一种以表空间为粒度的,不完全恢复的形式来将表空间恢复到过去某个特定的时间点的一种恢复方式.它整合了RMAN以及DataPump这2个备份恢复工具来实现时点恢复.那它具体的过程和逻辑是怎样的?下文是其具体的描述. 一.什么是表空间时点恢复 Oracle表空间时点恢复有2个需要理解的概念. 恢复粒度   表空间级别,也就是说恢复的粒度是以表空间为单位 时点恢复   时点恢复意味着是一个不完全恢复.也就是说可以把某个或几个表空间恢复到过去的特定时

我的五年百度博客文章列表

五年前,懵懵懂懂进入百度空间,五年后,总结一下在百度上贡献的文章(技术贴)以及收藏的文章.数了数大约450篇. name    urlservlet过滤器2 解决用户非法在线 filter http://hi.baidu.com/ae6623/item/617c46c5a96b6dd196445292servlet过滤器1 解决字符集乱码 filter  http://hi.baidu.com/ae6623/item/a006f07f0813c615d1dcb366GBK和UTF-8之间的战争,

Apache Spark源码走读(十)ShuffleMapTask计算结果的保存与读取 &WEB UI和Metrics初始化及数据更新过程分析

<一>ShuffleMapTask计算结果的保存与读取 概要 ShuffleMapTask的计算结果保存在哪,随后Stage中的task又是如何知道从哪里去读取的呢,这个过程一直让我困惑不已. 用比较通俗一点的说法来解释一下Shuffle数据的写入和读取过程 每一个task负责处理一个特定的data partition task在初始化的时候就已经明确处理结果可能会产生多少个不同的data partition 利用partitioner函数,task将处理结果存入到不同的partition,这