最近涉及信創(chuàng)的事情比較多，很多朋友也和我討論信創(chuàng)數(shù)據(jù)庫改造時應該注意一些什么問題。實際上最終涉及的問題包含兩方面，一方面是選型，一方面是遷移。從Oracle向國產(chǎn)、開源數(shù)據(jù)庫做數(shù)據(jù)遷移目前實際上是比較成熟的，有大量的工具可用。當然對于大數(shù)據(jù)量的業(yè)務遷移還是有一些工作量的，不過都還是可以克服。

實際上目前我們遇到的第一大難題就是選擇的問題，國產(chǎn)數(shù)據(jù)庫太多了，怎么選都眼花。實際上可能很多數(shù)據(jù)庫選型都有些走偏，大家過多的去關注TPCC、TPCH這些很可能對實際選型沒太大影響的測試。每個數(shù)據(jù)庫廠商都會對這些基準測試做很好的優(yōu)化，因此從這些測試中實際上也獲取不到很多有價值的數(shù)據(jù)。

實際上選擇數(shù)據(jù)庫的時候，我們還是要從遷移成本、使用成本、復雜業(yè)務支撐能力等方面入手。實際上最需要測試的第一方面就是與Oracle的兼容性，因為我們大多數(shù)都是要把系統(tǒng)從Oracle上遷移下來，與Oracle的兼容性越好，就意味著遷移成本越低。兼容性測試只要集中在一些SQL的特殊語法、窗口/統(tǒng)計函數(shù)、常用函數(shù)、SEQUENCE、PL/SQL存儲過程等方面。

除了兼容性外，第二重要的因素是高可用，高可用是確保業(yè)務SLA的關鍵，高可用切換方案是否能夠滿足業(yè)務SLA的需求，切換是否能夠自動化，切換時是否順暢，這些都是需要認真測試的。而且這種測試往往需要帶一定負載，甚至帶高負載進行。

第三個重要特性是備份與恢復，雖然所有數(shù)據(jù)庫都支持備份與恢復，不過其能力差異很大。備份恢復操作是否順暢，與磁帶庫、虛擬帶庫之間的兼容性，與常用備份工具平臺的兼容性等都是需要考慮的因素。另外就是備份恢復的粒度，是否支持表級甚至塊級恢復也是十分關鍵的考慮因素。

可靠性測試是不容易做的，這需要做耐力測試，要想在有限的時間內(nèi)從耐力測試中發(fā)現(xiàn)問題，對于測試用例有極高的要求。

除此之外，我們還要十分關注一些CBO優(yōu)化器方面的問題。原生的PG數(shù)據(jù)庫與Oracle在HASH JOIN等高級表連接上面是有一些差異的。雖然說PG也支持HASH JOIN，不過在有些場景下，PG的HASH JOIN支持并不完善。比如下面的場景：

我們創(chuàng)建兩張表，執(zhí)行一條帶or的表連接條件的查詢，就會發(fā)現(xiàn)執(zhí)行計劃并沒有走HASH JOIN，而是使用了NESTED LOOP。

而如果我們把Or的表連接條件去掉，則又走回了HASH JOIN這種性能比較好的連接方式。當表的數(shù)據(jù)量很大時這兩種連接的性能差異很大。

我們把這個測試用例用到基于PG的一些國產(chǎn)數(shù)據(jù)庫上，得到的結果是類似的。比如在openGauss v3上，我們獲得了相類似的結果。

如果我們的應用中有這樣的SQL，那么怎么辦呢？只能改寫，將這些SQL拆分或者用UNION語句來改寫。我手頭正好有一套OB4.0的環(huán)境，測試一下，執(zhí)行計劃是這樣的：

OB在CBO優(yōu)化器里自動對這樣的SQL進行了改寫，在執(zhí)行計劃里看到了UNION的操作。

類似這樣的問題在國產(chǎn)數(shù)據(jù)庫中還有很多，因此在做選擇的時候，最好能夠把自己的ERP,SCM，倉儲，財務等系統(tǒng)中相對比較復雜，數(shù)據(jù)量較大的SQL抽取一些出來，在待選產(chǎn)品上做一些測試，可能能夠比對出更有價值的數(shù)據(jù)出來。