如果有一套環境，業務優先級很高，伺服器的服役時間比我工作時間都長，現在需要遷移到X86平台，而且經過評估，如果能夠更新資料庫的軟體版本，可以使用到更多的特性和功能。這套環境的資料量大概是800G,停機維護時間在2個小時的樣子，對于很多公司來說，盡可能縮短維護視窗時間，提前起服就意味着有更多的收入，是以2個小時如果能夠再縮短一些的話，就太好了，這樣一個需求該怎麼辦?
這裡我刻意可以弱化了資料庫類型，其實這個需求具有一定的普适性，都可以參考借鑒。
而另一方面，我暫且按照Oracle為例來說明，過于籠統，可操作性，實踐性不強，實際意義會打折扣。
這個需求是一個硬骨頭，前前後後幾代DBA也是前仆後繼，總算到了非遷不可的地步了。而且因為環境的限制，有一些硬傷，比如主庫承擔不了太大的壓力，網絡條件不佳等。是以事兒真不好做，方案也不好來定。
這裡我建議大家先熟悉一下整個資料庫的情況，資料的分布情況之後再結合一些可行方案來得到一個最合适的方案。
在梳理了初步的方案之後，在這個基礎上再細化了資料的分布情況，我想到了一種相對可控的方案。
這個庫磁盤空間占用有800G,但是不是800G的純資料，還有相當一部分是索引的消耗，經過分析，這個環境90%的資料在屬主使用者上，而索引占據了近40%的空間，這樣一來實際的資料空間也就在50%左右，最後的10%的資料是一些資料字典資訊，補充輔助的一些資料資訊。
是以這樣一來我們可以把資料分為三類，然後給出相應的解決方案：
索引段資料，索引段的資料其實可以提前進行準備，能夠大大減少遷移過程中的資源消耗，整個過程中不需要同步，自适應即可。
資料字典和其它資訊，這部分資料都是資料字典，權限資訊，少量的輔助資料等，經過評估這部分資料一次同步後，就不需要反複同步了。
資料段，這部分資料占用空間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%的資料重新同步即可。