dataguard備庫的資料檔案的遷移實戰

在前幾天也花了一點時間測試了一下關於備庫資料檔案的遷移，這部分的工作看起來還是比較常規的，當然方法也很多。但是在實際工作中就更不能掉以輕心，所有的操作都要有理有據。都要經過一些嚴格的測試，如果測試不當，很可能在後期就會出現一些看似奇怪的問題，造成一些不必要的麻煩和影響。

所以在開始之前，做了下面的準備工作。
1.在zabbix中設定了維護視窗，這樣在維護操作中就不會報警。
2.檢查目前的備庫引數設定，是否開啟了閃回區，目前的檔案路徑設定情況和歸檔情況
3.檢查目標檔案路徑的情況，涉及許可權，資料夾屬主，大小等
4.準備完整的指令碼，估算時間。
第一步中，設定維護視窗的方式如下，加入對應的機器就萬事大吉了。

第二步中備庫沒有設定db_file_name_convert和log_file_name_convert,所以說是預設按照主庫的路徑來生成的。
檢查閃回區竟然沒有開啟，還是不太規範，都是指定使用了歸檔路徑。
SQL> show parameter recovery
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------
db_recovery_file_dest                string
db_recovery_file_dest_size           big integer 0
SQL> show parameter log_archive_dest
NAME                                 TYPE        VALUE
------------------------------------ ----------- ----------
log_archive_dest                     string
log_archive_dest_1                   string      location="/U01/app/oracle/admin/testdb/arch",  valid_for=(ALL_LOGFILES,ALL_ROLES)
對此的產出指令碼如下：
alter system set db_recovery_file_dest='/U01/app/oracle/admin/testdb/arch' scope=spfile;
alter system set db_recovery_file_dest_size=100G;
alter system log_archive_dest_1='location=USE_DB_RECOVERY_FILE_DEST' scope=spfile;
對於資料檔案和日誌檔案的路徑切換
alter system set db_file_name_convert='/U01/app/oracle/oradata/testdb','/DATA/testdb' scope=spfile;
alter system set log_file_name_convert='/U01/app/oracle/oradata/testdb,/Redo/testdb' scope=spfile;
第三步中
磁碟空間情況如下，許可權屬主都沒有問題。
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
。。。
/dev/sda6       510G  393G   92G  82% /U01
/dev/sdc1       733G  197M  696G   1% /DATA
/dev/sdb2       534G  198M  506G   1% /Redo
。。。
第四步中，如果採用rman的方式遷移資料檔案就需要提前準備指令碼。可以使用如下的方式生成動態指令碼。
select 'COPY DATAFILE '||file#||' to '||chr(39)||name||chr(39)||';'||chr(10)
||' switch datafile '||file#||' to copy;'||chr(10)
||' sql '||chr(39)||'alter database datafile '||file#||' online;' from v$datafile;
生成內容如下：
COPY DATAFILE 5 to '/DATA/testdb/acc_data01.dbf';
 switch datafile 5 to copy;
 sql 'alter database datafile 5 online;
。。。
準備好指令碼就開始實踐了。
因為這個操作有些引數需要重啟生效，而且這套環境是一主兩備，所以重啟暫時沒有什麼風險。因為考慮到修改convert引數會導致dg broker檢查失敗，需要修改dg broker的引數，如此一來還不如直接做remove操作，遷移完成直接再add database即可，也就免去了更多的屬性修改設定。
所以部署指令碼如下：
remove database stestdb2;   --在dg broker中操作
alter system set db_recovery_file_dest='/U01/app/oracle/admin/testdb/arch' scope=spfile;
alter system set db_recovery_file_dest_size=100G;
alter system set log_archive_dest_1='location=USE_DB_RECOVERY_FILE_DEST' scope=spfile;
alter system set db_file_name_convert='/U01/app/oracle/oradata/testdb','/DATA/testdb' scope=spfile;
alter system set log_file_name_convert='/U01/app/oracle/oradata/testdb','/Redo/testdb' scope=spfile;
重啟資料庫例項至mount階段
然後就準備開始rman遷移檔案了。
但是剛開始就碰到一些意料之外的事情。遷移的時候竟然提示找不到檔案。
RMAN> COPY DATAFILE 1 to '/DATA/testdb/system01.dbf';
Starting backup at 2016-02-29 10:47:21
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=6596 devtype=DISK
could not read file header for datafile 1 error reason 4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 02/29/2016 10:47:21
RMAN-06056: could not access datafile 1
經過一番排查發現原來在v$datafile裡，檔案路徑已經根據db_file_name_convert變成了最新的路徑了。
即原來的路徑
FILE_NAME
------------------------------------------------------------
/U01/app/oracle/oradata/testdb/users01.dbf
/U01/app/oracle/oradata/testdb/sysaux01.dbf
/U01/app/oracle/oradata/testdb/undotbs01.dbf
在重啟之後v$datafile裡面已經變成了下面的樣子。
FILE_NAME
------------------------------------------------------------
/DATA/testdb/users01.dbf
/DATA/testdb/sysaux01.dbf
/DATA/testdb/undotbs01.dbf    
當然這部分資訊在官方文件中也是有出處的。可以參考http://www.di.unipi.it/~ghelli/didattica/bdldoc/B19306_01/backup.102/b14191/rcmdupdb002.htm    
對於這部分內容，還是會有一個優先順序設定。按理說這部分資訊是寫在控制檔案中的。沒想到通過convert的資料看引數應優先生成了。
那麼我們需要做的事情就更簡單了。只需要作業系統級拷貝資料檔案即可。
拷貝完成之後，在dg broker中新增這個例項即可。
add database stestdb2 as
 connect identifier is stestdb2
 maintained as physical;
enable database stestdb2;
看似一個略帶複雜的遷移就這麼輕鬆完成了，感覺做什麼技術含量的事情，前期準備充足，在碰到問題的時候才會更加從容。
                                      

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2017314/，如需轉載，請註明出處，否則將追究法律責任。