rman全庫恢複到不同主機，不同執行個體名，不同目錄下

標籤：dom   for   ini   設定   備份   視圖   執行   方式   height   

一、配置目標主機的ip、hostname及與源端主機的連通性

1、配置目標主機IP

使用圖形介面配置IP：

administration----network---修改IP(指定靜態IP)

deactivate網卡---activate網卡（重啟網卡配置才會生效）
或者使用root使用者執行：service network restart 重啟網卡

2、配置主機名稱

1. root使用者執行：hostname hostNameValue
2. vi  /etc/sysconfig/network

修改：HOSTNAME=edsir4p1.us.oracle.com

1. 修改/etc/hosts檔案中IP到主機名稱的映射

127.0.0.1       localhost.localdomain   localhost

192.168.33.138  edsir4p1.us.oracle.com  edsir4p1

192.168.33.137  edsir1p8.us.oracle.com  edsir1p8

3、測試到源端主機的連通性

8. ping edsir1p8.us.oracle.com

或者

ping 192.168.33.137

【漫兮網（http://www.manxinet.com）】

二、規劃目標機上備份組的儲存路徑

因為控制檔案中記錄的備份組的儲存路徑是記錄的備份組在源端（edsir1p8）主機上的  路徑，如果scp到目標主機後和原來備份組的儲存路徑不一致，那麼控制檔案中記錄的         所有的備份組的中繼資料資訊都將失效，必須執行：catalog start with         ‘/backupset_path‘

讓控制檔案自動識別備份組的中繼資料資訊（路徑、備份片名等）。

 

現在在目標端設定備份組的儲存路徑和源端一致，這樣就避免了需要控制檔案自動識別         備份組中繼資料的過程，避免備份組識別不完全（漏掉備份片）

目標端備份組規劃路徑如下：

full備份：

database：/u01/app/oracle/oradata/backupset/prod4/full/database

controlfile: /u01/app/oracle/oradata/backupset/prod4/full/controlfile

arch     : /u01/app/oracle/oradata/backupset/prod4/full/arch

controfile備份：

controlfile：/u01/app/oracle/oradata/backupset/prod4/controlfile

arch備份：

arch     ：/u01/app/oracle/oradata/backupset/prod4/arch

自動備份控制檔案和spfile：

controlfile+spfile：

/u01/app/oracle/oradata/autobackup/prod4

三、規格恢複後資料庫的資料檔案儲存路徑

恢複的新instance名為：CPROD4

全庫恢複後的資料檔案儲存路徑：

datafile：/u01/app/oracle/oradata/CPROD4/datafile

redo   ：/u01/app/oracle/oradata/CPROD4/onlinelog

tempfile：/u01/app/oracle/oradata/CPROD4/tempfile

controlfile：/u01/app/oracle/oradata/CPROD4/controlfile

arch     ：/u01/app/oracle/oradata/CPROD4/arch

【漫兮網（http://www.manxinet.com）】

四、全庫恢複

1、在源端資料庫做全庫備份和歸檔備份

（實際實驗前要清空所有備份組delete backup ,但生產上嚴禁執行該操作）

a.全庫備份，在edsir1p8上執行指令碼：rman_prod4_full_01.sh

b.歸檔備份，在edsir1p8上執行指令碼：rman_prod4_arch_01.sh

c.備份完成後要查看是否在備份期間產生了新的歸檔日誌。

註：如果在備份期間產生了新的歸檔日誌，並且已經寫入到了控制檔案的

v$archived_log視圖中，但是在備份歸檔時卻沒有備份，然後在控制檔案自動                               備份時將當前控制檔案備份了，即備份的控制檔案中記錄了沒有備份的歸檔日                       志，這樣再後續確定恢複截至到的scn號時就會報錯，找不到對應的歸檔日誌                            （備份期間產生的歸檔日誌沒有被備份走）

所以在後續確定恢複截至到的scn號時一定要先確定備份組中是否有對應SCN                    號的歸檔日誌，不能僅通過v$archived_log視圖就簡單的確定恢複截至SCN

2、scp或其他方式匯入到目標主機

a.傳輸資料檔案

進入到源端edsir1p8的/u01/app/oracle/oradata/backupset/prod4/full/database                       目錄下

scp * 192.168.33.138: /u01/app/oracle/oradata/backupset/prod4/full/database

b.傳輸全備的歸檔：

進入到源端edsir1p8的/u01/app/oracle/oradata/backupset/prod4/full/arch

scp * 192.168.33.138: /u01/app/oracle/oradata/backupset/prod4/full/arch

c.後續傳輸所有備份組：full備份的控制檔案、歸檔日誌、單獨備份的控制檔案、                       自動備份的控制檔案

