reset incarnation的分析之一

xulongxc發表於2014-03-03
上午剛處理完客戶的一個問題,正在發呆,一個哥們在msn上跟我發了個連結,問起我Oracle裡incarnation的問題,本來也沒想那麼多,回答了幾個問題,後來覺得這麼說說不明白,乾脆做個演示好了,於是就在這兩天,作了一些incarnation的測試。
先解釋一下我對incarnation的理解吧,incarnation,我把這個叫做資料庫實體,不知道其他人怎麼個叫法,從含義上看,它指的是一個重置scn後的資料庫場景。一個資料庫在剛開始被建立出來時,scn號為1,隨著執行,scn不斷單調遞增,Oracle就是根據scn描述資料庫的整個發展程式,可以說scn就是資料庫的時間軸。當資料庫正常執行,或者執行完全恢復時,scn只會單調遞增直到最新的scn,這樣資料庫中所有的資料都按照時間的順序改變著,但如果資料庫出現了人為誤操作,需要執行不完全恢復,這時候就得用以前備份的所有資料檔案將資料版本回到以前,然後從那個起點開始應用日誌,直到出現人為故障之前的那一刻,但這時,scn並未到達最新的scn,而是到了之前的某個scn,在這一刻,人為故障還未發生。在完成recover .. until .. 的操作後,所有的資料檔案透過應用日誌到了統一的一點,但資料庫暫時還不能正常開啟,因為控制檔案中記錄的是最新的scn,與應用日誌後的資料檔案並不一致,因此無法直接開啟資料庫回到原始的狀態,必須透過resetlogs的方式強制控制檔案、重做日誌檔案以及資料檔案的scn一致,此時新開啟的資料庫中第一個scn等於應用日誌到的最後一條日誌的scn號+1(在告警日誌檔案中可以看到RESETLOGS after incomplete recovery UNTIL CHANGE 145936 這樣的資訊,開啟資料庫後的scn則為145937)。資料庫每次resetlogs之後,scn和日誌序列號都被重置,因此每次resetlogs都會產生一個新的incarnation,而incarnation的資訊儲存在控制檔案中,在rman中可以透過list incarnation看到實體資訊。[@more@]

我們交流的問題主要是Oracle在控制檔案中為什麼要儲存實體資訊,相應的reset database命令有什麼用?
在下面的例子中也可以看到,Oracle在控制檔案中記錄實體資訊,一方面可以清楚的看到資料庫實體的發展過程(畢竟resetlogs對資料庫是一個具有較大影響的動作,必須能夠清楚的檢視到資料庫生命期內出現的所有實體資訊),另一方面,也可以透過reset database命令選擇在rman中將要操作的資料庫實體,進而將資料庫恢復到某個以前實體對應的資料生命期,這個功能在以前8i的時候是不支援的,從9i開始,可以重置實體到以前,使用resetlogs之前的備份進行資料庫恢復。具體操作如下:

--在實體5中對資料庫進行全庫備份

RMAN> backup database format='c:bakdf_%d_%s_%p.bak';

啟動 backup 於 26-3月 -08
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=143 devtype=DISK
通道 ORA_DISK_1: 啟動全部資料檔案備份集
通道 ORA_DISK_1: 正在指定備份集中的資料檔案
輸入資料檔案 fno=00001 name=E:ORACLEPRODUCT10.2.0ORADATAORCLSYSTEM01.DBF
輸入資料檔案 fno=00002 name=E:ORACLEPRODUCT10.2.0ORADATAORCLUNDOTBS01.DBF
輸入資料檔案 fno=00003 name=E:ORACLEPRODUCT10.2.0ORADATAORCLSYSAUX01.DBF
輸入資料檔案 fno=00004 name=E:ORACLEPRODUCT10.2.0ORADATAORCLUSERS01.DBF
通道 ORA_DISK_1: 正在啟動段 1 於 26-3月 -08
通道 ORA_DISK_1: 已完成段 1 於 26-3月 -08
段控制程式碼=C:BAKDF_ORCL_26_1.BAK 標記=TAG20080326T224202 註釋=NONE
通道 ORA_DISK_1: 備份集已完成, 經過時間:00:01:16
通道 ORA_DISK_1: 啟動全部資料檔案備份集
通道 ORA_DISK_1: 正在指定備份集中的資料檔案
備份集中包括當前控制檔案
在備份集中包含當前的 SPFILE
通道 ORA_DISK_1: 正在啟動段 1 於 26-3月 -08
通道 ORA_DISK_1: 已完成段 1 於 26-3月 -08
段控制程式碼=C:BAKDF_ORCL_27_1.BAK 標記=TAG20080326T224202 註釋=NONE
通道 ORA_DISK_1: 備份集已完成, 經過時間:00:00:04
完成 backup 於 26-3月 -08

--關閉資料庫,將當前重做日誌檔案刪除,模擬故障,造成resetlogs的恢復場景

RMAN> shutdown immediate

資料庫已關閉
資料庫已解除安裝
Oracle 例項已關閉

RMAN> startup mount

已連線到目標資料庫 (未啟動)
Oracle 例項已啟動
資料庫已裝載

系統全域性區域總計 314572800 位元組

Fixed Size 1248768 位元組
Variable Size 79692288 位元組
Database Buffers 226492416 位元組
Redo Buffers 7139328 位元組

RMAN> alter database open resetlogs;
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: alter db 命令 (在 03/26/2008 22:50:16 上) 失敗
ORA-01139: RESETLOGS 選項僅在不完全資料庫恢復後有效

