最近先後幫客戶做了兩套從虛擬化環境到物理機的資料庫遷移，都是Linux系統，Oracle 11.2.0.4的RAC，最終選定ADG方案實現遷移，簡單高效。
在之前的文章Oracle 11g ADG 部署(duplicate)快速參考中，已經詳細介紹了搭建步驟。但本次環境準備時還是遇到些小問題，本文記錄下解決過程。
問題1:備庫Redo的一個member路徑有誤
按流程做完發現備庫在open後，Redo的一個member路徑有誤，都是+FRA磁碟組：SQL> select member from v$logfile;
MEMBER
-----------------------------------------------------------
+DATA/jingyus/onlinelog/group_1.383.1050758359
+FRA
+DATA/jingyus/onlinelog/group_2.384.1050758359
+FRA
+DATA/jingyus/onlinelog/group_3.385.1050758359
+FRA
+DATA/jingyus/onlinelog/group_4.386.1050758359
+FRA
+DATA/jingyus/onlinelog/group_5.397.1050758359
+FRA
+DATA/jingyus/onlinelog/group_6.398.1050758361
MEMBER
-----------------------------------------------------------
+FRA
+DATA/jingyus/onlinelog/group_7.399.1050758361
+FRA
+DATA/jingyus/onlinelog/group_8.400.1050758361
+FRA
+DATA/jingyus/standbylog/standby_group_101.log
+DATA/jingyus/standbylog/standby_group_102.log
+DATA/jingyus/standbylog/standby_group_103.log
+DATA/jingyus/standbylog/standby_group_104.log
+DATA/jingyus/standbylog/standby_group_105.log
+DATA/jingyus/standbylog/standby_group_201.log
MEMBER
----------------------------------------------------------
+DATA/jingyus/standbylog/standby_group_202.log
+DATA/jingyus/standbylog/standby_group_203.log
+DATA/jingyus/standbylog/standby_group_204.log
+DATA/jingyus/standbylog/standby_group_205.log
26 rows selected.
這樣的路徑不全，也無法使用常規命令刪除掉。
首先想到的是查convert引數是否配置有誤：
--convert:
SQL> show parameter convert
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string jingyu, jingyus
log_file_name_convert string +fra/jingyu, +arch/jingyus, jingyu,
jingyus
確認符合實際要求，沒有問題。
檢查db_recovery相關引數：
SQL> show parameter db_recovery
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string +FRA
db_recovery_file_dest_size big integer 90G
果然是這裡有問題，新環境應該是+ARCH磁碟組，而且客戶這裡的新規範是不配置此引數，這裡將引數去掉，重啟例項生效：
SQL> alter system reset db_recovery_file_dest_size;
System altered.
SQL> alter system reset db_recovery_file_dest;
System altered.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 7.4826E+10 bytes
Fixed Size 2261048 bytes
Variable Size 1.3959E+10 bytes
Database Buffers 6.0666E+10 bytes
Redo Buffers 199049216 bytes
Database mounted.
SQL> show parameter db_recover
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string
db_recovery_file_dest_size big integer 0
SQL>
問題2:switch database to copy報錯RMAN-6571
上面改完之後，已經有問題的member並不會自己修復，需要去主庫生成適用於備庫的控制檔案，在備庫進行恢復：--standby controlfile
primary:
RMAN> backup current controlfile for standby format '/tmp/std_ctl.bak';
scp to standby.
standby:
shutdown immediate
startup nomount
RMAN> restore standby controlfile from '/tmp/std_ctl.bak';
alter database mount;
此時資料檔案的名字因為OMF並不一樣，convert轉換的只有jingyu->jingyus，下面是示例：
selct name from v$datafile;
select member from v$Logfile;
NAME
--------------------------------------------------------------------------------
+DATA/jingyu/datafile/dmb_ts.381.1046616217
+DATA/jingyu/datafile/dmb_ts.383.1047808801
+DATA/jingyu/datafile/dmo_ts.384.1048122001
+DATA/jingyu/datafile/dmb_ts.385.1048755601
+DATA/jingyu/datafile/dmb_ts.386.1049724001
+DATA/jingyu/datafile/rpm.387.1049986803
116 rows selected.
--由於配置了db_file_name_convert 引數：
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string jingyu, jingyus
--會按上面設定的規則轉換：
NAME
--------------------------------------------------------------------------------
+DATA/jingyus/datafile/dmb_ts.381.1046616217
+DATA/jingyus/datafile/dmb_ts.383.1047808801
+DATA/jingyus/datafile/dmo_ts.384.1048122001
+DATA/jingyus/datafile/dmb_ts.385.1048755601
+DATA/jingyus/datafile/dmb_ts.386.1049724001
+DATA/jingyus/datafile/rpm.387.1049986803
116 rows selected.
但實際上我們同步過來的資料檔案是這樣：
+DATA/jingyus/datafile/dmb_ts.342.1050704211
+DATA/jingyus/datafile/dmb_ts.363.1050706625
+DATA/jingyus/datafile/dmo_ts.364.1050706641
+DATA/jingyus/datafile/dmb_ts.365.1050706649
+DATA/jingyus/datafile/dmb_ts.366.1050706655
+DATA/jingyus/datafile/rpm.367.1050706663
116 rows selected.
最直接的方式是通過資料庫的rename file 命令進行一一更正，但是比較麻煩，有一個通用的技巧就是將這些真實的檔案catalog到rman中，將以copy的方式識別，然後直接switch到copy，就實現了更名的目的，且不容易出錯：
catalog start with '+DATA/jingyus/datafile';
switch database to copy;
結果10號檔案報錯RMAN-6571，跳過10號檔案，也是其他檔案接連報錯，看oerr的解釋：
$ oerr rman 6571
6571, 1, "datafile %d does not have recoverable copy"
// *Cause: The SWITCH command with the option TO COPY was specified but
// the datafile has no valid copy to switch to.
// *Action: Verify whether the datafile has a valid datafile copy.
順手還去查了MOS文件
- OERR: RMAN-6571 "datafile %d does not have recoverable copy" Reference Note (Doc ID 291493.1)
也沒找到有效的解決方案。後來走了些彎路，又嘗試做了一次備庫控制檔案的建立，效果依舊。
此時想到不如查下檔案頭，看看到底差異在哪，結果發現檔案10-20都是別名的方式，根本不需要去switch：
SQL> select file#, name, checkpoint_change# from v$datafile_header;
FILE# NAME CHECKPOINT_CHANGE#
------------------------------ ------------------------------------------------------------------ ------------------------------
1 0
2 0
3 0
4 0
5 0
6 0
7 0
8 0
9 0
10 +DATA/jingyus/datafile/dmb_ts01.dbf 98520735063
11 +DATA/jingyus/datafile/dmb_ts02.dbf 98520735063
FILE# NAME CHECKPOINT_CHANGE#
------------------------------ ------------------------------------------------------------------ ------------------------------
12 +DATA/jingyus/datafile/dmb_ts03.dbf 98520735063
13 +DATA/jingyus/datafile/dmb_ts04.dbf 98520735063
14 +DATA/jingyus/datafile/dmo_ts01.dbf 98520735063
15 +DATA/jingyus/datafile/dmo_ts02.dbf 98520735063
16 +DATA/jingyus/datafile/dmo_ts03.dbf 98520735063
17 +DATA/jingyus/datafile/etl_ts01.dbf 98520735063
18 +DATA/jingyus/datafile/rpm01.dbf 98520735063
19 +DATA/jingyus/datafile/use01.dbf 98520735063
20 +DATA/jingyus/datafile/dms_ts01.dbf 98520735063
21 0
22 0
...省略後面無問題的顯示。
再次驗證下問題檔案數，就是有這11個：
SQL> select checkpoint_change#, count(*) from v$datafile_Header group by checkpoint_change#;
CHECKPOINT_CHANGE# COUNT(*)
------------------------------ ------------------------------
0 105
98520757598 11
確認後，就只需要將需要switch的檔案列出來：
switch datafile 1,2,3,4,5,6,7,8,9,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101 to copy;
再次查詢：
SQL> set num 30
SQL> select checkpoint_change#, count(*) from v$datafile_Header group by checkpoint_change#;
CHECKPOINT_CHANGE# COUNT(*)
------------------------------ ------------------------------
98520757598 116
此時開庫，名字也都是OK：
SQL> alter database open;
Database altered.
SQL> select member from v$logfile;
MEMBER
---------------------------------------------------------
+DATA/jingyus/onlinelog/group_1.257.950284165
+ARCH/jingyus/onlinelog/group_1.257.950284167
+DATA/jingyus/onlinelog/group_2.258.950284167
+ARCH/jingyus/onlinelog/group_2.258.950284169
+DATA/jingyus/onlinelog/group_3.265.950286045
+ARCH/jingyus/onlinelog/group_3.259.950286047
+DATA/jingyus/onlinelog/group_4.266.950286047
+ARCH/jingyus/onlinelog/group_4.260.950286049
+DATA/jingyus/onlinelog/group_5.286.959014699
+ARCH/jingyus/onlinelog/group_5.266.959014703
+DATA/jingyus/onlinelog/group_6.287.959014717
MEMBER
---------------------------------------------------------
+ARCH/jingyus/onlinelog/group_6.273.959014719
+DATA/jingyus/onlinelog/group_7.288.959014729
+ARCH/jingyus/onlinelog/group_7.277.959014731
+DATA/jingyus/onlinelog/group_8.289.959014753
+ARCH/jingyus/onlinelog/group_8.269.959014755
+DATA/jingyus/standbylog/standby_group_101.log
+DATA/jingyus/standbylog/standby_group_102.log
+DATA/jingyus/standbylog/standby_group_103.log
+DATA/jingyus/standbylog/standby_group_104.log
+DATA/jingyus/standbylog/standby_group_105.log
+DATA/jingyus/standbylog/standby_group_201.log
+DATA/jingyus/standbylog/standby_group_202.log
+DATA/jingyus/standbylog/standby_group_203.log
+DATA/jingyus/standbylog/standby_group_204.log
+DATA/jingyus/standbylog/standby_group_205.log
26 rows selected.
然後啟動備庫的mrp時，會自動刪除+ARCH 下的路徑，這個應該就是因為我們前面去掉了db_recover的相關設定：
--recover ,+ARCH auto deleted..
SQL> select member from v$logfile;
MEMBER
--------------------------------------------------------
+DATA/jingyus/onlinelog/group_1.397.1050759359
+DATA/jingyus/onlinelog/group_2.398.1050759359
+DATA/jingyus/onlinelog/group_3.399.1050759359
+DATA/jingyus/onlinelog/group_4.400.1050759361
+DATA/jingyus/onlinelog/group_5.401.1050759361
+DATA/jingyus/onlinelog/group_6.402.1050759361
+DATA/jingyus/onlinelog/group_7.403.1050759361
+DATA/jingyus/onlinelog/group_8.404.1050759363
+DATA/jingyus/standbylog/standby_group_101.log
+DATA/jingyus/standbylog/standby_group_102.log
+DATA/jingyus/standbylog/standby_group_103.log
+DATA/jingyus/standbylog/standby_group_104.log
+DATA/jingyus/standbylog/standby_group_105.log
+DATA/jingyus/standbylog/standby_group_201.log
+DATA/jingyus/standbylog/standby_group_202.log
+DATA/jingyus/standbylog/standby_group_203.log
+DATA/jingyus/standbylog/standby_group_204.log
+DATA/jingyus/standbylog/standby_group_205.log
18 rows selected.
至此，遇到的問題就都解決了。鬆一口氣，等待晚上配合切換即可。