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

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

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

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

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

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

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

我們創建兩張表，執行一條帶or的表連接條件的查詢，就會發現執行計劃并沒有走HASH JOIN，而是使用了NESTED LOOP。

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

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

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

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

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