ORACLE多次执行不完全恢复

昨天在做不完全恢复实验时,发现一个意思的现象,即可以多次执行不完全恢复,即使以resetlogs的方式打开数据库后,依然可以用之前的备份做不完全恢复,恢复到resetlogs之前或之后都可以。

下面演示以resetlogs打开数据库后再次用之前的备份做不完全恢复,恢复到resetlogs之前的时间。

首先看下备份的时间:

RMAN> list backup of database;

 

使用目标数据库控制文件替代恢复目录

 

备份集列表

===================

 

 

BS 关键字  类型 LV 大小       设备类型 经过时间 完成时间

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

33      Full    1.41G      DISK        00:03:49     20140722 13:58:07

        BP 关键字: 34   状态: AVAILABLE  已压缩: NO  标记: TAG20140722T135418

段名:D:\APP\WJ\PRODUCT\11.1.0\DB_1\DATABASE\14PE1LGA_1_1

  备份集 33 中的数据文件列表

  文件 LV 类型 Ckp SCN    Ckp 时间          名称

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

  1       Full 4302670    20140722 13:54:31 D:\APP\WJ\ORADATA\ORCL11G\SYSTEM01.DBF

  2       Full 4302670    20140722 13:54:31 D:\APP\WJ\ORADATA\ORCL11G\SYSAUX01.DBF

  3       Full 4302670    20140722 13:54:31 D:\APP\WJ\ORADATA\ORCL11G\UNDOTBS01.DBF

  4       Full 4302670    20140722 13:54:31 D:\APP\WJ\ORADATA\ORCL11G\USERS01.DBF

  5       Full 4302670    20140722 13:54:31 D:\APP\WJ\ORADATA\ORCL11G\EXAMPLE01.DBF

  6       Full 4302670    20140722 13:54:31 D:\APP\WJ\ORADATA\ORCL11G\TX.DBF

  7       Full 4302670    20140722 13:54:31 D:\ORACLE\DWSEE_INDEX.DBF

  8       Full 4302670    20140722 13:54:31 D:\ORACLE\DWODS_DATA_INDEX.DBF

  9       Full 4302670    20140722 13:54:31 D:\ORACLE\KETTLE4_DATA.DBF

  10      Full 4302670    20140722 13:54:31 D:\ORACLE\DWODS.DBF

  11      Full 4302670    20140722 13:54:31 D:\ORACLE\DWSEE_DATA_INDEX.DBF

  12      Full 4302670    20140722 13:54:31 D:\APP\WJ\ORADATA\ORCL11G\USERS02.DBF

备份时间是20140722 13:54:31

 

记录当前的下SCN:

SQL> SELECT dbms_flashback.get_system_change_number() FROM dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

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

                       4380487  

 

查看归档日志的情况:

SQL> SELECT a.NAME,a.SEQUENCE#,a.NEXT_CHANGE#,TO_CHAR(a.RESETLOGS_TIME,'yyyy-mm-dd hh24:mi:ss') RESETLOGS_TIME,to_char(a.FIRST_TIME,'YYYY-MM-DD HH24:MI:SS') FIRST_TIME FROM v$archived_log a WHERE a.NAME IS NOT NULL ;

 

NAME                            SEQUENCE# NEXT_CHANGE# RESETLOGS_TIME      FIRST_TIME

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

D:\WJARC00096_0817241642.001           96      4307515 2013-06-04 19:34:02 2014-07-22 13:58:16

D:\WJARC00097_0817241642.001           97      4334059 2013-06-04 19:34:02 2014-07-22 15:35:38

D:\WJARC00095_0817241642.001           95      4302884 2013-06-04 19:34:02 2014-07-22 13:52:50

D:\WJARC00098_0817241642.001           98      4334837 2013-06-04 19:34:02 2014-07-22 20:07:17

D:\WJARC00001_0853623513.001            1      4378498 2014-07-22 21:38:33 2014-07-22 21:38:33  

