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的埠訪問許可權,使用下面的方式在記憶體中和檔案中都做配置
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監控。
最後就是認真細心的處理各種可能發生的問題,統籌帷幄,一切盡在掌握之中。
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監控。
最後就是認真細心的處理各種可能發生的問題,統籌帷幄,一切盡在掌握之中。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-2121983/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Datapump資料遷移前的準備工作
- 【DATAPUMP】使用DataPump遷移Oracle資料庫Oracle資料庫
- 資料遷移前的準備和系統檢查
- 資料遷移工作技術準備
- Datapump資料遷移的實踐總結
- Oracle資料庫升級前必要的準備工作Oracle資料庫
- 海量資料遷移之sqlldr和datapump的缺點分析SQL
- 構建大資料平臺(二)準備工作大資料
- MySQL 資料遷移Oracle工作MySqlOracle
- 【Datapump】Oracle資料泵遷移資料命令參考(expdp/impdp說明)Oracle
- 資料庫的冷備份遷移資料庫
- 主備切換的準備工作(二)
- 小程式開發前的準備工作
- 網站進行伺服器遷移前應做好哪些準備?網站伺服器
- 不同的default tablespace資料遷移(二)
- oracle 資料庫安裝前環境檢查和準備工作Oracle資料庫
- SAP資料遷移規劃:準備、工具和合作夥伴是關鍵
- 工作日誌,多租戶模式下的資料備份和遷移模式
- dataguard備庫的資料檔案的遷移
- PHP 使用 Oracle 資料庫的準備工作PHPOracle資料庫
- websocket 二進位制資料傳輸基礎準備工作Web
- 檢測資料庫遷移準確性資料庫
- datapump跨平臺升級遷移的總結
- 【資料遷移】RMAN遷移資料庫到ASM(二)切換資料檔案到ASM資料庫ASM
- OGG資料庫遷移方案(二)資料庫
- 資料的遷移
- 演算法與資料結構系列 ( 二 ) - 實現前的基礎準備演算法資料結構
- mysql 備份與遷移 資料同步方法MySql
- MongoDB 資料遷移 備份 匯入(自用)MongoDB
- Cacti資料備份與遷移 (轉載)
- LoadRunner:壓力測試前的分析準備工作
- dataguard備庫的資料檔案的遷移實戰
- 【手摸手玩轉 OceanBase 174】恢復前準備準備工作有哪些?
- 遷移資料.
- 瞄準大資料遷移三大方法,掌握資料權大資料
- GoldenGate資料遷移的問題總結(二)Go
- 【遷移】使用rman遷移資料庫資料庫
- mongodb資料庫備份與恢復(資料庫資料遷移)MongoDB資料庫