您好,登錄后才能下訂單哦!
這篇文章主要介紹“如何使用RMAN還原和恢復數據庫”,在日常操作中,相信很多人在如何使用RMAN還原和恢復數據庫問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”如何使用RMAN還原和恢復數據庫”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
一、數據恢復顧問DRA的使用
數據恢復顧問(Data Recovery Advisor,DRA)是Oracle 11g中新增的一個診斷和修復數據庫問題的工具。共有兩種界面:RMAN可執行程序界面和企業管理器Enterprise Manager界面。DRA能夠生成腳本來修復數據文件和(在某些環境下)控制文件受到的損壞。它不提供有關服務器參數文件和聯機日志文件問題的建議。DRA的決策依賴于自動診斷知識庫(Automatic Diagnostic Repository,ADR)和健康檢查Health Monitor。
Health Monitor是一組檢查,檢查結果不存儲在數據庫,而存儲在文件系統中。其原因在于,一些錯誤的性質決定了數據庫不再可用,因此需要一個外部知識庫來存儲Health Monitor的結果。這個知識庫就是自動診斷知識庫(ADR),位于diagnostic_dest實例參數指定的目錄中。
show parameter diagnostic_dest;
NAME TYPE VALUE
------------------------------------ ----------- ------------
diagnostic_dest string C:\ORACLE
可以看到其默認是在Oracle安裝的基目錄中,有個diag子目錄就是存放ADR的位置。
健康檢查Health Monitor在數據庫不同的模式階段將運行不同的檢查內容:
在nomount模式下,只能檢查控制文件的完整性,因為數據庫還沒有裝載;
在mount模式下,將檢查控制文件、聯機重做日志文件和數據文件頭部的完整性,也將檢查歸檔日志文件的完整性;
在open模式下,將可掃描每個數據文件塊是否受損,并檢查數據字典和撤銷段的完整性。
DRA的功能有一定的局限性。例如,只有當實例處于nomount或更高模式時,DRA才能奏效。如果初始化文件存在問題,它就起不到幫助作用。但一旦能進入nomount模式,它就可以診斷控制文件的問題,并使用現有的有效副本(如果不存在,就嘗試從備份集中提取一個副本)生成用來還原的腳本。再一旦數據庫進入mount模式,DRA就可以診斷有關數據文件缺失或受損的問題,以及聯機日志文件組丟失的問題,并生成修復腳本。DRA只能用于單實例數據庫的環境,不能用于RAC集群環境,也不能用于Data Guard備用數據庫。如果RAC數據庫故障,可以在單實例模式中加載,使用DRA修復損壞的內容,然后關閉它并在RAC模式中重新打開。
數據恢復顧問DRA的使用非常簡單,RMAN環境下包括以下三個步驟:
1)使用list failure命令列出故障;
2)使用advise failure命令給出故障處理建議;
3)使用repair failure命令修復故障。
數據恢復顧問DRA使用健康檢查Health Monitor收集的信息查找問題并構建RMAN腳本進行修復。如果不首先要求DRA列出故障,則DRA不會生成建議。對于最后一次列出之后再發生的故障,DRA不提供任何建議。
以下通過一個例子,說明數據恢復顧問(DRA)的使用。
1)在操作系統提示符下進入RMAN程序
C:\Users\Administrator>rman target /
恢復管理器: Release 11.2.0.4.0 - Production on 星期四 5月 3 10:33:33 2018
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
已連接到目標數據庫: MES (DBID=2056489697)
2)確認已存在SYSAUX表空間的完整備份
RMAN> list backup of tablespace sysaux;
使用目標數據庫控制文件替代恢復目錄
備份集列表
===================
BS 關鍵字 類型 LV 大小 設備類型 經過時間 完成時間
------- ---- -- ---------- ----------- ------------ -------------------
241 Incr 0 312.86M DISK 00:01:00 2018-05-03 10:31:49
BP 關鍵字: 241 狀態: AVAILABLE 已壓縮: YES 標記: TAG20180503T103048
段名:E:\RMAN_BAK\MES\MES_85T1V56P_1_20180503
備份集 241 中的數據文件列表
文件 LV 類型 Ckp SCN Ckp 時間 名稱
---- -- ---- ---------- ------------------- ----
2 0 Incr 1640735 2018-05-03 10:30:49 D:\ORADATA\MES\SYSAUX01.DBF
如果沒有備份就創建一個
RMAN> backup as backupset tablespace sysaux;
3)關閉實例并退出
RMAN> shutdown immediate;
RMAN> exit;
4)利用操作系統程序刪除sysaux表空間的數據文件
5)使用SQL*Plus連接到數據庫,并嘗試啟動
C:\Users\Administrator>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on 星期四 5月 3 10:42:42 2018
Copyright (c) 1982, 2013, Oracle. All rights reserved.
已連接到空閑例程。
10:42:42 SYS @ mes AS SYSDBA>startup
ORACLE 例程已經啟動。
Total System Global Area 1286066176 bytes
Fixed Size 2280896 bytes
Variable Size 771752512 bytes
Database Buffers 503316480 bytes
Redo Buffers 8716288 bytes
數據庫裝載完畢。
ORA-01157: 無法標識/鎖定數據文件 2 - 請參閱 DBWR 跟蹤文件
ORA-01110: 數據文件 2: 'D:\ORADATA\MES\SYSAUX01.DBF'
啟動時提示sysaux01.dbf文件缺失,并停留在mount加載模式。
6)再次啟動RMAN并診斷問題
C:\Users\Administrator>rman target /
恢復管理器: Release 11.2.0.4.0 - Production on 星期四 5月 3 10:44:17 2018
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
已連接到目標數據庫: MES (DBID=2056489697, 未打開)
RMAN> list failure;
使用目標數據庫控制文件替代恢復目錄
數據庫故障列表
=========================
失敗 ID 優先級狀態 檢測時間 概要
------- -------- --------- ------------------- -------
4932 HIGH OPEN 2018-05-02 23:01:58 缺失一個或多個非系統數據文件
4908 HIGH OPEN 2018-05-02 23:01:58 一個或多個非系統數據文件需要介質恢復
返回一條消息,提示一個非系統數據文件的缺失。
7)生成有關故障的建議
RMAN> advise failure;
數據庫故障列表
=========================
失敗 ID 優先級狀態 檢測時間 概要
------- -------- --------- ------------------- -------
4932 HIGH OPEN 2018-05-02 23:01:58 缺失一個或多個非系統數據文件
4908 HIGH OPEN 2018-05-02 23:01:58 一個或多個非系統數據文件需要介質恢復
正在分析自動修復選項; 這可能需要一些時間
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=221 設備類型=DISK
分析自動修復選項完成
必需的手動操作
========================
沒有可用的手動操作
可選手動操作
=======================
1. 如果無意中重命名或移動了文件 D:\ORADATA\MES\SYSAUX01.DBF, 請還原該文件
2. 如果還原了錯誤版本的數據文件 D:\ORADATA\MES\SYSAUX01.DBF, 請使用正確版本將其替換
自動修復選項
========================
選項修復說明
------ ------------------
1 還原和恢復數據文件 2
策略: 修復操作包括無數據丟失的完全介質恢復
修復腳本: C:\ORACLE\diag\rdbms\mes\mes\hm\reco_339425269.hm
8)打開修復腳本,研究其內容,可以看到包括以下修復語句
restore datafile 2;
recover datafile 2;
sql 'alter database datafile 2 online';
10)要運行腳本,可使用以下命令
RMAN> repair failure;
策略: 修復操作包括無數據丟失的完全介質恢復
修復腳本: C:\ORACLE\diag\rdbms\mes\mes\hm\reco_339425269.hm
修復腳本的內容:
# restore and recover datafile
restore datafile 2;
recover datafile 2;
sql 'alter database datafile 2 online';
是否確實要執行以上修復 (輸入 YES 或 NO)? y
執行修復腳本
啟動 restore 于 2018-05-03 10:50:36
使用通道 ORA_DISK_1
通道 ORA_DISK_1: 正在開始還原數據文件備份集
通道 ORA_DISK_1: 正在指定從備份集還原的數據文件
通道 ORA_DISK_1: 將數據文件 00002 還原到 D:\ORADATA\MES\SYSAUX01.DBF
通道 ORA_DISK_1: 正在讀取備份片段 E:\RMAN_BAK\MES\MES_85T1V56P_1_20180503
通道 ORA_DISK_1: 段句柄 = E:\RMAN_BAK\MES\MES_85T1V56P_1_20180503 標記 = TAG20180503T103048
通道 ORA_DISK_1: 已還原備份片段 1
通道 ORA_DISK_1: 還原完成, 用時: 00:00:35
完成 restore 于 2018-05-03 10:51:12
啟動 recover 于 2018-05-03 10:51:12
使用通道 ORA_DISK_1
正在開始介質的恢復
介質恢復完成, 用時: 00:00:01
完成 recover 于 2018-05-03 10:51:13
sql 語句: alter database datafile 2 online
修復故障已完成
是否要打開數據庫 (輸入 YES 或 NO)? y
數據庫已打開
以上看到,系統自動定位最新的備份文件,經過數據還原和介質恢復,完成后提示打開數據庫。
二、數據文件丟失后的完整恢復
在Oracle數據庫中,有些文件是關鍵的(critical),關鍵文件受損意味著數據庫實例將終止,在損壞被修復之前不能重新打開。有些文件是非關鍵的(noncritical),如果這些文件受損,數據庫仍能保持打開或可以被打開。
構成SYSTEM表空間和當前活動的撤銷表空間(由undo_tablespace參數指定)的數據文件被認為是關鍵的,控制文件的任何副本也都是關鍵的,這類文件受損將導致實例終止運行。構成用戶數據表空間的文件則是非關鍵的,這些文件受損通常不會導致實例崩潰。使受損的文件脫機,使其內容不可訪問,可使數據庫的其余部分仍可保持打開。
通常,任意數目的數據文件的損壞都可用完整恢復來修復,不會有數據丟失。還原受損的文件,再應用重做使它們保持最新。當然,前提條件是自數據文件上一次備份后生成的所有歸檔日志文件可用。不完整恢復意味著還原數據庫并只應用重做至某個特定點,在該點之后所做的所有工作將丟失。為什么要不完整恢復?通常只有一個原因:用戶錯誤。如果因為用戶操作錯誤,則需要將整個數據庫返回到錯誤發生之前。不完整恢復的第二種原因是嘗試了完整恢復,但失敗了。這會在歸檔日志文件缺失或當前聯機日志文件組的所有副本丟失的情況下發生。
1、非歸檔日志模式下的數據文件恢復
在非歸檔日志模式下,沒有什么支持恢復的技術,因為恢復所需的歸檔日志并不存在,因此只能進行還原,但這樣也丟失了自備份創建之后所做的所有工作。
還原過程只能在加載模式下運行
shutdown abort;
startup mount;
restore database;
recover database;
alter database open resetlogs;
2、歸檔日志模式下丟失非關鍵文件時的恢復
歸檔模式下,如果損壞的是非關鍵數據文件,則還原和恢復過程包括以下四步:
1)使受損的數據文件脫機(可能系統已自動完整),如果還沒有脫機,則可執行以下命令,如指定10#文件脫機
RMAN> sql'alter database datafile 10 offline';
受損文件脫機后,數據庫應該已經可以打開。
2)還原數據文件
RMAN> restore datafile 10;
3)恢復數據文件
RMAN> recover datafile 10;
4)使數據文件聯機
RMAN> sql'alter database datafile 10 online';
以上命令中有的屬于SQL命令而非RMAN命令,因此在RMAN環境下執行時,需要添加sql前綴。
如果備份時使用的是增量備份策略,還原和恢復操作將首先利用級別0備份,然后應用級別1備份,最后再應用重做數據完成恢復。這一方法(使對重做的使用最小化)背后的邏輯是應用增量備份總是比應用重做要快。增量備份存在與否并不會導致使用recover命令時的語法差別,RMAN通過詢問其存儲庫,將計算出執行操作的最好方法。
3、丟失關鍵數據文件時的恢復
如果數據庫因為關鍵數據文件損壞而崩潰,那么第一行動就是試著啟動它。這將在加載模式下停止,同時將錯誤消息寫入警報日志。要進行恢復,可以采取和非關鍵文件一樣的過程,只是還原和恢復只能在加載模式下進行,因為數據庫已不能打開。例如要還原3#文件,此時還原和恢復包括以下四步:
1)數據庫啟動到加載模式
RMAN> startup mount;
2)還原數據文件
RMAN> restore datafile 3;
3)恢復數據文件
RMAN> recover datafile 3;
4)打開數據庫
RMAN> alter database open;
三、數據文件丟失后的不完整恢復
執行不完整恢復只有兩個原因:完整恢復不可行或是故意要丟失數據。如果缺失歸檔日志或當前聯機重做日志文件組的所有副本缺失,那么必須執行不完整恢復。對于用戶錯誤,可以還原整個數據庫并將它恢復至錯誤發生前的點,但也同時失去了自那之后所做的所有正確的工作。
不完整恢復的特例是控制文件的恢復。在理想情況下,所有恢復操作將使用當前控制文件來引導,但有時是不可能的,必須還原控制文件的備份。可能的原因有兩點:1)當前控制文件的所有副本已丟失,不能運行create controlfile命令重新創建它們。
2)當前控制文件已不能準確描述想要還原的數據庫版本,如表空間和數據文件的結構在最近一次備份后已發生了更改。這個時候還原數據文件的同時必須首先還原控制文件。
不完整恢復分為四個步驟:
1)加載數據庫
2)還原所有數據文件
3)恢復數據庫至某個點(以下會說明包括三種指定方式)
4)用重置日志打開數據庫
與完整恢復相比,不完整恢復有以下幾點不同:
1)開始時,完整恢復可在數據庫打開時進行,除非受損文件是關鍵的,而不完整恢復只能在加載模式下進行。
2)還原時,對于完整恢復,只需還原受損的數據文件,而不完整恢復需要還原所有數據文件,必須還原到早于想恢復的點。
3)恢復時,需要將歸檔日志和聯機日志的重做數據應用到所需的點,有幾個選項可用于指定想恢復到的點。
4)打開時, 需要用RESETLOGS打開數據庫,這將重新初始化聯機重做日志文件,創建數據庫的一個新化身。數據庫的化身是指帶有新的重做線程(日志序列號從1開始)的數據庫版本。備份和歸檔日志都是特定于一個化身的,由不同化身生成的備份和歸檔日志邏輯上是彼此分離的,不能互用。正因如此,當使用RESETLOGS重置日志文件后,應當立即重新執行一次完整的數據庫備份。
加載數據庫并還原所有數據文件(必要時還包括還原控制文件)后,對于不完整恢復操作有三種選項:
1)UNTIL TIME
該選項將應用重做前滾數據文件至一個特定時間,精度為秒。該選項通常用于糾正用戶錯誤,如果用戶犯了不可逆的錯誤,但知道犯錯誤的時間,那么就可以基于時間恢復至錯誤發生之前。
2、UNTIL SCN
如果已知錯誤發生時的確切的系統改變號SCN,那么可使用該選項準確的將恢復停在錯誤發生之前,從而盡可能少的丟失數據。這需要使用如Log Miner這樣的高級工具或是使用閃回功能,確定提交事務時的SCN。
3、UNTIL SEQUENCE
如果歸檔日志文件或聯機日志文件組缺失,則使用該選項,它會將恢復工作停止至指定的歸檔日志序列號。
默認情況下,RMAN應按最近的備份來還原,并應用重做。但不完整恢復與此不同,必須從早于恢復點的備份進行還原,再前滾到那個需要恢復到的時間點。要確保還原和恢復使用相同的UNTIL TIME,最佳辦法是在一個run塊中完成還原和恢復這兩個命令。
RMAN> run {
startup mount;
set until time = "to_date('2015-11-01 10:00:00', 'yyyy-mm-dd hh34:mi:ss')";
restore database;
recover database;
alter database open resetlogs;
}
命令set until time指定一個將應用到所有后續命令的時間,最終數據庫將還原和恢復到該時間點的狀態上。當然也可以單獨指定UNTIL值
RMAN> restore database until time 'sysdate -7';
RMAN> recover database until time '27-OCT-08';
這里如果沒有像前面run塊那樣指定時間格式,那么時間識別依賴于初始化參數NLS_DATE_FORMAT,如上命令假設NLS_DATE_FORMAT被設置為dd-MON-rr。
四、控制文件的自動備份和恢復
數據庫嚴重依賴于控制文件,如果控制文件受損,數據庫將崩潰。RMAN的情況更糟,存放備份信息的RMAN存儲庫就存儲在控制文件中。因此,如果控制文件損壞,一方面數據庫將崩潰,而另一方面RMAN又不能恢復它,因為RMAN所需要的信息不可用。這是個遞歸性的問題,解決這一問題的辦法是使用RMAN目錄數據庫或者啟用控制文件的自動備份功能。
要啟用控制文件的自動備份,在RMAN提示符下執行以下命令
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
該命令執行后,每個RMAN操作都會把控制文件和spfile文件自動備份到已知位置的備份集中。指定好自動備份的路徑,未指定時默認保存在閃回恢復區,文件名基于DBID。數據庫的ID是一個10位數字。DBID在啟動RMAN時可以看到,也可以通過查詢視圖v$database的字段DBID獲知。以下設定控制文件自動備份的保存路徑
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'e:\rman_bak\mes\control_bak\%F';
若要還原控制文件,可在數據庫處于非加載模式下執行以下命令
RMAN> restore controlfile from autobackup;
該命令從最近的自動備份中提取控制文件,還原到spfile初始化參數文件指定的位置。之后便可用還原的控制文件加載數據庫,RMAN將可以定位所需的備份來還原數據庫的其余部分。由于非加載模式下控制文件尚未加載,RMAN不知道自動備份控制文件的位置,故會從默認位置還原控制文件(包含spfile),該位置對于Windows來說是%ORACLE_HOME%\database,對于Unix系統來說是$ORACLE_HOME\dbs。因此還原前應當首先把最近一次自動備份的控制文件(包含spfile)復制到該路徑下。
如果spfile文件也丟失了,則可用啞初始化參數文件啟動實例:只有一個參數db_name的pfile文件(如內容只有一行db_name=mes)。然后用RMAN連接,發出以下命令替換為自己的DBID
RMAN> set dbid 1979336967;
RMAN> restore spfile from autobackup;
該命令將spfile文件還原到系統默認位置(Windows是%ORACLE_HOME%\database,Unix是$ORACLE_HOME\dbs)。之后再以非加載模式重啟實例,便可進行控制文件的還原以及后續數據庫的還原。
數據庫的ID號一般可以從備份的控制文件名上獲得,如控制文件備份C-1979336967-20151116-00,1979336967即是DBID。在RMAN連接到目標數據庫時也會提示DBID。視圖v$database中也包含了DBID字段的信息。
RMAN也只有這兩個關于spfile文件和控制文件的還原命令能在非加載模式下執行,所有其他命令只能在加載模式或打開模式下執行。
下列腳本用啞初始化參數文件dummy.ora開始實例的啟動,逐步完成數據庫的完整還原和恢復(假定所有數據文件、控制文件、spfile文件都已丟失)
run {
startup nomount pfile = C:\oracle\product\11.2.0\dbhome_1\database\dummy.ora;
set dbid = 1979336967;
restore spfile from autobackup;
shutdown abort;
startup nomount;
restore controlfile from autobackup;
alter database mount;
restore database;
recover database;
alter database open resetlogs;
}
如果之前沒有啟用控制文件的自動備份,但有包含spfile和controlfile的備份集,則命令可以指定包含該內容的備份
restore spfile from 'e:\rman_bak\mes\control_bak\C-2056489697-20180502-06';
五、不完整恢復實驗
1、實驗前備份的構建
更改控制文件的備份配置,設為自動備份,并指定備份的目標路徑
RMAN> configure controlfile autobackup on;
RMAN> configure controlfile autobackup format for device type disk to 'e:\rman_bak\mes\control_bak\%F';
更改數據文件備份集的目標位置和命名規則
RMAN> configure channel device type disk format 'e:\rman_bak\mes\%d_%u_%c_%T';
執行一次完整的數據庫增量級別1壓縮備份,并將之前(已不再需要)的歸檔日志文件刪除
RMAN> backup incremental level 1 as compressed backupset database plus archivelog delete all input;
2、清楚需要恢復的時間點
當故障發生后,我們需要將系統恢復到故障發生之前的某一時刻,這個時間愈靠近故障發生時刻,就愈能保證恢復后不丟失用戶數據,因此在實驗前我們先明確一下當前時間。
select sysdate from dual;
SYSDATE
-------------------
2018-05-03 12:09:34
3、故障模擬
假定現在由于用戶誤操作,不小心刪除了CMES表空間,導致重要數據丟失
drop tablespace cmes including contents and datafiles;
4、還原控制文件
由于表空間的刪除,數據庫的結構發生了變化,該變化已被記入當前的控制文件。因此如果要恢復到故障之前的狀態,必須首先恢復未刪除表空間之前的控制文件,用原有的控制文件加載數據庫,之后再還原表空間和數據文件。
登錄RMAN,構建一個run塊,設置還原時間點,然后還原控制文件到一個指定的路徑
RMAN> run {
2> shutdown abort;
3> startup mount;
4> set until time = '2018-05-03 12:09:34';
5> restore controlfile to 'D:\control.ctl';
6> }
Oracle 實例已關閉
已連接到目標數據庫 (未啟動)
Oracle 實例已啟動
數據庫已裝載
系統全局區域總計 1286066176 字節
Fixed Size 2280896 字節
Variable Size 771752512 字節
Database Buffers 503316480 字節
Redo Buffers 8716288 字節
正在執行命令: SET until clause
啟動 restore 于 2018-05-03 12:18:35
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=189 設備類型=DISK
通道 ORA_DISK_1: 正在開始還原數據文件備份集
通道 ORA_DISK_1: 正在還原控制文件
輸出文件名=D:\CONTROL.CTL
通道 ORA_DISK_1: 正在讀取備份片段 E:\RMAN_BAK\MES\CONTROL_BAK\C-2056489697-20180503-02
通道 ORA_DISK_1: 段句柄 = E:\RMAN_BAK\MES\CONTROL_BAK\C-2056489697-20180503-02 標記 = TAG20180503T105757
通道 ORA_DISK_1: 已還原備份片段 1
通道 ORA_DISK_1: 還原完成, 用時: 00:00:01
完成 restore 于 2018-05-03 12:18:37
5、用還原出來的控制文件重新加載數據庫
alter system set control_files = 'D:\control.ctl' scope = spfile;
shutdown abort
startup mount
6、按設定的時間點進行數據庫的還原和恢復
在RMAN會話中構建以下run塊,設置還原和恢復的時間點,然后進行數據庫的還原和恢復,并打開數據庫
RMAN> run {
allocate channel c1 type disk;
allocate channel c2 type disk;
set until time = '2018-05-03 12:09:34';
restore database;
recover database;
alter database open resetlogs;
}
使用目標數據庫控制文件替代恢復目錄
分配的通道: c1
通道 c1: SID=221 設備類型=DISK
分配的通道: c2
通道 c2: SID=3 設備類型=DISK
正在執行命令: SET until clause
啟動 restore 于 2018-05-03 12:25:41
啟動 implicit crosscheck backup 于 2018-05-03 12:25:41
已交叉檢驗的 5 對象
完成 implicit crosscheck backup 于 2018-05-03 12:25:41
啟動 implicit crosscheck copy 于 2018-05-03 12:25:41
完成 implicit crosscheck copy 于 2018-05-03 12:25:42
搜索恢復區中的所有文件
正在編制文件目錄...
沒有為文件編制目錄
通道 c1: 正在開始還原數據文件備份集
通道 c1: 正在指定從備份集還原的數據文件
通道 c1: 將數據文件 00001 還原到 D:\ORADATA\MES\SYSTEM01.DBF
通道 c1: 將數據文件 00002 還原到 D:\ORADATA\MES\SYSAUX01.DBF
通道 c1: 將數據文件 00003 還原到 D:\ORADATA\MES\UNDOTBS01.DBF
通道 c1: 將數據文件 00004 還原到 D:\ORADATA\MES\USERS01.DBF
通道 c1: 將數據文件 00005 還原到 D:\ORADATA\MES\EXAMPLE01.DBF
通道 c1: 正在讀取備份片段 E:\RMAN_BAK\MES\MES_85T1V56P_1_20180503
通道 c2: 正在開始還原數據文件備份集
通道 c2: 正在指定從備份集還原的數據文件
通道 c2: 將數據文件 00006 還原到 D:\ORADATA\MES\CMES01.DBF
通道 c2: 將數據文件 00007 還原到 D:\ORADATA\MES\RMES01.DBF
通道 c2: 將數據文件 00008 還原到 D:\ORADATA\MES\HMES01.DBF
通道 c2: 將數據文件 00009 還原到 D:\ORADATA\MES\INDX01.DBF
通道 c2: 將數據文件 00010 還原到 D:\ORADATA\MES\FDA01.DBF
通道 c2: 正在讀取備份片段 E:\RMAN_BAK\MES\MES_86T1V58Q_1_20180503
通道 c2: 段句柄 = E:\RMAN_BAK\MES\MES_86T1V58Q_1_20180503 標記 = TAG20180503T103048
通道 c2: 已還原備份片段 1
通道 c2: 還原完成, 用時: 00:00:15
通道 c1: 段句柄 = E:\RMAN_BAK\MES\MES_85T1V56P_1_20180503 標記 = TAG20180503T103048
通道 c1: 已還原備份片段 1
通道 c1: 還原完成, 用時: 00:00:46
完成 restore 于 2018-05-03 12:26:30
啟動 recover 于 2018-05-03 12:26:30
正在開始介質的恢復
線程 1 序列 7 的歸檔日志已作為文件 D:\ORADATA\MES\REDO01.LOG 存在于磁盤上
線程 1 序列 8 的歸檔日志已作為文件 D:\ORADATA\MES\REDO02.LOG 存在于磁盤上
歸檔日志文件名=D:\ORADATA\MES\REDO01.LOG 線程=1 序列=7
歸檔日志文件名=D:\ORADATA\MES\REDO02.LOG 線程=1 序列=8
介質恢復完成, 用時: 00:00:03
完成 recover 于 2018-05-03 12:26:36
數據庫已打開
釋放的通道: c1
釋放的通道: c2
7、恢復控制文件的復用狀態
數據庫打開后,查看當前啟用的控制文件
show parameter control_files;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_files string D:\CONTROL.CTL
修改控制文件參數,回到原先的多路復用狀態
alter system set control_files='d:\oradata\mes\control01.ctl','e:\fast_recovery_area\mes\control02.ctl' scope=spfile;
關閉數據庫
shutdown immediate
將控制文件d:\control.ctl分別復制到d:\oradata\mes\control01.ctl和e:\fast_recovery_area\mes\control02.ctl中
重啟數據庫
startup
數據庫打開后再次確認啟用的控制文件
show parameter control_files;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_files string D:\ORADATA\MES\CONTROL01.CTL,
E:\FAST_RECOVERY_AREA\MES\CONT
ROL02.CTL
由于恢復使用RESETLOGS重置了聯機日志文件(日志序列號重新從1開始),因此創建的是數據庫的一個新化身,之前的備份和歸檔日志已經和當前數據庫分離,因此可以在RMAN下將之前的備份和歸檔日志刪除,并盡快重新執行一次完整的數據庫備份。
六、使用映像副本恢復
如果備份策略包括映像副本,那么另一種還原選擇實際就是根本不用還原。由于映像副本與原數據文件是完全相同的,因此如果磁盤上有,則可以立即使用它。需要做的就是告訴數據庫映像副本的位置,然后恢復副本。與從備份集中提取數據文件所引起的延遲相比,映像副本的恢復可節省大量時間。
可使用下列RMAN命令創建整個數據庫的映像副本
RMAN> backup as copy database;
如果沒有更改默認的備份位置參數,那么該命令將所有數據文件復制到閃回恢復區作為映像副本。要使用映像副本,首先使原數據文件脫機(可能已經自動發生),然后更新控制文件中數據文件的指向,再恢復副本文件。例如有如下創建的副本
RMAN> backup as copy datafile 5 format 'e:\rman_bak\mes\cmes01.dbf';
通過以下腳本可以使用它
RMAN> run {
sql'alter database datafile 5 offline';
set newname for datafile 5 to 'e:\rman_bak\mes\cmes01.dbf';
switch datafile 5;
recover datafile 5;
sql'alter database datafile 5 online';
}
如果已對整個數據庫創建了映像副本,則可用一條命令還原整個數據庫
RMAN> switch database to copy;
映像副本的另一種使用方法是通過增量備份來更新副本,以維護副本的較新狀態。這要求將數據庫的完整副本作為起點,之后創建增量備份,將其應用至副本中。以下開辟兩個通道并行備份,將副本更新到閃回恢復區中,文件名格式將是OMF的
RMAN> run {
allocate channel c1 type disk;
allocate channel c2 type disk;
backup incremental level 1 for recover of copy with tag 'inc_copy' database;
recover copy of database with tag 'inc_copy';
release channel c1;
release channel c2;
}
該命令首次運行時,RMAN嘗試增量級別1備份,但由于之前沒有級別0備份,因此執行級別0備份。該語句生成一個映像副本。recover命令在首次執行時將失敗,因為沒有可用的副本和增量備份。腳本第二次運行時,第一個命令將執行增量級別1備份,提取自上一次備份后所有的變更塊,第二個命令則把這個增量變更應用到副本。以后每次運行都延續該行為。這種基于增量更新副本的策略可以使恢復過程非常快。
到此,關于“如何使用RMAN還原和恢復數據庫”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。