註：scp時的“*”表示傳輸當前路徑下的所有檔案到目標端

3、spfile檔案的恢複

a.使用rman內建的參數檔案啟動到nomount狀態

（i）在138上切換環境變數目的是切換到正確的ORACLE_HOME下可以使用                                          bin目錄下的rman

. oraenv

ORACLE_SID=PROD1

（ii）設定ORACLE_SID恢複該SID對應的spfile檔案：spfileSID.ora

export  ORACLE_SID=CPROD4

（iii）啟動rman到nomount狀態

rman target /

RMAN > startup nomount

b.恢複spfile

（i）restore spfile檔案

RMAN >  restore  spfile  from

‘/u01/app/oracle/oradata/autobackup/prod4/ctl_c-1612213667-20160305-05‘;                               執行過程中會報如下錯誤：

錯誤一：

 

reason：源端資料庫開啟了share mode模式的串連，修改了spfile中的六個參                     數，現在使用spfile時檢測spfile中儲存的系統參數發現在目標端沒有，因此                              報以上錯誤。

PROD4_1526是shared模式的訪問串連。並且註冊到了local_listener上，但是                    在目標端138上沒有對應的監聽和tns別名，需要建立

solution：

從137上複製如下監聽內容到138的listener.ora檔案中

SID_LIST_PROD4_1526 =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = PROD4.us.oracle.com)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1)

(SID_NAME = CPROD4)

)

)

 

PROD4_1526 =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = edsir4p1.us.oracle.com)(PORT = 1526))

)

 

ADR_BASE_PROD4_1526 = /u01/app/oracle

從137上複製如下TNS別名內容到138的tnsnames.ora檔案中

PROD4_1526 =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = edsir4p1.us.oracle.com)(PORT = 1526))

)

(CONNECT_DATA =

(SERVER = SHARED)

(SERVICE_NAME = PROD4.us.oracle.com)

)

)

 

錯誤二：

再次試圖開啟資料庫到nomount狀態:

SQL >  startup nomouont

會報以上錯誤

reason：

源端137上開啟了Database Audit功能需要建立audit目錄，但是138上沒有對應                      的audit目錄

solution：

在137上查看參數：show parameter audit

audit_file_dest    string          /u01/app/oracle/admin/PROD4/adump

在138上建立該目錄：mkdir -p /u01/app/oracle/admin/PROD4/adump

 

或者：

在目標端138上如果資料庫能啟動到nomount狀態，可以在138端查看參數

audit_file_dest，然後建立該目錄

 

c.使用恢複的spfile重新開啟資料庫到nomount狀態

shutdown immediate

startup nomount

4、controlfile檔案的恢複

a.先修改controlfile檔案的路徑

因為在137上controlfile是儲存在+DATA磁碟組上的，138上沒有ASM執行個體，故               不能成功restore controlfile。

執行如下指令：

alter system set control_files=‘ /u01/app/oracle/oradata/CPROD4/controlfile/                                       control01.ctl‘ scope=spfile;

重啟資料庫，重新載入spfile：

shutdown immediate

startup nomount

b.controlfile的恢複

restore controlfile from

‘/u01/app/oracle/oradata/autobackup/prod4/ctl_c-1612213667-20160305-05‘;

1. 修改資料庫到mount狀態

RMAN > alter database mount;

5、database的恢複

a.確定能恢複到的最大SCN號

(i)從v$archived_log視圖中查詢最後一個歸檔的結束SCN值

select name,RESETLOGS_CHANGE#,RESETLOGS_ID,FIRST_CHANGE#,NEXT_CHANGE# from v$archived_log;

中是恢複後新產生的歸檔日誌，不是原來恢複前控制檔案中記錄的歸檔日誌的資訊。

原來控制檔案中記錄的歸檔的最後一個scn值為：2460383

(ii)在備份組中確認真正存在對應 該SCN值的備份片

list backup of archivelog all;

在對應路徑

/u01/app/oracle/oradata/backupset/prod4/arch/arch_PROD4_905667093_729_1.bak下確認備份片是否真正儲存（注意是確認scp的過程中是否把備份片正確的傳輸過來了）

同時在顯示的備份組列表上觀察相關的歸檔記錄備份是否連續。

(iii)在備份片確認真正存在的情況下，再次確認incarnation的值，目的是確認在recover的過程中是否會去一直追加2460383歸檔對應的resetlog_scn的該批的歸檔日誌

從v$archived_log視圖中查詢2460383歸檔對應的RESETLOGS_CHANGE#列值為：2167043

從rman中： RMAN > list incarnation

1       1       PROD4    1612213667       CURRENT 2167043    02-MAR-16

結果顯示當前的incarnation對應的Reset SCN的值為2167043