可以看到在21:38:33以resetlogs的方式打开发数据库,并且做了日志切换,日志序列变成1,但是NEXT_CHANGE#不是1,说明日志的变化是连续的,而不是重新开始。

 

 

再看数据库以resetlogs打开的历史,每次以resetlogs打开数据库都会创建一个数据库的化身:

SQL> SELECT a.INCARNATION#,a.RESETLOGS_CHANGE#,to_char(a.RESETLOGS_TIME,'YYYY-MM-DD HH24:MI:SS'),a.STATUS FROM v$database_incarnation a;

 

INCARNATION# RESETLOGS_CHANGE# TO_CHAR(A.RESETLOGS_TIME,'YYYY STATUS

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

           1                 1     2007-10-15 10:08:59             PARENT

           2            886308  2013-06-04 19:34:02             PARENT

           3           4334060 2014-07-22 21:18:33            ORPHAN

           4           4334060 2014-07-22 21:38:33            CURRENT  

CURRENT表示当前的数据库化身,上次resetlogs的时间是2014-07-22 21:38:33 。

 

现在尝试再做一次不完全恢复,恢复到昨天晚上18点10:

RMAN> run{

2> set until time '20140722 18:10:00';

3> restore database;

4> recover database;

5> }

 

正在执行命令: SET until clause

DBGANY:     Mismatched message length! [19:36:09.473] (krmiduem)

DBGANY:     Mismatched message length! [19:36:09.489] (krmiduem)

..................

RMAN-03002: set 命令 (在 07/23/2014 19:36:09 上) 失败

RMAN-20207: UNTIL TIME 或 RECOVERY WINDOW 在 RESETLOGS 时间之前

 

由于已经执行了resetlogs操作,要恢复到resetlogs之前时就会报错,因为当前的数据库化身是2014-07-22 21:38:33 ,该时间表示最新生成的日志是从2014-07-22 21:38:33  开始,因此数据库的恢复也应该使用该时间后的日志来恢复,所以这里是无法恢复的。

 

如果要恢复到昨天的18点10分,首先要设置数据库的化身,化身的时间必须小于要恢复的时间,这样才能用到化身之后的日志。

把数据库启动到mount下,然后执行

RMAN> reset database to incarnation 2;

RMAN> run{

2> set until time '20140722 18:10:00';

3> restore database ;

4> recover database ;

5> }

 

正在执行命令: SET until clause

使用目标数据库控制文件替代恢复目录

 

启动 restore 于 20140723 20:26:40

忽略 DISK 通道 4 的配置

忽略 DISK 通道 5 的配置

分配的通道: ORA_DISK_1

通道 ORA_DISK_1: SID=152 设备类型=DISK

 

通道 ORA_DISK_1: 正在开始还原数据文件备份集

通道 ORA_DISK_1: 正在指定从备份集还原的数据文件

通道 ORA_DISK_1: 将数据文件 00001 还原到 D:\APP\WJ\ORADATA\ORCL11G\SYSTEM01.DBF

通道 ORA_DISK_1: 将数据文件 00002 还原到 D:\APP\WJ\ORADATA\ORCL11G\SYSAUX01.DBF

通道 ORA_DISK_1: 将数据文件 00003 还原到 D:\APP\WJ\ORADATA\ORCL11G\UNDOTBS01.DBF

通道 ORA_DISK_1: 将数据文件 00004 还原到 D:\APP\WJ\ORADATA\ORCL11G\USERS01.DBF

。。。。。。。。。。。。。。。

 

线程 1 序列 95 的归档日志已作为文件 D:\WJARC00095_0817241642.001 存在于磁盘上

线程 1 序列 96 的归档日志已作为文件 D:\WJARC00096_0817241642.001 存在于磁盘上

线程 1 序列 97 的归档日志已作为文件 D:\WJARC00097_0817241642.001 存在于磁盘上

归档日志文件名=D:\WJARC00095_0817241642.001 线程=1 序列=95

