下麵總結、整理一下RMAN異機恢復這方面的知識點,這篇筆記在個人筆記裡面躺了幾年了,直到最近偶然被翻看到,遂整理、總結一下。如下所示,個人將整個RMAN異機恢復分為準備工作和操作步驟兩大部分。當然,準備工作裡面,有些步驟不是必須的,可以跳過或忽略的。這個取決於你的實際環境和你對RMAN異機恢復的熟悉... ...
下麵總結、整理一下RMAN異機恢復這方面的知識點,這篇筆記在個人筆記裡面躺了幾年了,直到最近偶然被翻看到,遂整理、總結一下。如下所示,個人將整個RMAN異機恢復分為準備工作和操作步驟兩大部分。當然,準備工作裡面,有些步驟不是必須的,可以跳過或忽略的。這個取決於你的實際環境和你對RMAN異機恢復的熟悉程度。
準備工作
1:瞭解一下目標伺服器與源伺服器的操作系統版本信息
需要對比一下目標伺服器與源伺服器的操作系統版本是否一致,具體來說,操作系統版本信息、內核信息(例如Oracle Linux是否使用Unbreakable Enterprise Kernel內核等),以及操作系統是32bit還是64bit等。如果RMAN異機恢復只是準備Dev、Test、UAT環境,那麼這個完全可以忽略,如果是正式環境的遷移,那麼最好關註一下,避免一些問題。例如,有些版本的操作系統對不是官方認證的,如果在遷移前不關註這些,那麼遷移後,有可能出現一些意想不到的問題。
# uname -a
# uname -m
# more /etc/redhat-release
註意:這些工作是前期準備工作,不能到RMAN還原恢復的時候才做。
2:檢查目標伺服器與源伺服器的資料庫版本信息
如果源資料庫和目標資料庫版本一致,那麼完全可以跳過這一步。但是,有時候可能是從32位還原升級到64位;有些是從ORACLE 10g 遷移升級到ORACLE 11g,那麼在後面的RMAN還原後,還需做一些額外的Upgrade工作。個人剛做DBA的第一年,在一次遷移過程,事先安裝過程中不小心選錯了版本(標準版弄成了企業版,安裝過程中由於檢查某個選項,點擊後退過程中系統預設選擇了企業版,當時沒有發現),後續沒有仔細檢查,遷移完成後,驗證時才發現版本是企業版。結果將整個遷移進度全部打亂了!
32bit
64bit
3:檢查實例安裝路徑以及數據文件等路徑
這裡指資料庫實例的安裝路徑,以及數據文件、控制文件、參數文件是否一致,如果全部一致的話,那麼可以避免很多問題,但是很多時候,
我們需要重新規劃存儲路徑或者其它一些原因,這些數據文件、參數文件等,很有可能跟源伺服器不一致,那麼事先瞭解這些,在遷移過程中
就必須註意到這些情況。作出相應的處理。否則RMAN還原過程中就會遇到一些問題。
4:將備份文件拷貝的相關目錄
可以將備份拷貝到恢複目錄解壓或指定目錄解壓。如果源伺服器與目標伺服器的RMAN備份路徑一致,那麼可以省去很多不必要的麻煩。
5: 創建相關的目錄
例如,目標伺服器安裝ORACLE實例時,選擇了“只安裝實例”選項,那麼在RMAN還原之前,我們必須創建下麵一些目錄(這些不是必須的,有些環境甚至完全不必要。具體根據實際情況判斷):
1: 創建$ORACLE_BASE/admin/$ORACLE_SID/下的六個目錄;
2: $ORACLE_BASE/oradata下創建$ORACLE_SID目錄;
3: RMAN備份路徑目錄(這個地方最好與源資料庫一致,創建好後,把源資料庫備份的數據文件複製到這個目錄里);--非必須。
4: 歸檔日誌目錄(同樣,創建好後,把需要的歸檔日誌文件複製到此目錄) --非必須。
[root@getlnx14dev ~]#mkdir -p admin/SCM2/{adump,bdump,cdump,dpdump,pfile,udump}
[root@getlnx14dev ~]#mkdir -p oradata/$ORACLE_SID
[root@getlnx14dev ~]# chown -R oracle:oinstall /data
[root@getlnx14dev ~]# su - oracle
Last login: Fri May 26 13:38:38 CST 2017 on pts/2
[oracle@getlnx14dev ~]$ cd /data/
[oracle@getlnx14dev data]$ mkdir scm2
[oracle@getlnx14dev data]$
操作步驟
下麵測試,是將資料庫通過RMAN備份恢復到一臺測試伺服器,出於測試目的,故意將實例的安裝路徑,以及恢復路徑全部故意弄成不一致。具體測試環境如下:
源伺服器:
操作系統: Red Hat Enterprise Linux Server release 5.1
資料庫版本: Oracle Database 10g Release 10.2.0.4.0 32bit 標準版
目標伺服器:
操作系統: Red Hat Enterprise Linux Server release 7.2 (Maipo) #註意,這個版本不是官方認證版本,僅做測試而已。
資料庫版本: Oracle Database 10g Release 10.2.0.4.0 64bit 標準版
1:查詢DBID信息
DBID是DataBase IDentifier的縮寫,意思就是資料庫的唯一標識符。這個DBID在數據文件頭和控制文件都是存在的,可以用於標示數據文件的歸屬。
對於不同資料庫來說,DBID應當不同,而db_name則可能是相同的。一般在nocatalog模式並且控制文件丟失時才需要這個。
SQL> select name,dbid from v$database;
NAME DBID
--------- ----------
SCM2 3990839260
SQL>
如果源伺服器已經宕機,那麼如何查詢DBID相關信息呢? 關於這個,其實也有很多方法獲取,例如,如果你曾經做過AWR報告,可以從AWR中找到對應的DBID,也可以從恢復的控制文件獲取等。
2:啟動資料庫實例到nomount狀態
使用RMAN還原恢復時,DB必須啟動到nomout狀態。
[oracle@getlnx14dev SCM2]$ rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Sun May 28 21:14:36 2017
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database (not started)
RMAN> startup nomount pfile='/home/oracle/oracle/product/10.2.0/db_1/dbs/init.ora';
Oracle instance started
Total System Global Area 159383552 bytes
Fixed Size 2082400 bytes
Variable Size 150997408 bytes
Database Buffers 4194304 bytes
Redo Buffers 2109440 bytes
3:還原參數文件spfile
RMAN>set DBID=3990839260;
RMAN>restore spfile to pfile '/home/oracle/oracle/product/10.2.0/db_1/dbs/spfileSCM2.ora' from '/app/backup/backup/backupsets/ora_cfc-3990839260-20170518-00';
參數文件恢復後,需要修改相關參數,這裡由於測試緣故,我們故意在目標伺服器安裝ORACLE實例時,隨意選擇了一個路徑,故意與源伺服器ORACLE實例的安裝路徑不一致,當然,還有其它一些情況,也有可能導致你必須修改一些參數。
db_name=SCM2
db_block_size=8192
db_file_multiblock_read_count=16
sga_target=1200M
pga_aggregate_target=760M
audit_file_dest=/u01/app/oracle/admin/SCM2/adump
background_dump_dest=/u01/app/oracle/admin/SCM2/bdump
user_dump_dest=/u01/app/oracle/admin/SCM2/udump
core_dump_dest=/u01/app/oracle/admin/SCM2/cdump
control_files=('/u01/app/oracle/oradata/SCM2/control01.ctl','/u01/app/oracle/oradata/SCM2/control02.ctl','/u01/app/oracle/oradata/SCM2/control03.ctl')
compatible=10.2.0.1.0
remote_login_passwordfile=exclusive
open_cursors=300
sessions=450
processes=300
undo_management=auto
undo_tablespace=UNDOTBS1
修改後的pfile參數文件。
db_name=SCM2
db_block_size=8192
db_file_multiblock_read_count=16
sga_target=1200M
pga_aggregate_target=760M
audit_file_dest=/home/oracle/oracle/admin/SCM2/adump
background_dump_dest=/home/oracle/oracle/admin/SCM2/bdump
user_dump_dest=/home/oracle/oracle/admin/SCM2/udump
core_dump_dest=/home/oracle/oracle/admin/SCM2/cdump
control_files=('/home/oracle/oracle/oradata/SCM2/control01.ctl','/home/oracle/oracle/oradata/SCM2/control02.ctl','/home/oracle/oracle/orada
ta/SCM2/control03.ctl')
compatible=10.2.0.1.0
remote_login_passwordfile=exclusive
open_cursors=300
sessions=450
processes=300
undo_management=auto
undo_tablespace=UNDOTBS1
如果前面準備步驟,沒有創建對應的udmp等目錄,就會遇到下麵錯誤
RMAN> startup nomount pfile='/home/oracle/oracle/product/10.2.0/db_1/dbs/initSCM2.ora';
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of startup command at 05/26/2017 15:27:45
RMAN-04014: startup failed: ORA-00444: background process "PMON" failed while starting
ORA-07446: sdnfy: bad value '' for parameter .
Problem
The path to bdump,adump or udump does not exist. Oracle itself does not create any path if a path does not exist. So, you have to change the value of user_dump_dest in the initialize parameter.
Solution
If you use pfile to start your database then edit the pfile with any editor (for example vi on unix) and either change the location of user_dump_dest or remove the parameter user_dump_dest from pfile. And then perform. startup
4: 還原控制文件(control file)。
如果你實在不知道控制文件在那個備份集的那個文件,那麼可以在源伺服器使用list命令查看。如下所示。 當然如果經驗豐富或者你對備份與還原瞭如指掌的話, 完全不用這一步驟。
RMAN> list backup of controlfile;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
4 Full 7.58M DISK 00:00:00 18-MAY-17
BP Key: 4 Status: AVAILABLE Compressed: NO Tag: TAG20170518T224247
Piece Name: /u03/backup/backupsets/ora_cfc-3990839260-20170518-00
Control File Included: Ckp SCN: 22876629756 Ckp time: 18-MAY-17
後續具體操作操作如下所示
RMAN> shutdown immediate;
using target database control file instead of recovery catalog
Oracle instance shut down
RMAN> exit
Recovery Manager complete.
[oracle@getlnx14dev ~]$ export ORACLE_SID=SCM2;
[oracle@getlnx14dev ~]$ rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Mon May 29 08:41:17 2017
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: SCM2 (DBID=3990839260)
RMAN>
RMAN> startup nomount pfile='/home/oracle/oracle/product/10.2.0/db_1/dbs/initSCM2.ora';
connected to target database (not started)
Oracle instance started
Total System Global Area 1258291200 bytes
Fixed Size 2083624 bytes
Variable Size 318768344 bytes