一個跨平臺資料遷移的方案優化

   如果有一套環境，業務優先順序很高，伺服器的服役時間比我工作時間都長，現在需要遷移到X86平臺，而且經過評估，如果能夠升級資料庫的軟體版本，可以使用到更多的特性和功能。這套環境的資料量大概是800G,停機維護時間在2個小時的樣子，對於很多公司來說，儘可能縮短維護視窗時間，提前起服就意味著有更多的收入，所以2個小時如果能夠再縮短一些的話，就太好了，這樣一個需求該怎麼辦?

  這裡我刻意可以弱化了資料庫型別，其實這個需求具有一定的普適性，都可以參考借鑑。

   而另一方面，我暫且按照Oracle為例來說明，過於籠統，可操作性，實踐性不強，實際意義會打折扣。

   這個需求是一個硬骨頭，前前後後幾代DBA也是前仆後繼，總算到了非遷不可的地步了。而且因為環境的限制，有一些硬傷，比如主庫承擔不了太大的壓力，網路條件不佳等。所以事兒真不好做，方案也不好來定。

    這裡我建議大家先熟悉一下整個資料庫的情況，資料的分佈情況之後再結合一些可行方案來得到一個最合適的方案。

    在梳理了初步的方案之後，在這個基礎上再細化了資料的分佈情況，我想到了一種相對可控的方案。

   這個庫磁碟空間佔用有800G,但是不是800G的純資料，還有相當一部分是索引的消耗，經過分析，這個環境90%的資料在屬主使用者上，而索引佔據了近40%的空間，這樣一來實際的資料空間也就在50%左右，最後的10%的資料是一些資料字典資訊，補充輔助的一些資料資訊。

所以這樣一來我們可以把資料分為三類，然後給出相應的解決方案：

1. 索引段資料，索引段的資料其實可以提前進行準備，能夠大大減少遷移過程中的資源消耗，整個過程中不需要同步，自適應即可。

2. 資料字典和其它資訊，這部分資料都是資料字典，許可權資訊，少量的輔助資料等，經過評估這部分資料一次同步後，就不需要反覆同步了。

3. 資料段，這部分資料佔用空間400G左右,這個是遷移的關鍵所在。這個資料顯然是需要持續同步的。

這樣一來800G的遷移我們可以先簡化到400G的規格，聽起來難度降低了一半。

     我們再來看看這400G資料的情況，大部分的資料都集中在了20個大表裡面，佔用的空間遠超95%以上。而一些基礎的表資料大概只佔用了5%的比例。

   通過這些資訊，我們可以設想400G的資料遷移，大部分資料在20個表裡面，那這個事情可不可以這麼做：

   20個大表的資料通過持續的同步來滿足，而其他表的資料則不需要持續同步，在遷移的時候直接匯出匯入即可。

   而且更關鍵的是20個表裡面，70%的資料集中在了3個表上，剩下的30%的資訊集中在了17個表上。

   我們可以做成彈性的方案，比如使用Oracle的物化檢視prebuilt屬性，因為涉及的表很少，直接物化檢視增量重新整理即可。

   而3個大表的資料量實在太大，這部分資訊就可以通過OGG來邏輯同步。

  有的同學可能會問都用物化檢視增量重新整理得了，這樣一來3個大表的資料同步，資料庫層面沒有可以設定的閾值，控制措施，比如限定流量情況等。所以3個大表是不建議物化檢視增量重新整理來操作的。

   而那17個表相對來說資料量較大，幾百MB其實還可以接受的，使用增量重新整理就可以。

  或者有的同學說，乾脆都使用OGG同步得了，這個在目前的考慮方案中也是可行的。無非就是基礎的配置上需要提前準備除錯。

   遮掩下來，整個的資料遷移其實絕大部分工作都可以提前安排好，到了遷移的時候，只是把5%的資料重新同步即可。

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