incarnation. Reset SCN =v$archived_log.maxSCN. RESETLOGS_CHANGE#

滿足以上條件就說明：在recover的過程中會去尋找和最大SCN對應相同的       RESETLOGS_CHANGE#值的那一批歸檔日誌，直到追加完最大SCN號的歸檔日誌。
如果不滿足以上條件說明：在recover的過程中不會去尋找和最大SCN號的歸檔日誌的

RESETLOGS_CHANGE#列值對應相等的那一批歸檔。這時候如果是簡單為了搭建測試環    境不考慮遺失資料的多少，可以在v$archived_log視圖中尋找合適的SCN值，直到可以       追平v$datafile_header視圖中的所有檔案頭的CHECKPOINT_CHANGE#，這樣就可以          resetlogs開啟資料庫

如果考慮到儘可能的少遺失資料就需要設定當前的incarnation值使得滿足條件：

incarnation. Reset SCN =v$archived_log.maxSCN. RESETLOGS_CHANGE#

這樣就可以在recover的過程中一直追加所有歸檔，直到追加完最大SCN值對應的歸檔  日誌。這也是全庫恢複時遺失資料儘可能少的解決辦法。這樣設定可以恢複到丟失最少     資料的狀態。（丟失的只有redo中的資料）

 

b.關閉資料庫閃回功能

在源端137上開啟了資料庫閃回功能：

因為開始資料庫閃回時的閃回日誌儲存路徑在：+FLASHBACK磁碟組上

並且開啟資料庫閃回後resetlogs時重建的redo要預設放在和閃回日誌相同的            路徑下，因此要提前校正+FLASHBACK磁碟組，並且在執行restore database時也要               校正資料庫閃回

在138端沒有ASM執行個體，並且也沒有+FLASHBACK磁碟組，因此在後續的執行restore             database時就會報錯，所以需要在138上關閉資料庫閃回功能，並重啟資料庫重新                   載入spfile和controlfile

執行如下操作：

138上關閉資料庫閃回：

alter database flashback off;

確認關閉是否成功：

select name ,FLASHBACK_ON from v$database;

關閉資料庫：

shutdown immediate

重新載入spfile和controlfile

startup mount

因為資料庫閃回引起的報錯如下：

c.修改歸檔路徑

因為137上的歸檔路徑為+ARCH磁碟組

在138上沒有ASM執行個體更沒有+ARCH磁碟組，所以在recover的過程中會報錯，如 下：

報錯資訊顯示沒有起始SCN為2443916和2427335的歸檔日誌。

排除過程如下：

RMAN > list backup of archivelog all

查過所以歸檔備份組，找到包含該起始SCN的備份片，首先確認在rman的catalog中    是否有這個兩個歸檔的備份片及中繼資料資訊

通過Low SCN和 Next SCN值確定是否有該歸檔日誌的備份片

然後在對應路徑下確認該檔案是否存在

如果不存在說明scp 的過程中出錯：需要重新scp

如果在list backup of archivelog all的顯示結果中沒有找到，可能的原因是沒有註冊到rman上，需要重新把歸檔備份組的路徑再註冊一次到rman中：

catalog start with ‘ /u01/app/oracle/oradata/backupset/prod4/arch‘

catalog start with ‘ /u01/app/oracle/oradata/backupset/prod4/full/arch‘

如果在list backup of archivelog all的顯示結果中有對應的備份片，並且在指定路徑下確實存在該備份片檔案。那麼可能的原因就是源端137上的歸檔路徑在138上沒有建立，即138上沒有源端的歸檔日誌存放路徑。

因為在執行recover的過程中，追加日誌的執行過程是這樣的：

@先把歸檔記錄備份集釋放到控制檔案中記錄的歸檔日誌存放路徑

137上是+ARCH磁碟組，所以在138上會尋找釋放存在+ARCH磁碟組

@將所有歸檔備份組釋放到歸檔日誌存放路徑下，釋放成歸檔記錄檔

@recover過程中讀取該路徑下的歸檔記錄檔

 

綜上所述：必須在目標端建立和源端相同的路徑的歸檔日誌存放目錄，或者重新指定歸檔日誌存放路徑

 

因為137端歸檔日誌路徑為+ARCH磁碟組

138上沒有ASM執行個體，必須重新指定歸檔路徑

 

執行如下操作：

查看控制檔案中記錄的歸檔路徑：

show parameter archive

修改歸檔路徑：

alter system set log_archive_dest_1=‘location=/u01/app/oracle/oradata/CPROD4/arch‘

 

一致性關閉資料庫

shutdown immediate

 

重新載入spfile和controlfile

startup mount

b.執行恢複指令碼

(i) 先查詢出控制檔案中記錄的所有的資料檔案資訊

