某部委人士指出：“OceanBase測試指標雖高，但在關鍵領域仍不能使用”、“互聯網和銀行場景完全不同”、“不能支持跑批”。
OceanBase完全不兼容Oracle，分佈式數據庫性能尚待證明。結構上更像是一個數據庫存儲而非完整數據庫，替換Oracle缺乏理論支撐和實踐證明。
為什麼說OceanBase在關鍵領域不可能替代Oracle
2019年10月9日，某部委人士在公開會議上指出，“OceanBase測試指標雖高，但在關鍵領域仍不能使用”、“互聯網和銀行場景完全不同”、“不能支持跑批（批處理業務）”。問題本質是“什麼樣的分佈式數據庫在關鍵領域可用”？
從用戶的角度，答案很明確，兼容Oracle功能且滿足性能要求。兼容Oracle，意味著“不改造應用系統無縫升級模式”，用戶責任小，風險低。滿足性能要求，意味著業務可運行。
那OceanBase是不是這樣一個產品呢？
先說Oracle的兼容性：
數據庫核心功能，OceanBase在分佈式架構下，不兼容Oracle的存儲過程、觸發器、視圖、多表關聯、大表關聯等常用數據庫核心功能，需要通過大規模改造應用系統來彌補功能缺口，工程繁複，且不保證改造一定成功；
隔離等級，OceanBase不支持Oracle的隔離等級“可重複讀”，存在不可知數據錯誤風險及高失敗率；
鎖機制，和Oracle嚴苛鎖機制相比，OceanBase是鬆散鎖機制，在有數據衝突的金融場景，必然導致跑批（批處理業務）中斷，存在業務連續性風險；
結論：OceanBase完全不兼容Oracle，其缺口源於結構性差異，不可能通過適配解決。
再說性能，分佈式數據庫性能的關鍵是處理分佈式事務的效率：
兩次tpc-c測試，分佈式事務均不是由OceanBase數據庫完成的。按tpc-c規則，存在隨機15%和1%跨倉交易，如果完全隨機，總交易量的6.896%，即8小時共有520.017798億個交易，成為跨數據庫節點的分佈式事務。螞蟻金服披露“OceanBase1557節點集群時，壓測tpmC/理論tpmC=0.987”，集群與單機相比性能0損耗，即分佈式架構卻完全沒有分佈式開銷，顯然tpc-c測試裡的分佈式事務不是由OceanBase數據庫節點完成的。
2019年6月，中國信通院和中國軟件評測中心搞過一次分佈式數據庫的公開摸底考試，不允許大規模修改應用系統，OceanBase性能不佳，沒有進入複試。
支付寶場景，有專業人士認為：“網絡支付場景，更多是連接，而資金的清算早期在商業銀行，現在在人行網聯平臺，而非支付公司。相反，說明銀行的核心繫統大有進步。”支付場景與金融場景差異明顯，OceanBase分佈式事務能力仍需證明。
OceanBase多個外部測試場景，目前均未見到OceanBase單獨完成分佈式事務，更多是由應用系統分擔，OceanBase作為數據存儲。
高斯分佈式數據庫與OceanBase同屬一類，實戰效果不佳，已下架。
小結：沒有直接證據證明OceanBase分佈式事務處理性能。
綜上所述，OceanBase完全不兼容Oracle，分佈式數據庫性能尚待證明。結構上更像是一個數據庫存儲而非完整數據庫，就像沒有發動機的裸底盤，替換高端整車Oracle缺乏理論支撐和實踐證明。
以上觀點均可快速驗證，當眾遷移一簡單Oracle系統即可，如某標準OA。