RMAN> recover database;

啟動 recover 於 26-3月 -08
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=157 devtype=DISK

正在開始介質的恢復
無法恢復介質
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: recover 命令 (在 03/26/2008 22:50:36 上) 失敗
ORA-00283: recovery session canceled due to errors
RMAN-11003: 在分析/執行 SQL 語句期間失敗: alter database recover if needed
start
ORA-00283: 恢復會話因錯誤而取消
ORA-19909: 資料檔案 1 屬於孤立的原型
ORA-01110: 資料檔案 1: 'E:ORACLEPRODUCT10.2.0ORADATAORCLSYSTEM01.DBF'

--強制開啟後,看到現在已經進入實體6
RMAN> alter database open resetlogs;

資料庫已開啟

RMAN> list incarnation;


資料庫原型列表
DB 關鍵字 Inc 關鍵字 DB 名 DB ID STATUS 重置 SCN 重置時間
------- ------- -------- ---------------- --- ---------- ----------
1 1 ORCL 1176767170 PARENT 1 10-3月 -08
2 2 ORCL 1176767170 PARENT 472611 25-3月 -08
3 3 ORCL 1176767170 PARENT 474163 25-3月 -08
4 4 ORCL 1176767170 PARENT 488631 26-3月 -08
5 5 ORCL 1176767170 PARENT 490308 26-3月 -08
6 6 ORCL 1176767170 CURRENT 504418 26-3月 -08

--將資料庫關閉,重新啟動資料庫到mount狀態
RMAN> shutdown immediate

資料庫已關閉
資料庫已解除安裝
Oracle 例項已關閉

RMAN> startup mount

已連線到目標資料庫 (未啟動)
Oracle 例項已啟動
資料庫已裝載

系統全域性區域總計 314572800 位元組

Fixed Size 1248768 位元組
Variable Size 79692288 位元組
Database Buffers 226492416 位元組
Redo Buffers 7139328 位元組


--實體5中有備份,現在需要將資料庫恢復到實體5的資料中,首先重置實體
RMAN> reset database to incarnation 5;

將資料庫重置為原型 5

--在重置實體後,restore和recover都會針對重置設定的實體進行,rman自動選擇重置到的實體5所對應的備份進行恢復
RMAN> restore database;

啟動 restore 於 26-3月 -08
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=157 devtype=DISK

通道 ORA_DISK_1: 正在開始恢復資料檔案備份集
通道 ORA_DISK_1: 正在指定從備份集恢復的資料檔案
正將資料檔案00001恢復到E:ORACLEPRODUCT10.2.0ORADATAORCLSYSTEM01.DBF
正將資料檔案00002恢復到E:ORACLEPRODUCT10.2.0ORADATAORCLUNDOTBS01.DBF
正將資料檔案00003恢復到E:ORACLEPRODUCT10.2.0ORADATAORCLSYSAUX01.DBF
正將資料檔案00004恢復到E:ORACLEPRODUCT10.2.0ORADATAORCLUSERS01.DBF
通道 ORA_DISK_1: 正在讀取備份段 C:BAKDF_ORCL_26_1.BAK
通道 ORA_DISK_1: 已恢復備份段 1
段控制程式碼 = C:BAKDF_ORCL_26_1.BAK 標記 = TAG20080326T224202
通道 ORA_DISK_1: 恢復完成, 用時: 00:01:07
完成 restore 於 26-3月 -08

RMAN> recover database;

啟動 recover 於 26-3月 -08
使用通道 ORA_DISK_1

正在開始介質的恢復

無法找到存檔日誌
存檔日誌執行緒 =1 序列=3
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: recover 命令 (在 03/26/2008 22:54:34 上) 失敗
RMAN-06054: 介質恢復正請求未知的日誌: 執行緒 1 seq 3 lowscn 504053

RMAN> list incarnation;


資料庫原型列表
DB 關鍵字 Inc 關鍵字 DB 名 DB ID STATUS 重置 SCN 重置時間
------- ------- -------- ---------------- --- ---------- ----------
1 1 ORCL 1176767170 PARENT 1 10-3月 -08
2 2 ORCL 1176767170 PARENT 472611 25-3月 -08
3 3 ORCL 1176767170 PARENT 474163 25-3月 -08
4 4 ORCL 1176767170 PARENT 488631 26-3月 -08
5 5 ORCL 1176767170 CURRENT 490308 26-3月 -08
6 6 ORCL 1176767170 ORPHAN 504418 26-3月 -08

--在應用日誌後,強制開啟資料庫,可以看到已經將實體5重置為新的實體7,但實體7的scn大於實體5的scn,但小於實體6的scn
RMAN> alter database open resetlogs;

資料庫已開啟

RMAN> list incarnation;


資料庫原型列表
DB 關鍵字 Inc 關鍵字 DB 名 DB ID STATUS 重置 SCN 重置時間
------- ------- -------- ---------------- --- ---------- ----------
1 1 ORCL 1176767170 PARENT 1 10-3月 -08
2 2 ORCL 1176767170 PARENT 472611 25-3月 -08
3 3 ORCL 1176767170 PARENT 474163 25-3月 -08
4 4 ORCL 1176767170 PARENT 488631 26-3月 -08
5 5 ORCL 1176767170 PARENT 490308 26-3月 -08
7 7 ORCL 1176767170 CURRENT 504054 26-3月 -08
6 6 ORCL 1176767170 ORPHAN 504418 26-3月 -08

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29440247/viewspace-1098816/,如需轉載,請註明出處,否則將追究法律責任。

相關文章