在rman恢复中incarnation的概念

摘要

　　本文主要介绍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操作。

　　

 [oracle@redhat3 ~]$ rman target /

 Recovery Manager: Release 11.2.0.4.0 - Production on Thu Jul 18 10:10:37 2019

 Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

 connected to target database: TEST (DBID=2274480208, not open)

 RMAN> list incarnation;

 using target database control file instead of recovery catalog

 List of Database Incarnations
 DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
 ------- ------- -------- ---------------- --- ---------- ----------
 1       1       TEST     2274480208       PARENT  4483656    11-JUL-19
 2       2       TEST     2274480208       CURRENT 4504768    11-JUL-19

对数据库进行不完全恢复

　　首先对数据库进行rman备份，此处不做过多说明。

　　查看现有rman备份，可知数据文件6的scn为457020，即数据最小可指定恢复SCN号为457020，（实验一中会给出说明），最大可指定SCN号为归档文件的25号的4597382（下面会进行演示），所以指定SCN号恢复时，SCN区间应在457020-4597382之间。

 RMAN> list backup;

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

 BS Key  Type LV Size       Device Type Elapsed Time Completion Time
 ------- ---- -- ---------- ----------- ------------ ---------------
 1       Full    237.04M    DISK        00:01:08     18-JUL-19
         BP Key: 1   Status: AVAILABLE  Compressed: NO  Tag: TAG20190718T093005
         Piece Name: /u01/app/rmanbak/db_TEST_20190718_01u6uu0u_1
   List of Datafiles in backup set 1
   File LV Type Ckp SCN    Ckp Time  Name
   ---- -- ---- ---------- --------- ----
   2       Full 4596984    18-JUL-19 /u01/app/oracle/oradata/test/sysaux01.dbf
   4       Full 4596984    18-JUL-19 /u01/app/oracle/oradata/test/users01.dbf
   7       Full 4596984    18-JUL-19 /u01/app/oracle/oradata/test/sde01.dbf

 BS Key  Type LV Size       Device Type Elapsed Time Completion Time
 ------- ---- -- ---------- ----------- ------------ ---------------
 2       Full    307.69M    DISK        00:01:10     18-JUL-19
         BP Key: 2   Status: AVAILABLE  Compressed: NO  Tag: TAG20190718T093005
         Piece Name: /u01/app/rmanbak/db_TEST_20190718_02u6uu0u_1
   List of Datafiles in backup set 2
   File LV Type Ckp SCN    Ckp Time  Name
   ---- -- ---- ---------- --------- ----
   1       Full 4596985    18-JUL-19 /u01/app/oracle/oradata/test/system01.dbf
   8       Full 4596985    18-JUL-19 /u01/app/oracle/oradata/test/UNDO2.DBF

 BS Key  Type LV Size       Device Type Elapsed Time Completion Time
 ------- ---- -- ---------- ----------- ------------ ---------------
 3       Full    1.47M      DISK        00:00:00     18-JUL-19
         BP Key: 3   Status: AVAILABLE  Compressed: NO  Tag: TAG20190718T093005
         Piece Name: /u01/app/rmanbak/db_TEST_20190718_03u6uu3b_1
   List of Datafiles in backup set 3
   File LV Type Ckp SCN    Ckp Time  Name
   ---- -- ---- ---------- --------- ----
   6       Full 4597020    18-JUL-19 /u01/app/oracle/oradata/test/tbs_1.dbf
 。。。。。。。。。。。。。

   List of Archived Logs in backup set 11
   Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
   ---- ------- ---------- --------- ---------- ---------
   1    24      4597222    18-JUL-19 4597382    18-JUL-19
   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问题！！！！

 [oracle@redhat3 ~]$ rman target /
 Recovery Manager: Release 11.2.0.4.0 - Production on Thu Jul 18 10:26:56 2019
 Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
 connected to target database: TEST (DBID=2274480208, not open)
 RMAN> run{
 2> set until scn 4597019;
 3> restore database;
 4> recover database;
 5> }
 executing command: SET until clause
 Starting restore at 18-JUL-19
 using target database control file instead of recovery catalog
 allocated channel: ORA_DISK_1
 channel ORA_DISK_1: SID=5 device type=DISK
 RMAN-00571: ===========================================================
 RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
 RMAN-00571: ===========================================================
 RMAN-03002: failure of restore command at 07/18/2019 10:26:59
 RMAN-06026: some targets not found - aborting restore
 RMAN-06023: no backup or copy of datafile 6 found to restore