select name from v$datafile;

(ii)修改restore的資料檔案儲存新路徑，即恢複到不同的目錄下

set newname for datafile  ‘+DATA/prod4/datafile/system.286.905335925‘ to                                                                            ‘/u01/app/oracle/oradata/PROD4_T/datafile/system‘;

(iii)執行restore database;

把資料檔案備份組釋放到對應的新儲存目錄下，並重新命名成新的指定文                                     件名

(iv)修改控制檔案中新的資料檔案的指標

switch datafile all;

(v)追加歸檔日誌recover資料庫

recover database;

指令碼大致內容如下：

run {

set until scn 2460383;

set newname for datafile  ‘+DATA/prod4/datafile/system.286.905335925‘ to                                          ‘/u01/app/oracle/oradata/CPROD4/datafile/system.dbf‘;

restore database;

switch datafile all;

recover database;

}

具體指令碼參考：CPROD4_setNewName_recover.txt

註：指令碼執行過程中要tail -f  recover_log.log記錄檔，跟蹤恢複過程

【漫兮網（http://www.manxinet.com）】

6、重建controlfile檔案修改redo的復原路徑

recover完成後不能resetlogs方式開啟資料庫，因為還沒有redo檔案，沒有redo     的情況下，任何到資料庫的訪問會話都會被oracle kill掉。

 

該步執行resetlogs方式開啟資料庫的報錯如下：

reason：

源端137的redo存放路徑在+ FLASHBACK磁碟組

SQL> select member from v$logfile;

 

MEMBER

---------------------

+FLASHBACK/prod4/onlinelog/group_4.366.905339795

+FLASHBACK/prod4/onlinelog/group_1.368.905339781

+FLASHBACK/prod4/onlinelog/group_2.374.905339785

+FLASHBACK/prod4/onlinelog/group_3.369.905339787

目標端138上沒有ASM執行個體更沒有+FLASHBACK磁碟組，所以在執行resetlogs方式開啟 資料庫時不能成功建立redo檔案。

解決辦法：可以建立和源端137上相同路徑的redo存放目錄，或者重建控制檔案重新    指定redo的存放路徑

註：預設用resetlogs方式開啟資料庫時只能建立三個日誌組，並且每組只能有一個成                      員。

solution：

重建controlfile：

執行如下操作：

@mount狀態備份控制檔案到trace

alter database backup controlfile to trace as

‘/u01/app/oracle/oradata/CPROD4/controlfile/recreateCtl.ctl‘;

@gedit編輯控制檔案

gedit   /u01/app/oracle/oradata/CPROD4/controlfile/recreateCtl.ctl

重新指定redo的存放路徑並以resetlogs方式重建controlfile。

修改後的內容參考指令碼：recreateCtl.txt

@執行指令碼

SQL > @/u01/app/oracle/oradata/CPROD4/controlfile/recreateCtl.ctl

@一致性關閉資料庫

shutdown  immediate

@重新載入控制檔案

startup mount

7、開啟資料庫到open狀態

alter database open resetlogs;

五、修改日誌組，按照業務需求添加日誌組及成員

a.添加日誌組

alter database add logfile group 4

‘/u01/app/oracle/oradata/CPROD4/onlinelog/redo04a.log‘ size 50m;

b.日誌組新增成員

alter database add logfile member

‘/u01/app/oracle/oradata/CPROD4/onlinelog/redo04b.log‘  to group 4;

最終日誌組及成員設定情況如下：

 

註：添加完日誌組後要切換下日誌組，把unused狀態切換到正常狀態。

alter system switch logfile;

同時再次確認日誌群組成員member的status是正常狀態。

六、添加暫存資料表空間、臨時資料檔案

a.查詢系統預設暫存資料表空間

select * from database_properties where property_name=‘DEFAULT_TEMP_TABLESPACE‘;

b.查詢臨時資料檔案

select name,status from v$tempfile;

c.對系統預設暫存資料表空間添加臨時資料檔案

alter tablespace temp add tempfile

‘/u01/app/oracle/oradata/CPROD4/tempfile/temp01.dbf‘ size 300m;

d.根據業務需求添加臨時資料檔案，最終設定如下：

 

【漫兮網（http://www.manxinet.com）】

七、校正是否成功恢複到指定SCN

查詢v$datafile_header視圖確認資料檔案頭的真實SCN

select name, CHECKPOINT_CHANGE# from v$datafile_header;

確認資料檔案頭的SCN成功恢複到指定SCN : 2460383

八、完成全庫恢複（或測試環境搭建）的整個過程

本文由 漫兮 首發於【漫兮網（http://www.manxinet.com）】--轉載請註明【漫兮網】

rman全庫恢複到不同主機，不同執行個體名，不同目錄下