摘要
本文主要介绍incarnation的由来，在rman恢复中的作用，以及相关rman恢复的注意事项。
概念说明
从10g开始，incarnation被引入，用于跨越resetlogs进行恢复，由此可见，此概念在rman中可以找到相关使用轨迹。
Resetlogs命令表示一个数据库逻辑生存期的结束和另一个数据库逻辑生存期的开始，Oracle把这个数据库逻辑生存期称为incarnation；每次使用resetlogs打开数据库，就会使incarnation + 1，也就是产生一个新的incarnation；如果想要恢复到之前incarnation的scn/time，就需要先恢复到之前的incarnation；
下图来源官方文档，可以自行理解incarnation在 rman恢复的作用，其中灰色线是数据库rman恢复之后的运行路径。
实验环节
初识incarnation
在rman中可以可以通过list incarnation命令查看当前数据库有多少化身，新创建的数据库默认只有1条记录，下面所示2条记录，代表数据库做过rman不完全恢复，即进行过alter database open resetlogs操作。
1 [oracle@redhat3 ~]$ rman target / 2 3 Recovery Manager: Release 11.2.0.4.0 - Production on Thu Jul 18 10:10:37 2019 4 5 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. 6 7 connected to target database: TEST (DBID=2274480208, not open) 8 9 RMAN> list incarnation; 10 11 using target database control file instead of recovery catalog 12 13 List of Database Incarnations 14 DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time 15 ------- ------- -------- ---------------- --- ---------- ---------- 16 1 1 TEST 2274480208 PARENT 4483656 11-JUL-19 17 2 2 TEST 2274480208 CURRENT 4504768 11-JUL-19
对数据库进行不完全恢复
首先对数据库进行rman备份，此处不做过多说明。
查看现有rman备份，可知数据文件6的scn为457020，即数据最小可指定恢复SCN号为457020，（实验一中会给出说明），最大可指定SCN号为归档文件的25号的4597382（下面会进行演示），所以指定SCN号恢复时，SCN区间应在457020-4597382之间。
1 RMAN> list backup; 2 3 4 List of Backup Sets 5 =================== 6 7 8 BS Key Type LV Size Device Type Elapsed Time Completion Time 9 ------- ---- -- ---------- ----------- ------------ --------------- 10 1 Full 237.04M DISK 00:01:08 18-JUL-19 11 BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20190718T093005 12 Piece Name: /u01/app/rmanbak/db_TEST_20190718_01u6uu0u_1 13 List of Datafiles in backup set 1 14 File LV Type Ckp SCN Ckp Time Name 15 ---- -- ---- ---------- --------- ---- 16 2 Full 4596984 18-JUL-19 /u01/app/oracle/oradata/test/sysaux01.dbf 17 4 Full 4596984 18-JUL-19 /u01/app/oracle/oradata/test/users01.dbf 18 7 Full 4596984 18-JUL-19 /u01/app/oracle/oradata/test/sde01.dbf 19 20 BS Key Type LV Size Device Type Elapsed Time Completion Time 21 ------- ---- -- ---------- ----------- ------------ --------------- 22 2 Full 307.69M DISK 00:01:10 18-JUL-19 23 BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20190718T093005 24 Piece Name: /u01/app/rmanbak/db_TEST_20190718_02u6uu0u_1 25 List of Datafiles in backup set 2 26 File LV Type Ckp SCN Ckp Time Name 27 ---- -- ---- ---------- --------- ---- 28 1 Full 4596985 18-JUL-19 /u01/app/oracle/oradata/test/system01.dbf 29 8 Full 4596985 18-JUL-19 /u01/app/oracle/oradata/test/UNDO2.DBF 30 31 BS Key Type LV Size Device Type Elapsed Time Completion Time 32 ------- ---- -- ---------- ----------- ------------ --------------- 33 3 Full 1.47M DISK 00:00:00 18-JUL-19 34 BP Key: 3 Status: AVAILABLE Compressed: NO Tag: TAG20190718T093005 35 Piece Name: /u01/app/rmanbak/db_TEST_20190718_03u6uu3b_1 36 List of Datafiles in backup set 3 37 File LV Type Ckp SCN Ckp Time Name 38 ---- -- ---- ---------- --------- ---- 39 6 Full 4597020 18-JUL-19 /u01/app/oracle/oradata/test/tbs_1.dbf 40 。。。。。。。。。。。。。 41 42 List of Archived Logs in backup set 11 43 Thrd Seq Low SCN Low Time Next SCN Next Time 44 ---- ------- ---------- --------- ---------- --------- 45 1 24 4597222 18-JUL-19 4597382 18-JUL-19 46 1 25 4597382 18-JUL-19 4597393 18-JUL-19
实验一 验证最小可指定SCN号
注意我们指定的SCN为4597019，比上述数据文件6的scn457020还少1，报错为找不到文件6的备份。
个人理解，在restore database时，rman只能找到scn为457020的文件6，并没有比其SCN小的数据文件备份，所以报错，而其他几个数据文件在备份时，SCN号小于4597019，可以在recover database进行增量恢复。说白了就是文件6最小的SCN是从457020开始。
注：RMAN-06023 错也有可能是其他原因导致，此处实验只是为证明恢复时指定SCN问题！！！！
1 [oracle@redhat3 ~]$ rman target / 2 Recovery Manager: Release 11.2.0.4.0 - Production on Thu Jul 18 10:26:56 2019 3 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. 4 connected to target database: TEST (DBID=2274480208, not open) 5 RMAN> run{ 6 2> set until scn 4597019; 7 3> restore database; 8 4> recover database; 9 5> } 10 executing command: SET until clause 11 Starting restore at 18-JUL-19 12 using target database control file instead of recovery catalog 13 allocated channel: ORA_DISK_1 14 channel ORA_DISK_1: SID=5 device type=DISK 15 RMAN-00571: =========================================================== 16 RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 17 RMAN-00571: =========================================================== 18 RMAN-03002: failure of restore command at 07/18/2019 10:26:59 19 RMAN-06026: some targets not found - aborting restore 20 RMAN-06023: no backup or copy of datafile 6 found to restore
下面指定SCN 4597020恢复成功。
1 RMAN> run{ 2 2> set until scn 4597020; 3 3> restore database; 4 4> recover database; 5 5> } 6 executing command: SET until clause 7 Starting restore at 18-JUL-19 8 using channel ORA_DISK_1 9 channel ORA_DISK_1: starting datafile backup set restore 10 。。。。。。。。。。 11 channel ORA_DISK_1: restore complete, elapsed time: 00:00:03 12 Finished restore at 18-JUL-19 13 Starting recover at 18-JUL-19 14 using channel ORA_DISK_1 15 starting media recovery 16 。。。。。。。 17 Finished recover at 18-JUL-19
实验二 incarnation增长
在SCN区间457020-4597382中，选一个进行不完全恢复，然后resetlogs，查看incarnation会+1。指定4597300进行恢复。
可以发现在resetlogs后，执行list incarnation后，确认增加1条，且Reset SCN 4597301，比指定的4597300大1。数据库开启一个新的生命周期，在list incarnation命令中第3条记录的status 字段为CURRENT。
1 RMAN> run{ 2 2> set until scn 4597300; 3 3> restore database; 4 4> recover database; 5 5> } 6 executing command: SET until clause 7 Starting restore at 18-JUL-19 8 using channel ORA_DISK_1 9 。。。。。。。。。。。。。。。。 10 channel ORA_DISK_1: restored backup piece 1 11 channel ORA_DISK_1: restore complete, elapsed time: 00:00:03 12 Finished restore at 18-JUL-19 13 14 Starting recover at 18-JUL-19 15 using channel ORA_DISK_1 16 starting media recovery 17 。。。。。。。。。。。。 18 media recovery complete, elapsed time: 00:00:02 19 Finished recover at 18-JUL-19 20 21 RMAN> alter database open resetlogs; 22 database opened 23 24 RMAN> list incarnation; 25 List of Database Incarnations 26 DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time 27 ------- ------- -------- ---------------- --- ---------- ---------- 28 1 1 TEST 2274480208 PARENT 4483656 11-JUL-19 29 2 2 TEST 2274480208 PARENT 4504768 11-JUL-19 30 3 3 TEST 2274480208 CURRENT 4597301 18-JUL-19
实验三 incarnation reset
在实验二中，我们看到incarnation已经+1，如果在此时，需要重新恢复库至4597300之前的SCN号，将会出现什么情况？
清理之前恢复的数据文件，日志文件（不要清理控制文件）
如下所示，直接进行恢复，提示RMAN-20208，其实提示的也很清楚，就是告诉我们，控制文件里面已经记录过比这个SCN大的resetlogs，需要恢复的SCN不在当前数据库生命周期中。如需恢复，则需要把SCN重置到自己的生命周期中。
1 [oracle@redhat3 ~]$ rman target / 2 Recovery Manager: Release 11.2.0.4.0 - Production on Thu Jul 18 11:17:23 2019 3 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. 4 connected to target database: TEST (DBID=2274480208, not open) 5 RMAN> list incarnation; 6 using target database control file instead of recovery catalog 7 8 List of Database Incarnations 9 DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time 10 ------- ------- -------- ---------------- --- ---------- ---------- 11 1 1 TEST 2274480208 PARENT 4483656 11-JUL-19 12 2 2 TEST 2274480208 PARENT 4504768 11-JUL-19 13 3 3 TEST 2274480208 CURRENT 4597301 18-JUL-19 14 15 RMAN> run{ 16 2> set until scn 4597280; 17 3> restore database; 18 4> recover database; 19 5> } 20 executing command: SET until clause 21 Starting restore at 18-JUL-19 22 RMAN-00571: =========================================================== 23 RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 24 RMAN-00571: =========================================================== 25 RMAN-03002: failure of restore command at 07/18/2019 11:17:56 26 RMAN-20208: UNTIL CHANGE is before RESETLOGS change
通过reset 命令可以重置数据库的生命周期。在重置后，可以看到第2号记录的STATUS字段调整为CURRENT。这时再进行恢复则正常。
1 [oracle@redhat3 ~]$ rman target / 2 Recovery Manager: Release 11.2.0.4.0 - Production on Thu Jul 18 11:23:55 2019 3 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. 4 connected to target database: TEST (DBID=2274480208, not open) 5 RMAN> list incarnation; 6 7 using target database control file instead of recovery catalog 8 List of Database Incarnations 9 DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time 10 ------- ------- -------- ---------------- --- ---------- ---------- 11 1 1 TEST 2274480208 PARENT 4483656 11-JUL-19 12 2 2 TEST 2274480208 PARENT 4504768 11-JUL-19 13 3 3 TEST 2274480208 CURRENT 4597301 18-JUL-19 14 15 RMAN> reset database to incarnation 2; 16 17 database reset to incarnation 2 18 19 RMAN> list incarnation; 20 21 22 List of Database Incarnations 23 DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time 24 ------- ------- -------- ---------------- --- ---------- ---------- 25 1 1 TEST 2274480208 PARENT 4483656 11-JUL-19 26 2 2 TEST 2274480208 CURRENT 4504768 11-JUL-19 27 3 3 TEST 2274480208 ORPHAN 4597301 18-JUL-19 28 29 RMAN> run{ 30 2> set until scn 4597280; 31 3> restore database; 32 4> recover database; 33 5> } 34 executing command: SET until clause 35 Starting restore at 18-JUL-19 36 allocated channel: ORA_DISK_1 37 channel ORA_DISK_1: SID=5 device type=DISK 38 channel ORA_DISK_1: starting datafile backup set restore 39 。。。。。。。。。。。
总结
通过上述的实验，我们可得出以下结论：
1、rman恢复如指定SCN，则需要通过查看备份中数据文件的最大SCN号最为起点。
2、在resetlogs后，如要恢复之前的SCN，则需要进行reset前身。（如果控制文件是重新恢复的，则不需要）
3、实践是检验真理的唯一标准，作为DBA，多多动手实验才是王道。