　　下面指定SCN 4597020恢复成功。

 RMAN> run{
 2> set until scn 4597020;
 3> restore database;
 4> recover database;
 5> }
 executing command: SET until clause
 Starting restore at 18-JUL-19
 using channel ORA_DISK_1
 channel ORA_DISK_1: starting datafile backup set restore
 。。。。。。。。。。
 channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
 Finished restore at 18-JUL-19
 Starting recover at 18-JUL-19
 using channel ORA_DISK_1
 starting media recovery
 。。。。。。。
 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。

 RMAN> run{
 2> set until scn 4597300;
 3> restore database;
 4> recover database;
 5> }
 executing command: SET until clause
 Starting restore at 18-JUL-19
 using channel ORA_DISK_1
 。。。。。。。。。。。。。。。。
 channel ORA_DISK_1: restored backup piece 1
 channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
 Finished restore at 18-JUL-19

 Starting recover at 18-JUL-19
 using channel ORA_DISK_1
 starting media recovery
 。。。。。。。。。。。。
 media recovery complete, elapsed time: 00:00:02
 Finished recover at 18-JUL-19

 RMAN> alter database open resetlogs;
 database opened

 RMAN> list incarnation;
 List of Database Incarnations
 DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
 ------- ------- -------- ---------------- --- ---------- ----------
 1       1       TEST     2274480208       PARENT  4483656    11-JUL-19
 2       2       TEST     2274480208       PARENT  4504768    11-JUL-19
 3       3       TEST     2274480208       CURRENT 4597301    18-JUL-19

实验三 incarnation reset

　　在实验二中，我们看到incarnation已经+1，如果在此时，需要重新恢复库至4597300之前的SCN号，将会出现什么情况？

　　清理之前恢复的数据文件，日志文件（不要清理控制文件）

　　如下所示，直接进行恢复，提示RMAN-20208，其实提示的也很清楚，就是告诉我们，控制文件里面已经记录过比这个SCN大的resetlogs，需要恢复的SCN不在当前数据库生命周期中。如需恢复，则需要把SCN重置到自己的生命周期中。

 [oracle@redhat3 ~]$ rman target /
 Recovery Manager: Release 11.2.0.4.0 - Production on Thu Jul 18 11:17:23 2019
 Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
 connected to target database: TEST (DBID=2274480208, not open)
 RMAN> list incarnation;
 using target database control file instead of recovery catalog

 List of Database Incarnations
 DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
 ------- ------- -------- ---------------- --- ---------- ----------
 1       1       TEST     2274480208       PARENT  4483656    11-JUL-19
 2       2       TEST     2274480208       PARENT  4504768    11-JUL-19
 3       3       TEST     2274480208       CURRENT 4597301    18-JUL-19

 RMAN> run{
 2> set until scn 4597280;
 3> restore database;
 4> recover database;
 5> }
 executing command: SET until clause
 Starting restore at 18-JUL-19
 RMAN-00571: ===========================================================
 RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
 RMAN-00571: ===========================================================
 RMAN-03002: failure of restore command at 07/18/2019 11:17:56
 RMAN-20208: UNTIL CHANGE is before RESETLOGS change

　　通过reset 命令可以重置数据库的生命周期。在重置后，可以看到第2号记录的STATUS字段调整为CURRENT。这时再进行恢复则正常。

 [oracle@redhat3 ~]$ rman target /
 Recovery Manager: Release 11.2.0.4.0 - Production on Thu Jul 18 11:23:55 2019
 Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
 connected to target database: TEST (DBID=2274480208, not open)
 RMAN> list incarnation;

 using target database control file instead of recovery catalog
 List of Database Incarnations
 DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
 ------- ------- -------- ---------------- --- ---------- ----------
 1       1       TEST     2274480208       PARENT  4483656    11-JUL-19
 2       2       TEST     2274480208       PARENT  4504768    11-JUL-19
 3       3       TEST     2274480208       CURRENT 4597301    18-JUL-19

 RMAN> reset database to incarnation 2;

 database reset to incarnation 2

 RMAN> list incarnation;

 List of Database Incarnations
 DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
 ------- ------- -------- ---------------- --- ---------- ----------
 1       1       TEST     2274480208       PARENT  4483656    11-JUL-19
 2       2       TEST     2274480208       CURRENT 4504768    11-JUL-19
 3       3       TEST     2274480208       ORPHAN  4597301    18-JUL-19

 RMAN> run{
 2> set until scn 4597280;
 3> restore database;
 4> recover database;
 5> }
 executing command: SET until clause
 Starting restore at 18-JUL-19
 allocated channel: ORA_DISK_1
 channel ORA_DISK_1: SID=5 device type=DISK
 channel ORA_DISK_1: starting datafile backup set restore
 。。。。。。。。。。。

总结

　　通过上述的实验，我们可得出以下结论：

　　1、rman恢复如指定SCN，则需要通过查看备份中数据文件的最大SCN号最为起点。

　　2、在resetlogs后，如要恢复之前的SCN，则需要进行reset前身。（如果控制文件是重新恢复的，则不需要）

　　3、实践是检验真理的唯一标准，作为DBA，多多动手实验才是王道。