對于RMAN恢複我一直都不是很明白,因為,老是搞不清楚不完全恢複該怎麼進行,今天,通過這個實驗即是對不完全恢複的實踐,
也是希望搞清楚incarnation到底是怎麼工作的.很可惜,本人對Oracle的了解還不入門,僅能做一點提示.在文末做為小結.
RMAN> list backup;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
1 Full 559.92M DISK 00:01:08 2016-08-13 20:17:08 =============[第一個時間點]==========
BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20160813T201600
Piece Name: /home/oracle10/flash_recovery_area/DBINFO/backupset/2016_08_13/o1_mf_nnndf_TAG20160813T201600_cty3w0sx_.bkp
List of Datafiles in backup set 1
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ------------------- ----
1 Full 1080165 2016-08-13 20:16:00 /home/oracle10/oradata/dbinfo/system01.dbf
2 Full 1080165 2016-08-13 20:16:00 /home/oracle10/oradata/dbinfo/undotbs01.dbf
3 Full 1080165 2016-08-13 20:16:00 /home/oracle10/oradata/dbinfo/sysaux01.dbf
4 Full 1080165 2016-08-13 20:16:00 /home/oracle10/oradata/dbinfo/users01.dbf
5 Full 1080165 2016-08-13 20:16:00 /home/oracle10/oradata/dbinfo/gias01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
2 Full 6.80M DISK 00:00:02 2016-08-13 20:17:17
BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20160813T201600
Piece Name: /home/oracle10/flash_recovery_area/DBINFO/backupset/2016_08_13/o1_mf_ncsnf_TAG20160813T201600_cty3yffw_.bkp
Control File Included: Ckp SCN: 1080190 Ckp time: 2016-08-13 20:17:15
SPFILE Included: Modification time: 2016-08-13 20:09:59
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
3 Full 560.05M DISK 00:00:18 2016-08-13 20:26:33 =============[第二個時間點]==========
BP Key: 3 Status: AVAILABLE Compressed: NO Tag: TAG20160813T202615
Piece Name: /home/oracle10/orabak/fulldb_20160813_919801575
List of Datafiles in backup set 3
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ------------------- ----
1 Full 1080933 2016-08-13 20:26:15 /home/oracle10/oradata/dbinfo/system01.dbf
2 Full 1080933 2016-08-13 20:26:15 /home/oracle10/oradata/dbinfo/undotbs01.dbf
3 Full 1080933 2016-08-13 20:26:15 /home/oracle10/oradata/dbinfo/sysaux01.dbf
4 Full 1080933 2016-08-13 20:26:15 /home/oracle10/oradata/dbinfo/users01.dbf
5 Full 1080933 2016-08-13 20:26:15 /home/oracle10/oradata/dbinfo/gias01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
4 Full 6.80M DISK 00:00:01 2016-08-13 20:26:41
BP Key: 4 Status: AVAILABLE Compressed: NO Tag: TAG20160813T202615
Piece Name: /home/oracle10/orabak/fulldb_20160813_919801600
Control File Included: Ckp SCN: 1080941 Ckp time: 2016-08-13 20:26:40
SPFILE Included: Modification time: 2016-08-13 20:09:59
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
5 Full 561.88M DISK 00:00:19 2016-08-13 20:34:29 =============[第三個時間點]==========
BP Key: 5 Status: AVAILABLE Compressed: NO Tag: TAG20160813T203410
Piece Name: /home/oracle10/orabak/db_full_bak_20160813_919802050
List of Datafiles in backup set 5
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ------------------- ----
1 Full 1081829 2016-08-13 20:34:10 /home/oracle10/oradata/dbinfo/system01.dbf
2 Full 1081829 2016-08-13 20:34:10 /home/oracle10/oradata/dbinfo/undotbs01.dbf
3 Full 1081829 2016-08-13 20:34:10 /home/oracle10/oradata/dbinfo/sysaux01.dbf
4 Full 1081829 2016-08-13 20:34:10 /home/oracle10/oradata/dbinfo/users01.dbf
5 Full 1081829 2016-08-13 20:34:10 /home/oracle10/oradata/dbinfo/gias01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
6 Full 6.80M DISK 00:00:01 2016-08-13 20:34:36
BP Key: 6 Status: AVAILABLE Compressed: NO Tag: TAG20160813T203410
Piece Name: /home/oracle10/orabak/db_full_bak_20160813_919802075
Control File Included: Ckp SCN: 1081837 Ckp time: 2016-08-13 20:34:35
SPFILE Included: Modification time: 2016-08-13 20:09:59
從上面檢視備份集的輸出可知,目前有三個可用的備份集.分别是:
1. 2016-08-13 20:17:08
2. 2016-08-13 20:26:33
3. 2016-08-13 20:34:29
現在的情況是,已經進行了一次完全恢複,使用的是 第3個時間點的全備.但現在需要恢複第2個時間點的全備.
注: 進行基于時間的備份時需要先導出指定日期格式的變量: export NLS_DATE_FORMAT='yyyy-mm-dd hh24:mi:ss';
RMAN> run {
set until time='2016-08-13 20:26:33';
restore database;
recover database;
alter database open resetlogs;
}
executing command: SET until clause
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of set command at 08/13/2016 23:42:18
RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time
恢複時,出現了RMAN-20207的錯誤,這是進行恢複時,經常會出的錯誤.這是因為,我們先前恢複了第3個時間點
的全備,并進行了resetlogs,那麼Oracle将的incarnation将加1,可以了解為Oracle将resetlogs前的備份集做為上層,
resetlogs後,重建立了一個層,開始重新記錄資訊. 我們現在要恢複上一層的備份集,就必須先回到上一層.
RMAN> list incarnation; #檢視目前有幾個incarnation.
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 DBINFO 3196490228 PARENT 1 2005-10-22 21:44:08
2 2 DBINFO 3196490228 PARENT 525876 2015-06-20 21:23:03
3 3 DBINFO 3196490228 CURRENT 1081970 2016-08-13 23:39:33 #這是目前層.
RMAN> reset database to incarnation 2;
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 DBINFO 3196490228 PARENT 1 2005-10-22 21:44:08
2 2 DBINFO 3196490228 CURRENT 525876 2015-06-20 21:23:03 #此時,它變成了目前層.
3 3 DBINFO 3196490228 ORPHAN 1081970 2016-08-13 23:39:33
4 4 DBINFO 3196490228 ORPHAN 1081972 2016-08-14 00:05:20
RMAN> run {
set until time='2016-08-13 20:26:33'; #使用第二次備份的時間點來進行不完全恢複.
restore database;
recover database;
alter database open resetlogs;
}
executing command: SET until clause
Starting restore at 2016-08-14 00:14:50
using channel ORA_DISK_1
.......
piece handle=/home/oracle10/orabak/fulldb_20160813_919801575 tag=TAG20160813T202615 #可以看到這裡使用第二次的備份集.
channel ORA_DISK_1: restore complete, elapsed time: 00:00:55
Finished restore at 2016-08-14 00:15:45
恢複完成後,再次檢視incarnation：
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 DBINFO 3196490228 PARENT 1 2005-10-22 21:44:08
2 2 DBINFO 3196490228 PARENT 525876 2015-06-20 21:23:03
5 5 DBINFO 3196490228 CURRENT 1080958 2016-08-14 00:15:47 #目前層在這裡.
3 3 DBINFO 3196490228 ORPHAN 1081970 2016-08-13 23:39:33
4 4 DBINFO 3196490228 ORPHAN 1081972 2016-08-14 00:05:20
這時,我們繼續将恢複的資料檔案gias01.dbf 删除.然後,直接執行:
restore database; #發現恢複的是第二次備份的全備集.
recover database;
alter database open resetlogs; #并且,執行它時會報錯,因為,Oracle不認為這是不完全恢複.
alter database open; #是以,直接此指令即可打開資料庫.檢視incarnation沒有發生變化。
那現在要重新恢複第三次備份的備份集,要怎麼做?
1. 重新關庫,删除gias01.dbf
2. 重設incarnation 為4.
RMAN> reset database to incarnation 4;
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 DBINFO 3196490228 PARENT 1 2005-10-22 21:44:08
2 2 DBINFO 3196490228 PARENT 525876 2015-06-20 21:23:03
5 5 DBINFO 3196490228 ORPHAN 1080958 2016-08-14 00:15:47
3 3 DBINFO 3196490228 ORPHAN 1081970 2016-08-13 23:39:33
4 4 DBINFO 3196490228 CURRENT 1081972 2016-08-14 00:05:20 #可以看到現在已經修改成功.
3. 嘗試手動恢複:
restore database; #這次恢複的是第三次備份的全備集.
recover database;
執行recover database時,出現下面錯誤，可忽略:
RMAN-03002: failure of recover command at 06/24/2015 16:02:25
RMAN-06054: media recovery requesting unknown log: thread 1 scn 277200603
4.進入sqlplus嘗試打開資料庫:
alter database open resetlogs; #成功打開.
5.再次檢視incarnation：
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 DBINFO 3196490228 PARENT 1 2005-10-22 21:44:08
2 2 DBINFO 3196490228 PARENT 525876 2015-06-20 21:23:03
5 5 DBINFO 3196490228 ORPHAN 1080958 2016-08-14 00:15:47
3 3 DBINFO 3196490228 ORPHAN 1081970 2016-08-13 23:39:33
6 6 DBINFO 3196490228 CURRENT 1081972 2016-08-14 00:39:49 #現在第6層
4 4 DBINFO 3196490228 PARENT 1081972 2016-08-14 00:05:20
實驗到此,我又嘗試了reset database to incarnation 2; 然後,使用時間恢複第一次備份集,
成功,incarnation+1後為7,然後,我再次回到2,嘗試使用時間恢複第一次備份,竟然失敗了,然後,
我嘗試使用時間恢複第一/二/三都不成功,但可以直接使用restore database來恢複.
我依然沒有完全了解,從實驗上看,沒次resetlogs後,該層上将記錄此次恢複備份集的資訊,
并且上個目前層上關于該備份集的資訊将被删除。
後記:
此次實驗到最後,出現了一個問題,incarnation 被搞混亂了,我把所有的備份集都删除了,然後,
重新做了兩次RMAN全備,每次都看incarnation有什麼變化沒,結果因為先前reset database to incarnation 3;
兩次全備的資訊似乎都沒有記錄到incarnation 3這層,無論我怎麼切換,直接用restore database 或 基于時間的
恢複都提示找不到資料檔案,将incarnation功能關閉也無法恢複.最終的解決方案是,重建控制檔案來解決.
經測試重建控制檔案可以重置incarnation.
這裡有需要注意重建控制檔案時: resetlogs與noresetlogs的差別
norestlogs: 控制檔案的scn是來自目前日志的最大scn。
resetlogs: 控制檔案的scn是來自資料檔案。
重建控制檔案的腳本:
1. 從$ORACLE_BASE/admin/$ORACLE_SID/bdump/alert_$ORACLE_SID.log ,從警告日志中找.
2. 手動寫.
參考樣本:
Create controlfile reuse database "dbinfo" noresetlogs archivelog
MAXINSTANCES 8
MAXLOGHISTORY 1
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
LOGFILE
GROUP 1 '/home/oracle10/oradata/dbinfo/redo01.log' SIZE 51200K,
GROUP 2 '/home/oracle10/oradata/dbinfo/redo02.log' SIZE 51200K,
GROUP 3 '/home/oracle10/oradata/dbinfo/redo03.log' SIZE 51200K
-- STANDBY LOGFILE
Datafile
'/home/oracle10/oradata/dbinfo/system01.dbf',
'/home/oracle10/oradata/dbinfo/undotbs01.dbf',
'/home/oracle10/oradata/dbinfo/sysaux01.dbf',
'/home/oracle10/oradata/dbinfo/users01.dbf',
'/home/oracle10/oradata/dbinfo/gias01.dbf'
CHARACTER SET ZHS16GBK
;
寫好重建控制檔案的腳本後,啟動Oracle到nomount：
SQL> startup nomount
SQL> @/tmp/create-control-file.sql
轉載于:https://www.cnblogs.com/wn1m/p/5830554.html
![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)