對於“化身”Incarnation概念了解之后，本篇通過手工恢復實驗來具體操作演示，加深對Incarnation的理解，來自於博客園AskScuti。
你可以點擊此處查看《概念理解篇》。
目錄
1. 官方圖示例
2. 場景模擬
3. 實驗步驟
3.1 備份數據庫（略）
3.2 查詢當前數據庫化身版本
3.3 按場景模擬操作
3.4 恢復出B表並打開數據庫
3.5 查詢當前數據庫化身版本
3.6 恢復出A-6（修改當前化身）並打開數據庫
3.7 查詢當前數據庫化身版本
1. 官方圖示例
在官方文檔 Release 19c Backup and Recovery User's Guide：14.3.2.2 Relationship Among Database Incarnations 中有這么一張示例圖片。（注意：每個版本都有，這里只是順手翻了最新版本）
此圖涉及三個版本的化身 Incarnation。
Incarnation 1：
最低位黑色水平線從 SCN1 開始，經歷 SCN1000，直到 SCN2000，這個為數據庫第一個化身，稱之為 Incarnation 1，這時候，化身1 就為當前化身（current incarnation）。
Incarnation 2：
假設在化身1中，我們執行了一個時間點恢復（不完全恢復），且指定的地方是 SCN1000 的位置，然后我們通過使用 Resetlogs 選項打開了數據庫，這時，化身2 就出現了（45°傾斜黑色實線），化身2 從SCN1000開始，持續到 SCN3000。這時候，我們稱化身1 是 化身2 的父級化身（parent incarnation），化身2 變為當前化身（current incarnation）。
Incarnation 3：
我們觀察下向右上角45°傾斜的這條黑色實線，它是化身2。在化身2中，它從 SCN1000開始，經過 SCN2000，持續到 SCN3000。假設在化身2 中，我們執行了一個時間點恢復（不完全恢復），且指定的地方是 SCN2000 的位置，然后通過 Resetlogs 選項打開數據庫，這時，化身3 就出現了（位於最高位的黑色水平線），化身3 從 SCN2000開始，持續到黑色水平線的 SCN3000。這時候，我們稱化身2 是 化身3 的父級化身，稱化身1 是 化身3 的祖輩級化身（ancestor incarnation），化身3 變為當前化身（current incarnation）。
2. 場景模擬
我們不妨來模擬一個場景：下面這張圖灰色區塊一共8個，這是8個動作。分別代表：表A插入1、表A插入2、表A插入3、表B插入666、Drop刪除表B、表A插入4、表A插入5、表A插入6。
我在操作完成表A數據6的插入后，發現了剛才剛才Drop掉了表B（這里不討論閃回技術），而表B數據很重要，需要做基於時間點的不完全恢復，然后以 Resetlogs 選項打開數據庫。這時數據庫第二個化身出現，如下圖
現在數據庫里面的操作都是基於化身2，后面我又想還是算了，重新還原恢復到 A-6 吧。於是還原舊的數據文件，然后進行恢復，試想會成功恢復到A-6嗎？前提又是什么呢？是可以成功的，前提是需要在RMAN里面指定使用哪一個化身。因為 A-4、A-5 和 A-6 都是屬於第一個原始化身：化身1，而現在數據庫是基於化身2的，如果使用現在數據庫的默認化身2，那么恢復出來的依然是第二個化身中的操作，就是得提前指定方向，你是想往水平方向（化身1）恢復呢，還是想往右上角方向（化身2）恢復。
同理，如果指定了往水平方向去恢復，恢復到A-6之后，依然需要使用 Resetlogs 選項打開數據庫，這時數據庫的第三個化身出現，而原第二化身變為孤兒化身（ORPHAN），如下圖
3. 實驗步驟
3.1 備份數據庫（略）
3.2 查詢當前數據庫化身版本（這里實驗環境多了一個化身，忽略）
SQL> select INCARNATION#,RESETLOGS_CHANGE#,RESETLOGS_TIME,STATUS from v$database_incarnation; INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS ------------ ----------------- ------------------ ------- 1 1 2011-09-17 09:46:04 PARENT 2 995548 2019-02-23 16:01:17 CURRENT
切歸檔，查看歸檔文件名稱
SQL> alter system archive log current; System altered. SQL> / System altered. SQL> / System altered. SQL> col name for a60 SQL> select name from v$archived_log; NAME -------------------------------------------- /u01/app/oracle/archive1/1_54_1001001677.dbf /u01/app/oracle/archive1/1_55_1001001677.dbf /u01/app/oracle/archive1/1_56_1001001677.dbf /u01/app/oracle/archive1/1_57_1001001677.dbf
注意歸檔日志名稱中的 1001001677 ，這是由數據庫歸檔參數 log_archive_format 定義的，默認情況下該參數對應的值為：%t_%s_%r.dbf
%t：thread number 日志線程號，單實例中就是1（這里不探討RAC環境）
%s：log sequence number 日志序列號，每次日志切換歸檔后，序列號加1
%r：resetlogs ID 日志重置ID號，這個就是控制化身Incarnation的，每次resetlogs后，該ID都會改變，日志序列號又從1開始。其目的是為了保證數據庫在跨多個化身版本時，保證歸檔日志名稱的唯一性。
3.3 按場景模擬操作
創建A表和B表，並按照場景模擬操作
SQL> create table a(id number); Table created. SQL> create table b(id number); Table created. SQL> insert into a values(1); 1 row created. SQL> insert into a values(2); 1 row created. SQL> insert into a values(3); 1 row created. SQL> insert into b values(666); 1 row created.
SQL> commit;
Commit complete. SQL> select sysdate from dual; SYSDATE ------------------- 2019-05-28 19:57:50 SQL> select current_scn from v$database; CURRENT_SCN ----------- 1520977 SQL> drop table b purge; Table dropped. SQL> insert into a values(4); 1 row created. SQL> insert into a values(5); 1 row created. SQL> insert into a values(6); 1 row created. SQL> commit; Commit complete.
3.4 恢復出B表並打開數據庫
這時，准備恢復出B表（B表中只有一條數據666）
還原舊的數據文件
SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> !cp /u01/app/oracle/backup/*.dbf /u01/app/oracle/oradata/PROD1/
做不完全恢復
SQL> startup mount ORACLE instance started. Total System Global Area 830930944 bytes Fixed Size 2232920 bytes Variable Size 591400360 bytes Database Buffers 234881024 bytes Redo Buffers 2416640 bytes Database mounted. SQL> select file#,change# from v$recover_file; FILE# CHANGE# ---------- ---------- 1 1519163 2 1519163 3 1519163 4 1519163 5 1519163 6 1519163 7 1519163 8 1519163 9 1519163 10 1519163 10 rows selected. SQL> recover database until change 1520977; ORA-00279: change 1519163 generated at 05/28/2019 19:29:20 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/archive1/1_55_1001001677.dbf ORA-00280: change 1519163 for thread 1 is in sequence #55 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} auto Log applied. Media recovery complete. SQL> alter database open resetlogs; Database altered.
3.5 查詢當前數據庫化身版本
完成基於時間點恢復后，查詢當前數據庫化身版本，對比3.2小節
SQL> select INCARNATION#,RESETLOGS_CHANGE#,RESETLOGS_TIME,STATUS from v$database_incarnation; INCARNATION# RESETLOGS RESETLOGS_TIME STATUS ------------ --------- ------------------- ------- 1 1 2011-09-17 09:46:04 PARENT 2 995548 2019-02-23 16:01:17 PARENT 3 1520978 2019-05-28 20:35:03 CURRENT
可以看到，當前數據庫使用的化身為3，我們嘗試切換日志生成歸檔，對比歸檔名稱
SQL> alter system archive log current; System altered. SQL> / System altered. SQL> / System altered. SQL> select name from v$archived_log; NAME -------------------------------------------- /u01/app/oracle/archive1/1_54_1001001677.dbf /u01/app/oracle/archive1/1_55_1001001677.dbf /u01/app/oracle/archive1/1_56_1001001677.dbf /u01/app/oracle/archive1/1_57_1001001677.dbf /u01/app/oracle/archive1/1_58_1001001677.dbf /u01/app/oracle/archive1/1_1_1009485303.dbf /u01/app/oracle/archive1/1_2_1009485303.dbf /u01/app/oracle/archive1/1_3_1009485303.dbf 8 rows selected.
可看到，當數據庫 resetlogs 后，歸檔日志名的 Incarnation 由原來的 1001001677 變為了現在的1009485303，且日志序列號，重新從1開始。
需要注意，Oracle 11g 是可以跨化身進行恢復的。（可以從化身為1001001677 的54號日志開始，一直應用到化身為1009485303的4號日志）
例如，這是另外一個實驗，還原舊的數據文件，然后進行完全恢復。仔細觀察歸檔的應用。
SQL> !cp /u01/app/oracle/backup/*.dbf /u01/app/oracle/oradata/PROD1/ SQL> startup mount ORACLE instance started. Total System Global Area 830930944 bytes Fixed Size 2232920 bytes Variable Size 591400360 bytes Database Buffers 234881024 bytes Redo Buffers 2416640 bytes Database mounted. SQL> recover database; ORA-00279: change 1519163 generated at 05/28/2019 19:29:20 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/archive1/1_55_1001001677.dbf ORA-00280: change 1519163 for thread 1 is in sequence #55 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} auto ORA-00279: change 1519932 generated at 05/28/2019 19:40:13 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/archive1/1_56_1001001677.dbf ORA-00280: change 1519932 for thread 1 is in sequence #56 ORA-00279: change 1519936 generated at 05/28/2019 19:40:14 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/archive1/1_57_1001001677.dbf ORA-00280: change 1519936 for thread 1 is in sequence #57 ORA-00279: change 1519941 generated at 05/28/2019 19:40:18 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/archive1/1_58_1001001677.dbf ORA-00280: change 1519941 for thread 1 is in sequence #58 ORA-00279: change 1520978 generated at 05/28/2019 20:35:03 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/archive1/1_1_1009485303.dbf ORA-00280: change 1520978 for thread 1 is in sequence #1 ORA-00279: change 1522809 generated at 05/28/2019 20:55:20 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/archive1/1_2_1009485303.dbf ORA-00280: change 1522809 for thread 1 is in sequence #2 ORA-00279: change 1522813 generated at 05/28/2019 20:55:22 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/archive1/1_3_1009485303.dbf ORA-00280: change 1522813 for thread 1 is in sequence #3 ORA-00279: change 1522817 generated at 05/28/2019 20:55:24 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/archive1/1_4_1009485303.dbf ORA-00280: change 1522817 for thread 1 is in sequence #4 ORA-00279: change 1523255 generated at 05/28/2019 21:01:35 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/archive1/1_5_1009485303.dbf ORA-00280: change 1523255 for thread 1 is in sequence #5 Log applied. Media recovery complete. SQL> alter database open; Database altered.
3.7 恢復出A-6（修改當前化身）並打開數據庫
查詢當前數據庫化身（這里實驗環境多了一個化身，忽略）
SQL> select INCARNATION#,RESETLOGS_CHANGE#,RESETLOGS_TIME,STATUS from v$database_incarnation; INCARNATION# RESETLOGS RESETLOGS_TIME STATUS ------------ --------- ------------------ ------ 1 1 2011-09-17 09:46:04 PARENT 2 995548 2019-02-23 16:01:17 PARENT 3 1520978 2019-05-28 20:35:03 CURRENT
當前數據庫正在使用3號 Incarnation，也就意味着，數據的恢復，目前只能走標數字號碼的這條線。
如果想要通過舊的數據文件，恢復到A-6，那么需要更改數據庫恢復路線，就是更改數據庫化身版本Incarnation，修改為2即可。（實驗環境，之前操作多了一個化身，可以忽略）
關閉數據庫，還原舊的數據文件。
SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> !cp /u01/app/oracle/backup/*.dbf /u01/app/oracle/oradata/PROD1/ SQL> startup mount; ORACLE instance started. Total System Global Area 830930944 bytes Fixed Size 2232920 bytes Variable Size 591400360 bytes Database Buffers 234881024 bytes Redo Buffers 2416640 bytes Database mounted.
連接RMAN，更改當前數據庫化身版本。
[oracle@henry ~]$ rman target / Recovery Manager: Release 11.2.0.3.0 - Production on Tue May 28 21:35:33 2019 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. connected to target database: PROD1 (DBID=2222344843, not open) RMAN> reset database to incarnation 2; using target database control file instead of recovery catalog database reset to incarnation 2
我們查看下當前數據庫使用的化身版本。
SQL> select INCARNATION#,RESETLOGS_CHANGE#,RESETLOGS_TIME,STATUS from v$database_incarnation; INCARNATION# RESETLOGS RESETLOGS_TIME STATUS ------------ --------- ------------------- ------ 1 1 2011-09-17 09:46:04 PARENT 2 995548 2019-02-23 16:01:17 CURRENT 3 1520978 2019-05-28 20:35:03 ORPHAN
現在，數據庫又使用了第一個化身版本，化身號為2，（化身號1為初始化身，忽略），而原第二個化身（化身號為3）狀態變為了孤兒化身（ORPHAN）。
現在將遵照下圖中標注的數字號這條線來恢復出A-6
然后，恢復數據庫，仔細觀察前滾的歸檔日志名稱。
SQL> recover database; ORA-00279: change 1519163 generated at 05/28/2019 19:29:20 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/archive1/1_55_1001001677.dbf ORA-00280: change 1519163 for thread 1 is in sequence #55 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} auto ORA-00279: change 1519932 generated at 05/28/2019 19:40:13 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/archive1/1_56_1001001677.dbf ORA-00280: change 1519932 for thread 1 is in sequence #56 ORA-00278: log file '/u01/app/oracle/archive1/1_55_1001001677.dbf' no longer needed for this recovery ORA-00279: change 1519936 generated at 05/28/2019 19:40:14 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/archive1/1_57_1001001677.dbf ORA-00280: change 1519936 for thread 1 is in sequence #57 ORA-00278: log file '/u01/app/oracle/archive1/1_56_1001001677.dbf' no longer needed for this recovery ORA-00279: change 1519941 generated at 05/28/2019 19:40:18 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/archive1/1_58_1001001677.dbf ORA-00280: change 1519941 for thread 1 is in sequence #58 ORA-00278: log file '/u01/app/oracle/archive1/1_57_1001001677.dbf' no longer needed for this recovery Log applied. Media recovery complete. SQL> alter database open resetlogs; Database altered.
確認A-6數據是否已經恢復
SQL> select * from a; ID ---------- 1 2 3 4 5 6 6 rows selected.
3.8 查詢當前數據庫化身版本
最后，我們再次查詢數據庫化身版本。對比3.2和3.7。
SQL> select INCARNATION#,RESETLOGS_CHANGE#,RESETLOGS_TIME,STATUS from v$database_incarnation; INCARNATION# RESETLOGS RESETLOGS_TIME STATUS ------------ --------- ------------------- ------ 1 1 2011-09-17 09:46:04 PARENT 2 995548 2019-02-23 16:01:17 PARENT 3 1520978 2019-05-28 20:35:03 ORPHAN 4 1521714 2019-05-28 21:50:58 CURRENT