遷移需求：
1、兩邊資料保持一致
2、停機時間很短
3、不借助行動硬碟之類的裝置
4、nocatelog

背景：
1、兩邊資料庫和OS版本一致
2、DML操作比較頻繁
3、原資料庫資料量很大

分析：
1、實現方式有多種，如prebuild MV、RMAN、DG、host cp等
Prebuild MV需要做的後續工作太多；DG配置複雜
用rman的話，因為庫比較大，如果本地空間不足，備份就可能失敗。另外，就算空間足夠，因為在傳送過程也會耗時不少，這段時間會產生很多的歸檔，要應該這些歸檔也會很慢，不滿足停機時間很短的需求。
用host cp的方式，透過一些取巧的辦法可以滿足需求。

步驟：
1、將表空間置於begin backup狀態
2、用ftp或者scp等傳送資料檔案到目標伺服器對應目錄上
3、將表空間置於end backup狀態
4、將歸檔日誌複製到目標伺服器，並將最後幾個歸檔改名或者移到其他路徑
加入主庫有N組聯機日誌，則把最後N個歸檔改名（可以不改名或移動，但以防萬一最好這樣做，否則恢復可能有問題）
5、複製密碼檔案和聯機日誌到目標庫上
之所以要複製聯機日誌是因為在目標庫recover database的時候會檢查日誌頭，如果發現日誌大小或日誌組資訊不吻合，recover將會失敗。
6、在源庫alter system backup constrolfile to trace;
然後開啟這個trace檔案，選擇noresetlogs這部分內容
7、在目標庫startup nomount，然後重建控制檔案（如果兩邊路徑不一致，需要編輯trace的內容）
8、在目標庫recover database
9、recover database完成後關閉目標庫
10、停止源庫，複製密碼檔案和聯機日誌到目標庫上
11、把新產生的歸檔複製到目標庫上
12、在目標庫上把第4步改名的歸檔名字改回來
13、重複7、8步
14、alter database open

這裡主要是利用重建控制檔案的方式先應用在傳輸資料檔案期間產生的歸檔，使得最後一次recover只需要應用在第一次recover期間產生的新歸檔，那樣，最後一次recover的時間大大減少，停機時間也大大減少。

減少熱備方法遷移資料庫的停機時間

相關文章