数据库按时间点恢复

您所在的位置：网站首页 › mysql数据库回退到某个时间点怎么办 › 数据库按时间点恢复

数据库按时间点恢复

2023-12-25 03:48| 来源: 网络整理| 查看: 265

按时间点恢复

数据库按时间点恢复，可以从要恢复的目标时间之前的备份中还的数据库，然后使用增量备份和重做日志来将数据库前滚到目标时间点,按时间点恢复也叫不完全恢复因为不使用所有的日志或者不完全恢复对数据库的所有改变。

数据库按时间点恢复所要满足的条件

1.数据库必须运行在archivelog模式下

2.必须要有恢复目标时间点之前所有数据文件的备份和在备份SCN与目标SCN之间所有的归档重做日志

每次以resetlogs选项打开数据库时一个新的数据库incarnation就会被创建。执行open resetlogs操作时就会对当前的联机重做日志文件进行归档。incarnation会将重做日志序列号设置为1,并且指联机重做日志一个新的时间戳。它也会增加incarnation的序号，它被用来唯一标记和识另重做日志流。

incarnation可能存在的几种关系

1.current incarnation是由那个incarnation执行open resetlog操作产生的，那个incarnation就是current incarnation的parent incarnation

2.parent incarnation和它parent incarnation的incarnation就叫作current incarnation的ancestor incarnations

3.如果两个incarnation共享相同的ancestor那么它们就是sibling incarnations

SQL> select * from v$database_incarnation;

INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TI PRIOR_RESETLOGS_CHANGE# PRIOR_RESETL STATUS RESETLOGS_ID PRIOR_INCARNATION# FLASHBACK_DATABASE_ALLOWED------------ ----------------- ------------ ----------------------- ------------ ------- ------------ ------------------ -------------------------- 1 1 30-JUN-05 0 PARENT 562360180 0 NO 2 446075 05-SEP-14 1 30-JUN-05 PARENT 857466832 1 NO 3 2849317 27-JAN-15 446075 05-SEP-14 PARENT 870102602 2 NO 4 2880152 27-JAN-15 2849317 27-JAN-15 PARENT 870133266 3 NO 5 3017109 01-FEB-15 2880152 27-JAN-15 PARENT 870550288 4 NO 6 3041066 01-FEB-15 3017109 01-FEB-15 PARENT 870563157 5 NO 7 3041350 01-FEB-15 3041066 01-FEB-15 PARENT 870564201 6 YES 8 3111834 03-FEB-15 3041350 01-FEB-15 ORPHAN 870724654 7 YES 9 3111834 03-FEB-15 3041350 01-FEB-15 ORPHAN 870726369 7 YES 10 3114665 03-FEB-15 3041350 01-FEB-15 ORPHAN 870726883 7 YES 11 3114664 03-FEB-15 3041350 01-FEB-15 CURRENT 870729934 7 YES

11 rows selected.

RMAN> list incarnation;

要执行按时间点恢复需要准备好以下两个条件：

1.决定要恢复到的目标时间，SCN，还原点或者日志序列号。闪回查询，闪回版本查询和闪回事务查询可能帮助你来识别逻辑错误。也可以检查alert.log的信息来帮助你判断恢复的目标时间点。另外也可以判断包含目标SCN的日志序列号然后通过日志进行恢复。例如，查询v$log_history来查看已经归档的日志信息。

SQL> select * from v$log_history;

RECID STAMP THREAD# SEQUENCE# FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# RESETLOGS_CHANGE# RESETLOGS_TI---------- ---------- ---------- ---------- ------------- ------------ ------------ ----------------- ------------ 231 870563592 1 2 3041294 01-FEB-15 3041343 3041066 01-FEB-15 232 870564201 1 3 3041343 01-FEB-15 3041349 3041066 01-FEB-15 233 870597597 1 1 3041350 01-FEB-15 3063719 3041350 01-FEB-15 234 870684680 1 2 3063719 02-FEB-15 3097923 3041350 01-FEB-15 235 870724659 1 3 3097923 03-FEB-15 3114664 3041350 01-FEB-15 236 870726371 1 1 3111834 03-FEB-15 3112739 3111834 03-FEB-15 237 870726883 1 1 3111834 03-FEB-15 3114664 3111834 03-FEB-15 238 870729935 1 1 3114665 03-FEB-15 3116367 3114665 03-FEB-15 239 870769788 1 1 3114664 03-FEB-15 3135728 3114664 03-FEB-15