归档日志文件名=D:\WJARC00096_0817241642.001 线程=1 序列=96

归档日志文件名=D:\WJARC00097_0817241642.001 线程=1 序列=97

介质恢复完成, 用时: 00:00:07

完成 recover 于 20140723 20:29:41

 

这样就完成了恢复。

以resetlogs打开数据库

SQL> alter database open resetlogs;

数据库已更改。

这时查看v$database_incarnation 表会发现多了一个数据库化身。

 

另一种情况:做完不完全恢复后,只要不以resetlogs打开数据库,不用设置数据库的化身就可以继续做不完全恢复。

如:

run{

set until time '20140722 18:10:00';

restore database ;

recover database ;

}

 

run{

set until time '20140722 14:10:00';

restore database ;

recover database ;

}

等,只要不以resetlogs打开,就可以反复的执行不完全恢复。

 

总结一下:

1.数据库化身的作用是标记使用何时的归档日志,数据库只能使用当前化身之后的归档日志。ORACLE这样做应该是方便管理可用的归档日志,显然即使没有化身这个功能,数据库也应该是能恢复的。

2.在resetlogs之后能执行不完全恢复并且恢复到resetlogs之前,关键之处就是归档日志中 NEXT_CHANGE#是连续并不会被重置为1,通过读取连续的修改内容来恢复数据库。

 

可以验证一下第2条,即使归档日志是连续的就可以恢复,那么用resetlogs之前的备份恢复到resetlogs之后的一个时间点。

刚才的不完全恢复的时间是是20140723 20:29:41随后执行了alter database open resetlogs操作,现在向前恢复到20140723 20:56:00:

首先要启动到mount下:

SQL> shutdown immediate;

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

SQL> startup mount;

ORACLE 例程已经启动。

 

Total System Global Area  431038464 bytes

Fixed Size                  1333676 bytes

Variable Size             335545940 bytes

Database Buffers           88080384 bytes

Redo Buffers                6078464 bytes

数据库装载完毕。

RMAN> run{

2> set until time '20140723 20:56:00';

3> restore database ;

4> recover database ;

5> }

 

正在执行命令: SET until clause

使用目标数据库控制文件替代恢复目录

 

启动 restore 于 20140723 21:09:05

忽略 DISK 通道 4 的配置

忽略 DISK 通道 5 的配置

分配的通道: ORA_DISK_1

通道 ORA_DISK_1: SID=152 设备类型=DISK

 

通道 ORA_DISK_1: 正在开始还原数据文件备份集

通道 ORA_DISK_1: 正在指定从备份集还原的数据文件

通道 ORA_DISK_1: 将数据文件 00001 还原到 D:\APP\WJ\ORADATA\ORCL11G\SYSTEM01.DBF

通道 ORA_DISK_1: 将数据文件 00002 还原到 D:\APP\WJ\ORADATA\ORCL11G\SYSAUX01.DBF

。。。。。。。。。。。。。。。。。

正在开始介质的恢复

 

线程 1 序列 95 的归档日志已作为文件 D:\WJARC00095_0817241642.001 存在于磁盘上

线程 1 序列 96 的归档日志已作为文件 D:\WJARC00096_0817241642.001 存在于磁盘上

线程 1 序列 97 的归档日志已作为文件 D:\WJARC00097_0817241642.001 存在于磁盘上

线程 1 序列 1 的归档日志已作为文件 D:\WJARC00001_0853706036.001 存在于磁盘上

归档日志文件名=D:\WJARC00095_0817241642.001 线程=1 序列=95

归档日志文件名=D:\WJARC00096_0817241642.001 线程=1 序列=96

归档日志文件名=D:\WJARC00097_0817241642.001 线程=1 序列=97

介质恢复完成, 用时: 00:00:08

完成 recover 于 20140723 21:11:46

 

用resetlogs之前的备份恢复到resetlogs之后成功。

 

 

参考:http://blog.csdn.net/haibusuanyun/article/details/14228427

 

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值