ORACLE多次執行不完全恢復

昨天在做不完全恢復實驗時,發現一個意思的現象,即可以多次執行不完全恢復,即使以resetlogs的方式打開數據庫後,依然可以用之前的備份做不完全恢復,恢復到resetlogs之前或之後都可以。
下面演示以resetlogs打開數據庫後再次用之前的備份做不完全恢復,恢復到resetlogs之前的時間。
首先看下備份的時間:
RMAN> list backup of database;

使用目標數據庫控制文件替代恢復目錄

備份集列表
===================


BS 關鍵字  類型 LV 大小       設備類型 經過時間 完成時間
------- ---- -- ---------- ----------- ------------ -----------------
33      Full    1.41G      DISK        00:03:49     20140722 13:58:07
        BP 關鍵字: 34   狀態: AVAILABLE  已壓縮: NO  標記: TAG20140722T135418
段名:D:\APP\WJ\PRODUCT\11.1.0\DB_1\DATABASE\14PE1LGA_1_1
  備份集 33 中的數據文件列表
  文件 LV 類型 Ckp SCN    Ckp 時間          名稱
  ---- -- ---- ---------- ----------------- ----
  1       Full 4302670    20140722 13:54:31 D:\APP\WJ\ORADATA\ORCL11G\SYSTEM01.DBF
  2       Full 4302670    20140722 13:54:31 D:\APP\WJ\ORADATA\ORCL11G\SYSAUX01.DBF
  3       Full 4302670    20140722 13:54:31 D:\APP\WJ\ORADATA\ORCL11G\UNDOTBS01.DBF
  4       Full 4302670    20140722 13:54:31 D:\APP\WJ\ORADATA\ORCL11G\USERS01.DBF
  5       Full 4302670    20140722 13:54:31 D:\APP\WJ\ORADATA\ORCL11G\EXAMPLE01.DBF
  6       Full 4302670    20140722 13:54:31 D:\APP\WJ\ORADATA\ORCL11G\TX.DBF
  7       Full 4302670    20140722 13:54:31 D:\ORACLE\DWSEE_INDEX.DBF
  8       Full 4302670    20140722 13:54:31 D:\ORACLE\DWODS_DATA_INDEX.DBF
  9       Full 4302670    20140722 13:54:31 D:\ORACLE\KETTLE4_DATA.DBF
  10      Full 4302670    20140722 13:54:31 D:\ORACLE\DWODS.DBF
  11      Full 4302670    20140722 13:54:31 D:\ORACLE\DWSEE_DATA_INDEX.DBF
  12      Full 4302670    20140722 13:54:31 D:\APP\WJ\ORADATA\ORCL11G\USERS02.DBF
備份時間是20140722 13:54:31

記錄當前的下SCN:
SQL> SELECT dbms_flashback.get_system_change_number() FROM dual;
 
DBMS_FLASHBACK.GET_SYSTEM_CHAN
------------------------------
                       4380487  

查看歸檔日誌的情況:
SQL> SELECT a.NAME,a.SEQUENCE#,a.NEXT_CHANGE#,TO_CHAR(a.RESETLOGS_TIME,'yyyy-mm-dd hh24:mi:ss') RESETLOGS_TIME,to_char(a.FIRST_TIME,'YYYY-MM-DD HH24:MI:SS') FIRST_TIME FROM v$archived_log a WHERE a.NAME IS NOT NULL ;
 
NAME                            SEQUENCE# NEXT_CHANGE# RESETLOGS_TIME      FIRST_TIME
------------------------------ ---------- ------------ ------------------- -------------------
D:\WJARC00096_0817241642.001           96      4307515 2013-06-04 19:34:02 2014-07-22 13:58:16
D:\WJARC00097_0817241642.001           97      4334059 2013-06-04 19:34:02 2014-07-22 15:35:38
D:\WJARC00095_0817241642.001           95      4302884 2013-06-04 19:34:02 2014-07-22 13:52:50
D:\WJARC00098_0817241642.001           98      4334837 2013-06-04 19:34:02 2014-07-22 20:07:17
D:\WJARC00001_0853623513.001            1      4378498 2014-07-22 21:38:33 2014-07-22 21:38:33  
可以看到在21:38:33以resetlogs的方式打開發數據庫,並且做了日誌切換,日誌序列變成1,但是NEXT_CHANGE#不是1,說明日誌的變化是連續的,而不是重新開始。


