面對互聯(lián)網(wǎng)業(yè)務的不斷深化以及業(yè)務量的爆發(fā)式增長，傳統(tǒng)數(shù)據(jù)庫架構迎來了前所未有的挑戰(zhàn)和變革。在傳統(tǒng)數(shù)據(jù)庫領域，Oracle一直占據(jù)了很大的市場份額，很多企業(yè)的業(yè)務系統(tǒng)基于此實現(xiàn)OLTP交易場景。近年來，隨著分布式技術的發(fā)展，分布式數(shù)據(jù)庫逐漸占據(jù)了OLTP領域較大的市場，尤其在互聯(lián)網(wǎng)領域，MYSQL、PG等分布式數(shù)據(jù)庫的應用非常廣泛。隨著軟件國產(chǎn)化、自主可控戰(zhàn)略的提出，去“Oracle”逐漸被提上日程，非互聯(lián)網(wǎng)企業(yè)也開始考慮數(shù)據(jù)庫轉型，其中，分布式數(shù)據(jù)庫即是一個重要轉型方向。

不同于Oracle數(shù)據(jù)庫的集中式、主從式架構，分布式數(shù)據(jù)庫將位于不同地點的多個服務器通過網(wǎng)絡互相連接，共同組成一個完整的、全局的大型數(shù)據(jù)庫，它在邏輯上集中、物理上分布；在數(shù)據(jù)存儲上，分布式數(shù)據(jù)庫將數(shù)據(jù)打散存儲在不同服務器上，故而將數(shù)據(jù)庫壓力分散到不同服務器上。故而使得分布式數(shù)據(jù)庫具備了可擴展性、高并發(fā)性、高可用性等特點。

很多企業(yè)原本都是傳統(tǒng)數(shù)據(jù)庫一體化解決方案，在進行Oracle向分布式數(shù)據(jù)庫遷移時會遇到很多難點，傳統(tǒng)數(shù)據(jù)庫設計與運維經(jīng)驗不一定完全適合分布式數(shù)據(jù)庫。那么，從Oracle遷移至MYSQL、PG等分布式數(shù)據(jù)庫會遇到哪些障礙？這些障礙是否能順利解決？

（1）不同數(shù)據(jù)庫之間的異構數(shù)據(jù)如何做到無損遷移？Oracle存量數(shù)據(jù)如何成功遷移至MYSQL、PG等分布式數(shù)據(jù)庫？

（2）Oracle數(shù)據(jù)庫遷移至MYSQL、PG等分布式數(shù)據(jù)庫過程中如何保障系統(tǒng)穩(wěn)定性？如何設置異構數(shù)據(jù)庫并行過渡期？

（3）Oracle數(shù)據(jù)庫往往和應用耦合度較高，遷移過程還會涉及到應用遷移和改造，特別是存儲過程、觸發(fā)器、自定義函數(shù)等方面的改造，將業(yè)務邏輯實現(xiàn)方從數(shù)據(jù)庫上移至應用，那么如何評估改造量和改造難度？兼容性如何保障？

（4）數(shù)據(jù)庫遷移完成后如何成功建轉運？或者說，在數(shù)據(jù)庫設計階段如何設計運維方案？除了分布式數(shù)據(jù)庫的高可用、負載均衡設計，傳統(tǒng)運維方案中的網(wǎng)絡、存儲、監(jiān)控告警、備份恢復等等應該如何規(guī)劃？