在rman恢復中incarnation的概念

空白葛發表於2019-07-18

摘要

　　本文主要介紹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，多多動手實驗才是王道。

 

 

相關文章