Datapump資料移轉前的準備工作（二）

Datapump資料移轉前的準備工作（二）

之前寫了一篇文章分析了Datapump遷移資料的一些準備總結，反響還不錯。最近碰到一個情境，根據評估還是使用Datapump比較好。主要的原因如下：

1.原來的環境在Solaris下，硬體資源老舊，需要遷移到Linux下，跨平台遷移使用邏輯遷移優先

2.原來的環境使用10gR2,現在需要順帶遷移到11gR2，充分解決備庫“不中用”的情況

3.遷移的資料量不算大，在幾百G以內，可以充分利用頻寬和I/O輸送量來達到預期的時間視窗。

而在這個方案之外，考慮到提高效能，我們採用了PCIE-SSD的方案加速I/O，當然使用了和源庫不同的分區。

為了使應用的影響降低到最低，我們決定在遷移之後切換IP，使得新的資料庫環境擁有原來的IP，這樣應用端就無需做任何串連資訊的修改了，DB Link的問題也能得到一併解決，無需確認更多的細節。

如果應用有重連機制，那麼這種方案之外對於應用是完全透明的，就跟啟停一下應用的效果一樣。

這種方案使用Datapump遷移前看起來還是照葫蘆畫瓢，但是細細想來卻有一些隱患和需要預先解決的地方，不知道大家看到我提供的背景是否有一些想法。

1.為了降低切換IP帶來的繁瑣和更多可能的隱患，所以在listener.ora,tnsnames.ora中的host資訊都統一為主機名稱，這樣在/etc/hosts中統一修改即可。切換IP後只修改這一處配置即可。

2.Solaris的防火牆資訊設定和Linux還是截然不同的。這個裡面就有很多資訊需要確認。

Solaris環境下的防火牆開通是類似下面的形式：

如果要對10.xxxx的IP開通1522的連接埠存取權限，使用下面的方式在記憶體中和檔案中都做配置

記憶體中設定，線上生效，其中e1000g0 為網卡的名稱，就跟Linux中的eth0,eth1是一樣的。

echo 'pass in quick on e1000g0 proto tcp from 10.xxxxx to any port = 1522' | ipf -f -

在檔案中補充

/etc/ipf/ipf.conf ||pass in quick on e1000g0 proto tcp from 10.xxxxx to any port = 1522

在Linux下則要簡單許多,類似下面的形式

iptables -I INPUT -s  10.xxxx  -p tcp -m multiport --dports 1522  -i  eth0  -j ACCEPT

如果要寫入設定檔，則可以直接service iptables save

這個配置資訊的變更讓我花了些時間，其中還有一些空格類的，個別文法的差異，最後乾脆直接手工來調整了。

3.對於目標庫的設定，有一個很大的隱患，就是源庫和目標庫的檔案路徑不同，我在上面也提到了使用PCIE-SSD採用了不同的分區，所以如果直接採用全庫匯入是肯定會有隱患，倒不是出錯，而是會造成資源的浪費。比如源庫中的檔案路徑是/U01/xxxx 而在目標庫是/U02/xxx，在這種情況下如果全庫匯入，產生的資料表空間，資料檔案都會在/U01下，如果遷移完成之後反應過來，那已經有些晚了，還得重新再遷移一遍，要麼重建控制檔案，要麼直接rename，在升級視窗有限的時間裡這種突發情況花費的時間肯定不是一兩分鐘，恐懼和慌亂很可能會花去至少10多分鐘的時間。

4.對於未知問題的考慮，我也有一些補充的想法，在源庫中匯出資料，如果開啟大並行，有一種隱患就是老舊的伺服器還是有潛在的風險，如果出現了宕機，那大家可就慌亂了，緊急處理思路就是做Failover，然後在備庫端繼續嘗試匯出，如果點更背，還是出現故障，還有異地備庫2 ，再次做Failover，這種情況下就趕緊收手，安排下次的遷移了。當然我說的可能是微乎其微的機率，但是這些可能你如果認真想過，就算出了問題也會臨危不太亂。

5.當然對於監控來說，有一個好處是可以統一在Linux下監控了，在Solaris下還總是有一些擔心，所以只開啟了Orabbix監控。

最後就是認真細心的處理各種可能發生的問題，統籌帷幄，一切盡在掌握之中。

Datapump資料移轉前的準備工作 

Datapump資料移轉的實踐總結