再看數據庫以resetlogs打開的歷史,每次以resetlogs打開數據庫都會創建一個數據庫的化身:
SQL> SELECT a.INCARNATION#,a.RESETLOGS_CHANGE#,to_char(a.RESETLOGS_TIME,'YYYY-MM-DD HH24:MI:SS'),a.STATUS FROM v$database_incarnation a;
 
INCARNATION# RESETLOGS_CHANGE# TO_CHAR(A.RESETLOGS_TIME,'YYYY STATUS
------------ ----------------- ------------------------------ -------
           1                 1     2007-10-15 10:08:59             PARENT
           2            886308  2013-06-04 19:34:02             PARENT
           3           4334060 2014-07-22 21:18:33            ORPHAN
           4           4334060 2014-07-22 21:38:33            CURRENT  
CURRENT表示當前的數據庫化身,上次resetlogs的時間是2014-07-22 21:38:33 。

現在嘗試再做一次不完全恢復,恢復到昨天晚上18點10:
RMAN> run{
2> set until time '20140722 18:10:00';
3> restore database;
4> recover database;
5> }

正在執行命令: SET until clause
DBGANY:     Mismatched message length! [19:36:09.473] (krmiduem)
DBGANY:     Mismatched message length! [19:36:09.489] (krmiduem)
..................
RMAN-03002: set 命令 (在 07/23/2014 19:36:09 上) 失敗
RMAN-20207: UNTIL TIME 或 RECOVERY WINDOW 在 RESETLOGS 時間之前

由於已經執行了resetlogs操作,要恢復到resetlogs之前時就會報錯,因爲當前的數據庫化身是2014-07-22 21:38:33 ,該時間表示最新生成的日誌是從2014-07-22 21:38:33  開始,因此數據庫的恢復也應該使用該時間後的日誌來恢復,所以這裏是無法恢復的。

如果要恢復到昨天的18點10分,首先要設置數據庫的化身,化身的時間必須小於要恢復的時間,這樣才能用到化身之後的日誌。
把數據庫啓動到mount下,然後執行
RMAN> reset database to incarnation 2;
RMAN> run{
2> set until time '20140722 18:10:00';
3> restore database ;
4> recover database ;
5> }

正在執行命令: SET until clause
使用目標數據庫控制文件替代恢復目錄

啓動 restore 於 20140723 20:26:40
忽略 DISK 通道 4 的配置
忽略 DISK 通道 5 的配置
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=152 設備類型=DISK

通道 ORA_DISK_1: 正在開始還原數據文件備份集
通道 ORA_DISK_1: 正在指定從備份集還原的數據文件
通道 ORA_DISK_1: 將數據文件 00001 還原到 D:\APP\WJ\ORADATA\ORCL11G\SYSTEM01.DBF
通道 ORA_DISK_1: 將數據文件 00002 還原到 D:\APP\WJ\ORADATA\ORCL11G\SYSAUX01.DBF
通道 ORA_DISK_1: 將數據文件 00003 還原到 D:\APP\WJ\ORADATA\ORCL11G\UNDOTBS01.DBF
通道 ORA_DISK_1: 將數據文件 00004 還原到 D:\APP\WJ\ORADATA\ORCL11G\USERS01.DBF
。。。。。。。。。。。。。。。

線程 1 序列 95 的歸檔日誌已作爲文件 D:\WJARC00095_0817241642.001 存在於磁盤上
線程 1 序列 96 的歸檔日誌已作爲文件 D:\WJARC00096_0817241642.001 存在於磁盤上
線程 1 序列 97 的歸檔日誌已作爲文件 D:\WJARC00097_0817241642.001 存在於磁盤上
歸檔日誌文件名=D:\WJARC00095_0817241642.001 線程=1 序列=95
歸檔日誌文件名=D:\WJARC00096_0817241642.001 線程=1 序列=96
歸檔日誌文件名=D:\WJARC00097_0817241642.001 線程=1 序列=97
介質恢復完成, 用時: 00:00:07
完成 recover 於 20140723 20:29:41