例如，如果你发在上午10点1分一个用户意外删除了一个表空间，那么可以将数据库恢复到上午10点，就是在删除表空间前的时间点。在恢复之后在上午10点之后的所有改变都会丢失.

2.如果使用目标时间表达式代替目标SCN，那么在使用RMAN之前要确保时间格式的环境变量设置合适。

NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'

使用current incarnation来执行按时间点恢复

使用current incarnation执行按时间点恢复时是使用的当前版本的控制文件。当执行按时间点恢复时，可以使用set until命令来设置恢复的目标时间，而不用对restotre和recover命令单独设置until子句从而避免出错。这能确保从备份中还原的数据文件的时间戳早于后续的recover操作。

按时间点恢复的过程如下：

我们把scott用户下的表emp中的所有记录删除,并且在删除之前记录了当前系统的SCN，然后执行按时间点恢复来恢复表中的记录。

SQL> select current_scn from v$database;

CURRENT_SCN----------- 3142264

SQL> select to_char(scn_to_timestamp(3142264),'yyyy-mm-dd hh24:mi:ss') from dual;

TO_CHAR(SCN_TO_TIME-------------------2015-02-04 11:22:29

SQL> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------ 1 1 4 52428800 1 NO CURRENT 3142228 04-FEB-15 3 1 3 52428800 1 YES INACTIVE 3142176 04-FEB-15 2 1 2 52428800 1 YES INACTIVE 3135728 04-FEB-15

SQL> select * from emp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO---------- ---------- --------- ---------- ------------ ---------- ---------- ---------- 7369 SMITH CLERK 7902 17-DEC-80 800 20 7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30 7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30 7566 JONES MANAGER 7839 02-APR-81 2975 20 7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400 30 7698 BLAKE MANAGER 7839 01-MAY-81 2850 30 7782 CLARK MANAGER 7839 09-JUN-81 2450 10 7788 SCOTT ANALYST 7566 19-APR-87 3000 20 7839 KING PRESIDENT 17-NOV-81 5000 10 7844 TURNER SALESMAN 7698 08-SEP-81 1500 0 30 7876 ADAMS CLERK 7788 23-MAY-87 1100 20 7900 JAMES CLERK 7698 03-DEC-81 950 30 7902 FORD ANALYST 7566 03-DEC-81 3000 20 7934 MILLER CLERK 7782 23-JAN-82 1300 10

14 rows selected.

SQL> delete from emp;

14 rows deleted.

SQL> commit;

Commit complete.

SQL> select * from emp;

no rows selected

1.连接到目标数据库或恢复目录（如果有），将数据库启动到mount状态：

[oracle@oracle11g ~]$ rman target/

Recovery Manager: Release 10.2.0.5.0 - Production on Wed Feb 4 10:25:34 2015

connected to target database (not started)

RMAN> startup mount

Oracle instance starteddatabase mounted

Total System Global Area 327155712 bytes

Fixed Size 1273516 bytesVariable Size 138412372 bytesDatabase Buffers 184549376 bytesRedo Buffers 2920448 bytes

2.运行RUN块来执行按时间点恢复。在RUN块中使用set until来指定恢复的目标时间，还原点，SCN或日志序列号。如果指定的是目标时间，那么使用NLS_LANG和NLS_DATE_FORMAT环境变量所指定的格式。如果自动通道没有配置，那么要为访问的磁盘或磁带分配通道。

RMAN> run2> {3> set until scn 3142264;4> restore database;5> recover database;6> }

executing command: SET until clause

Starting restore at 04-FEB-15allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=157 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restorechannel ORA_DISK_1: specifying datafile(s) to restore from backup setrestoring datafile 00001 to /u01/app/oracle/oradata/test/system01.dbfrestoring datafile 00002 to /u01/app/oracle/oradata/test/undotbs01.dbfrestoring datafile 00003 to /u01/app/oracle/oradata/test/sysaux01.dbfrestoring datafile 00004 to /u01/app/oracle/oradata/test/users01.dbfrestoring datafile 00005 to /u01/app/oracle/oradata/test/example01.dbfrestoring datafile 00006 to /u01/app/oracle/oradata/test/test01.dbfrestoring datafile 00007 to /u01/app/oracle/oradata/test/testbak.dbfchannel ORA_DISK_1: reading from backup piece /u02/test_df870779983_s135_s1channel ORA_DISK_1: restored backup piece 1piece handle=/u02/test_df870779983_s135_s1 tag=TAG20150204T111943channel ORA_DISK_1: restore complete, elapsed time: 00:02:29Finished restore at 04-FEB-15

Starting recover at 04-FEB-15using channel ORA_DISK_1

starting media recoverymedia recovery complete, elapsed time: 00:00:02

Finished recover at 04-FEB-15

从alert日志文件中可以看到如下信息：

The input backup piece /u02/test_df870779983_s135_s1 is in compressed format.Full restore complete of datafile 6 /u01/app/oracle/oradata/test/test01.dbf. Elapsed time: 0:00:01 checkpoint is 3142189Full restore complete of datafile 7 /u01/app/oracle/oradata/test/testbak.dbf. Elapsed time: 0:00:06 checkpoint is 3142189Full restore complete of datafile 4 /u01/app/oracle/oradata/test/users01.dbf. Elapsed time: 0:00:09 checkpoint is 3142189 last deallocation scn is 3111848Wed Feb 04 11:25:47 CST 2015Full restore complete of datafile 2 /u01/app/oracle/oradata/test/undotbs01.dbf. Elapsed time: 0:00:37 checkpoint is 3142189 last deallocation scn is 3106509Wed Feb 04 11:25:58 CST 2015Full restore complete of datafile 5 /u01/app/oracle/oradata/test/example01.dbf. Elapsed time: 0:00:46 checkpoint is 3142189 last deallocation scn is 2526488Wed Feb 04 11:26:57 CST 2015Full restore complete of datafile 3 /u01/app/oracle/oradata/test/sysaux01.dbf. Elapsed time: 0:01:47 checkpoint is 3142189 last deallocation scn is 3099893Wed Feb 04 11:27:32 CST 2015Full restore complete of datafile 1 /u01/app/oracle/oradata/test/system01.dbf. Elapsed time: 0:02:20 checkpoint is 3142189 last deallocation scn is 3101877Wed Feb 04 11:27:39 CST 2015alter database recover datafile list clearWed Feb 04 11:27:39 CST 2015Completed: alter database recover datafile list clearWed Feb 04 11:27:39 CST 2015alter database recover datafile list 1 , 2 , 3 , 4 , 5 , 6 , 7Completed: alter database recover datafile list 1 , 2 , 3 , 4 , 5 , 6 , 7Wed Feb 04 11:27:39 CST 2015alter database recover if needed start until change 3142264Media Recovery StartWed Feb 04 11:27:40 CST 2015Recovery of Online Redo Log: Thread 1 Group 3 Seq 3 Reading mem 0 Mem# 0: /u01/app/oracle/oradata/test/redo03.logWed Feb 04 11:27:40 CST 2015Recovery of Online Redo Log: Thread 1 Group 1 Seq 4 Reading mem 0 Mem# 0: /u01/app/oracle/oradata/test/redo01.logWed Feb 04 11:27:40 CST 2015Incomplete Recovery applied until change 3142277Wed Feb 04 11:27:40 CST 2015Media Recovery Complete (test)Completed: alter database recover if needed start until change 3142264

从上面的恢复过程可以看到，首先从备份中还原数据文件，各个数据文件的checkpoint scn是3142189比我们的恢复目标SCN小，然后应用重做日志文件将数据库恢复到目标SCN所对应的时间点。

set until还可以使用时间表达式，还原点或者日志序列事情作为它的恢复目标时间点

set until time '2015-02-04 11:22:29';

set until sequence 4;

set until restore point before_delete;

如果按时间点恢复成功。可以以只读方式打开数据库来检查表emp的数据是否恢复回来了。如果表emp的记录没有恢复回来，可能我们选错了恢复目标SCN。在这种情况下，可以使用新的恢复目标SCN然后重新执行按时间点恢复。

RMAN> sql 'alter database open read only';

sql statement: alter database open read only

SQL> select * from emp;

14 rows selected.

从上面的结果可知表emp的记录通过按时间点恢复已经找回来了。

如果按时间点恢复经过验证后达到了恢复目标，可以有如下选择：

1.使用oracle导出工具将恢复的表emp进行逻辑导出。然后将数据库恢复到当前时间点后，再导入导出的数据。这样在不会丢失数据库的其它改变而又恢复了表emp的数据。

2.以读写方式打开数据库，这样在恢复目标SCN之后的所有改变将会丢失。当前的联机重做日志文件会被归档，日志序列号会被设置为1，并且所有的联机重做日志会被指定新的时间戳和SCN。

RMAN> alter database open resetlogs;

database opened

使用ancestor incarnation执行按时间点恢复

使用ancestor incarnation执行按时间点恢复与使用current incarnation的不同之处在于需要设置数据库的incarnation.并且必须从包含恢复目标SCN的incarnation中还原控制文件。

不使用recover catalog的情况

比如我们要将数据库恢复到scott用户的emp表被删除之后的时间点，对older incarnation执行按时间点恢复的过程如下:

1.判断要使用的incarnation。可以使用list incarnation命令来找到恢复目标时间所对应的incarnation

RMAN> list incarnation;

List of Database IncarnationsDB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time------- ------- -------- ---------------- --- ---------- ----------1 1 TEST 2155613261 PARENT 1 2005-06-30 19:09:402 2 TEST 2155613261 PARENT 446075 2014-09-05 09:13:523 3 TEST 2155613261 PARENT 2849317 2015-01-27 15:10:024 4 TEST 2155613261 PARENT 2880152 2015-01-27 23:41:065 5 TEST 2155613261 PARENT 3017109 2015-02-01 19:31:286 6 TEST 2155613261 PARENT 3041066 2015-02-01 23:05:577 7 TEST 2155613261 PARENT 3041350 2015-02-01 23:23:218 8 TEST 2155613261 ORPHAN 3111834 2015-02-03 19:57:349 9 TEST 2155613261 ORPHAN 3111834 2015-02-03 20:26:0911 11 TEST 2155613261 PARENT 3114664 2015-02-03 21:25:3410 10 TEST 2155613261 ORPHAN 3114665 2015-02-03 20:34:4312 12 TEST 2155613261 PARENT 3142278 2015-02-04 11:40:0213 13 TEST 2155613261 PARENT 3144077 2015-02-04 13:09:0314 14 TEST 2155613261 CURRENT 3144537 2015-02-04 13:32:41

当前的incarnation的Inc Key为14.通过下面的查询可以找到它之前的incarnation的Inc Key为13：

SQL> select prior_incarnation# from v$database_incarnation where status ='CURRENT';

PRIOR_INCARNATION#------------------ 13

2.将数据库启动到mount状态

RMAN> startup mount

Oracle instance starteddatabase mounted

Total System Global Area 327155712 bytes

Fixed Size 1273516 bytesVariable Size 138412372 bytesDatabase Buffers 184549376 bytesRedo Buffers 2920448 bytes

3.将数据库test的incarnation设置为incarnation号为13,也就是current incarnation的parent incarnation。

RMAN> reset database to incarnation 13;

database reset to incarnation 13

4.执行还原与恢复，设置恢复目标时间，如果没有配置相关通道设置通道。将数据库恢复到表emp删除之后的时间点（2015-02-04 13:30:01）：

RMAN> run2> {3> set until time '2015-02-04 13:30:01';4> restore database;5> recover database;6> }

executing command: SET until clause

Starting restore at 2015-02-04 13:54:37using channel ORA_DISK_1

Starting recover at 2015-02-04 13:57:14using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 3 is already on disk as file /u02/1_3_870729934.dbfarchive log thread 1 sequence 4 is already on disk as file /u02/1_4_870729934.dbfarchive log thread 1 sequence 1 is already on disk as file /u02/1_1_870781202.dbfarchive log filename=/u02/1_3_870729934.dbf thread=1 sequence=3archive log filename=/u02/1_4_870729934.dbf thread=1 sequence=4archive log filename=/u02/1_1_870781202.dbf thread=1 sequence=1archive log filename=/u02/1_1_870786543.dbf thread=1 sequence=1media recovery complete, elapsed time: 00:00:03Finished recover at 2015-02-04 13:57:18

RMAN> alter database open resetlogs;

database opened

RMAN> list incarnation;

使用recover catalog的情况

比如我们要将数据库恢复到scott用户的emp表被删除之后的时间点，对older incarnation执行按时间点恢复的过程如下:

1.判断要使用的incarnation。可以使用list incarnation命令来找到恢复目标时间所对应的incarnation

RMAN> list incarnation;

List of Database IncarnationsDB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time------- ------- -------- ---------------- --- ---------- ----------1 8 TEST 2168949517 PARENT 1 2010-04-19 10:22:461 2 TEST 2168949517 PARENT 383537 2015-02-04 17:44:491 102 TEST 2168949517 PARENT 415176 2015-02-04 18:22:161 188 TEST 2168949517 CURRENT 415481 2015-02-04 18:33:17

当前的incarnation的Inc Key为188.通过下面的查询可以找到它之前的incarnation的Inc Key为102：我们将数据库恢复到2015-02-04 18:22:30，也就是在SCN:415176和SCN:415481之间。

RMAN> list backup of controlfile;

List of Backup Sets===================

BS Key Type LV Size Device Type Elapsed Time Completion Time------- ---- -- ---------- ----------- ------------ -------------------75 Full 6.80M DISK 00:00:01 2015-02-04 18:11:38 BP Key: 77 Status: AVAILABLE Compressed: NO Tag: TAG20150204T181137 Piece Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870804697_bf3w2t62_.bkp Control File Included: Ckp SCN: 415111 Ckp time: 2015-02-04 18:11:37

BS Key Type LV Size Device Type Elapsed Time Completion Time------- ---- -- ---------- ----------- ------------ -------------------139 Full 6.80M DISK 00:00:02 2015-02-04 18:22:45 BP Key: 144 Status: AVAILABLE Compressed: NO Tag: TAG20150204T182243 Piece Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870805363_bf3wqnyv_.bkp Control File Included: Ckp SCN: 415288 Ckp time: 2015-02-04 18:22:43

BS Key Type LV Size Device Type Elapsed Time Completion Time------- ---- -- ---------- ----------- ------------ -------------------236 Full 6.80M DISK 00:00:03 2015-02-04 18:33:39 BP Key: 242 Status: AVAILABLE Compressed: NO Tag: TAG20150204T183336 Piece Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870806016_bf3xd2wl_.bkp Control File Included: Ckp SCN: 415765 Ckp time: 2015-02-04 18:33:36

从上面的控制文件备份信息可以看到要恢复到2015-02-04 18:22:30这个时间点应该使用控制文件备份是o1_mf_s_870805363_bf3wqnyv_.bkp

2.将数据库强制启动到nomount状态

RMAN> startup force nomount

Oracle instance started

Total System Global Area 327155712 bytes

Fixed Size 1273516 bytesVariable Size 138412372 bytesDatabase Buffers 184549376 bytesRedo Buffers 2920448 bytes

3.将数据库test的incarnation设置为incarnation号为102,也就是current incarnation的parent incarnation。

RMAN> reset database to incarnation 102;

database reset to incarnation 102

RMAN> list incarnation;

List of Database IncarnationsDB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time------- ------- -------- ---------------- --- ---------- ----------1 8 TEST 2168949517 PARENT 1 2010-04-19 10:22:461 2 TEST 2168949517 PARENT 383537 2015-02-04 17:44:491 102 TEST 2168949517 CURRENT 415176 2015-02-04 18:22:161 188 TEST 2168949517 ORPHAN 415481 2015-02-04 18:33:17

4.执行还原与恢复，设置恢复目标时间，如果没有配置相关通道设置通道。还原控制文件，将数据库恢复到表emp删除之后的时间点（2015-02-04 18:22:30）：

RMAN> restore controlfile;

Starting restore at 2015-02-04 18:44:23allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=156 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restorechannel ORA_DISK_1: restoring control filechannel ORA_DISK_1: reading from backup piece /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870805363_bf3wqnyv_.bkpchannel ORA_DISK_1: restored backup piece 1piece handle=/u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870805363_bf3wqnyv_.bkp tag=TAG20150204T182243channel ORA_DISK_1: restore complete, elapsed time: 00:00:03output filename=/u01/app/oracle/oradata/test/control01.ctloutput filename=/u01/app/oracle/oradata/test/control02.ctloutput filename=/u01/app/oracle/oradata/test/control03.ctlFinished restore at 2015-02-04 18:44:29

RMAN> alter database mount;

database mountedreleased channel: ORA_DISK_1

RMAN> restore database until time '2015-02-04 18:22:30';

Starting restore at 2015-02-04 18:47:15Starting implicit crosscheck backup at 2015-02-04 18:47:15allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=156 devtype=DISKCrosschecked 4 objectsFinished implicit crosscheck backup at 2015-02-04 18:47:17

Starting implicit crosscheck copy at 2015-02-04 18:47:17using channel ORA_DISK_1Finished implicit crosscheck copy at 2015-02-04 18:47:17

searching for all files in the recovery areacataloging files...cataloging done

List of Cataloged Files=======================File Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870805363_bf3wqnyv_.bkpFile Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870806016_bf3xd2wl_.bkp

using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backupset restorechannel ORA_DISK_1: specifying datafile(s) to restore from backup setrestoring datafile 00001 to /u01/app/oracle/oradata/test/system01.dbfrestoring datafile 00002 to /u01/app/oracle/oradata/test/undotbs01.dbfrestoring datafile 00003 to /u01/app/oracle/oradata/test/sysaux01.dbfrestoring datafile 00004 to /u01/app/oracle/oradata/test/users01.dbfrestoring datafile 00005 to /u01/app/oracle/oradata/test/example01.dbfchannel ORA_DISK_1: reading from backup piece /u01/app/oracle/flash_recovery_area/TEST/backupset/2015_02_04/o1_mf_nnndf_TAG20150204T181037_bf3w0y1f_.bkpchannel ORA_DISK_1: restored backup piece 1piece handle=/u01/app/oracle/flash_recovery_area/TEST/backupset/2015_02_04/o1_mf_nnndf_TAG20150204T181037_bf3w0y1f_.bkp tag=TAG20150204T181037channel ORA_DISK_1: restore complete, elapsed time: 00:01:15Finished restore at 2015-02-04 18:48:32

将数据文件还原到2015-02-04 18:22:30这个时间点，下面执行恢复，要注意的是在执行恢复操作之前还需要执行reset database to incarnation 102否则会报错:

RMAN> recover database until time '2015-02-04 18:22:30';

Starting recover at 2015-02-04 18:49:05using channel ORA_DISK_1RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of recover command at 02/04/2015 18:49:05RMAN-06004: ORACLE error from recovery catalog database: RMAN-20011: target database incarnation is not current in recovery catalog

再次执行 reset database to incarnation 102;

RMAN> reset database to incarnation 102;

database reset to incarnation 102

RMAN> recover database until time '2015-02-04 18:22:30';

Starting recover at 2015-02-04 18:49:21using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 3 is already on disk as file /u02/1_3_870803089.dbfarchive log thread 1 sequence 4 is already on disk as file /u02/1_4_870803089.dbfarchive log thread 1 sequence 1 is already on disk as file /u02/1_1_870805336.dbfarchive log filename=/u02/1_3_870803089.dbf thread=1 sequence=3archive log filename=/u02/1_4_870803089.dbf thread=1 sequence=4archive log filename=/u02/1_1_870805336.dbf thread=1 sequence=1media recovery complete, elapsed time: 00:00:01Finished recover at 2015-02-04 18:49:24

RMAN> alter database open resetlogs;

database openednew incarnation of database registered in recovery catalogstarting full resync of recovery catalogfull resync complete

RMAN> list incarnation;

List of Database IncarnationsDB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time------- ------- -------- ---------------- --- ---------- ----------1 8 TEST 2168949517 PARENT 1 2010-04-19 10:22:461 2 TEST 2168949517 PARENT 383537 2015-02-04 17:44:491 102 TEST 2168949517 PARENT 415176 2015-02-04 18:22:161 308 TEST 2168949517 CURRENT 415183 2015-02-04 18:49:411 188 TEST 2168949517 ORPHAN 415481 2015-02-04 18:33:17

可以看到恢复完成之后当前的incarnation对应的reset scn号在415176与415481之间，达到了我们所期待的结果。

【本文地址】

公司简介

联系我们