Summary
This paper describes the origin of the incarnation, the role rman in recovery, as well as considerations related to rman recovery.
Concept Note
10g from the start, incarnation was introduced across resetlogs for recovery, we can see that this concept can be found in the relevant use rman track.
Resetlogs command indicates the beginning of a lifetime of logical database database logic of survival and another end, Oracle database logic this is called survival of the incarnation; each use resetlogs open the database, it will make the incarnation + 1, that is, to produce a new the incarnation; previous incarnation before if you want to return to scn / time, we need to return to incarnation;
The figure below official source documents, you can understand their own role in the incarnation rman recovery, in which the gray line is to run rman recovery path after the database.
Labs
Acquaintance incarnation
In rman that can be viewed through the command list incarnation number of the current database incarnation, the newly created database default only one record, two records as shown below, representing a database rman did not fully recover, that is conducted alter database open resetlogs operation .
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
The database is not fully restored
First, the database rman backup, do not do much to explain here.
See rman existing backup data files known as scn 6 457 020, i.e., data recovery may specify the minimum number 457020 SCN, (a test will be given below), to specify the maximum number of SCN No. 4,597,382 archive 25 ( the following will demonstrate), so the number specified when SCN recovery, SCN range should be between 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
A verification experiment can specify the minimum number SCN
Note that we specified SCN is 4597019, scn457020 than the above data file 6 is also one less, being given not find the file backup 6.
Understand, when restore database, rman only find scn for the 457 020 documents 6, and no backup than the SCN small data file, error, and several other data files during backup, SCN number is less than 4,597,019, can be recover database incremental recovery. It means the file 6 from 457,020 the minimum SCN is beginning.
Note: RMAN-06023 wrong there may be other reasons, but here experiments to prove the specified SCN problem when recovery! ! ! !
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
The following specified SCN 4597020 successful recovery.
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
The second experiment incarnation growth
In the SCN interval 457020-4597382, choose one of incomplete recovery, then resetlogs, will see +1 incarnation. 4,597,300 designated for recovery.
After RESETLOGS can be found, after performing list incarnation, a confirmation increases, and Reset SCN 4597301, 4597300 large than the specified one. Database start a new life cycle, in the list incarnation status field of the command recorded in Article 3 of 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
Third experiment incarnation reset
In the second experiment, we have seen incarnation +1, if at this time before the need to restore the library to 4597300 SCN number, what would happen?
Before cleaning up the recovery of data files, log files (do not clean up the control file)
As shown below, the direct recovery, suggesting RMAN-20208, in fact, prompt and very clear, it is to tell us, which has been recorded over the control file is larger than the SCN of resetlogs, need to restore the SCN not in the current database lifecycle. To restore, you need to take SCN reset to their life cycle.
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
You can reset the life cycle of the database via the reset command. After the reset, the STATUS field can see the recording No. 2 was adjusted to CURRENT. Then again restore it to normal.
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 。。。。。。。。。。。
to sum up
Through the above experiment, we can draw the following conclusions:
1, rman recovery as specified SCN, SCN is required by looking at the maximum number of backup data files most starting point.
2, after resetlogs, such as to restore the previous SCN, you need to be reset predecessor. (If the control file is restored, and is not required)
3, practice is the sole criterion for testing truth, as DBA, a lot of hands-on experiments is king.