這樣就完成了恢復。
以resetlogs打開數據庫
SQL> alter database open resetlogs;
數據庫已更改。
這時查看v$database_incarnation 表會發現多了一個數據庫化身。

另一種情況:做完不完全恢復後,只要不以resetlogs打開數據庫,不用設置數據庫的化身就可以繼續做不完全恢復。
如:
run{
set until time '20140722 18:10:00';
restore database ;
recover database ;
}

run{
set until time '20140722 14:10:00';
restore database ;
recover database ;
}
等,只要不以resetlogs打開,就可以反覆的執行不完全恢復。

總結一下:
1.數據庫化身的作用是標記使用何時的歸檔日誌,數據庫只能使用當前化身之後的歸檔日誌。ORACLE這樣做應該是方便管理可用的歸檔日誌,顯然即使沒有化身這個功能,數據庫也應該是能恢復的。
2.在resetlogs之後能執行不完全恢復並且恢復到resetlogs之前,關鍵之處就是歸檔日誌中 NEXT_CHANGE#是連續並不會被重置爲1,通過讀取連續的修改內容來恢復數據庫。

可以驗證一下第2條,即使歸檔日誌是連續的就可以恢復,那麼用resetlogs之前的備份恢復到resetlogs之後的一個時間點。
剛纔的不完全恢復的時間是是20140723 20:29:41隨後執行了alter database open resetlogs操作,現在向前恢復到20140723 20:56:00:
首先要啓動到mount下:
SQL> shutdown immediate;
數據庫已經關閉。
已經卸載數據庫。
ORACLE 例程已經關閉。
SQL> startup mount;
ORACLE 例程已經啓動。

Total System Global Area  431038464 bytes
Fixed Size                  1333676 bytes
Variable Size             335545940 bytes
Database Buffers           88080384 bytes
Redo Buffers                6078464 bytes
數據庫裝載完畢。
RMAN> run{
2> set until time '20140723 20:56:00';
3> restore database ;
4> recover database ;
5> }

正在執行命令: SET until clause
使用目標數據庫控制文件替代恢復目錄

啓動 restore 於 20140723 21:09:05
忽略 DISK 通道 4 的配置
忽略 DISK 通道 5 的配置
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=152 設備類型=DISK

通道 ORA_DISK_1: 正在開始還原數據文件備份集
通道 ORA_DISK_1: 正在指定從備份集還原的數據文件
通道 ORA_DISK_1: 將數據文件 00001 還原到 D:\APP\WJ\ORADATA\ORCL11G\SYSTEM01.DBF
通道 ORA_DISK_1: 將數據文件 00002 還原到 D:\APP\WJ\ORADATA\ORCL11G\SYSAUX01.DBF
。。。。。。。。。。。。。。。。。
正在開始介質的恢復

線程 1 序列 95 的歸檔日誌已作爲文件 D:\WJARC00095_0817241642.001 存在於磁盤上
線程 1 序列 96 的歸檔日誌已作爲文件 D:\WJARC00096_0817241642.001 存在於磁盤上
線程 1 序列 97 的歸檔日誌已作爲文件 D:\WJARC00097_0817241642.001 存在於磁盤上
線程 1 序列 1 的歸檔日誌已作爲文件 D:\WJARC00001_0853706036.001 存在於磁盤上
歸檔日誌文件名=D:\WJARC00095_0817241642.001 線程=1 序列=95
歸檔日誌文件名=D:\WJARC00096_0817241642.001 線程=1 序列=96
歸檔日誌文件名=D:\WJARC00097_0817241642.001 線程=1 序列=97
介質恢復完成, 用時: 00:00:08
完成 recover 於 20140723 21:11:46

用resetlogs之前的備份恢復到resetlogs之後成功。





發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章