OpenGauss 510與Oracle的兼容性如何？你試過了嗎？
目前使用openGauss或者基于openGauss的國產(chǎn)數(shù)據(jù)庫的客戶已經(jīng)不少了，當(dāng)我們要把一套數(shù)據(jù)庫從Oracle遷移到openGauss的時(shí)候，首先我們要關(guān)注的是openGauss與Oracle的兼容性如何。一些基于openGauss的商用數(shù)據(jù)庫在兼容性方面做了一定的增強(qiáng)，有些號(hào)稱兼容性已經(jīng)超過90%，不過我沒有親身體驗(yàn)過，不知道是否屬實(shí)。對于openGauss 5.10，大致的 兼容度評估如下表：
編號(hào) | 特性名稱 | 兼容 | 不兼容 | 總數(shù) | 百分比 |
1 | DCL關(guān)鍵特性 | 48 | 374 | 422 | 11.37% |
2 | DDL關(guān)鍵特性 | 84 | 288 | 372 | 22.58% |
3 | DML關(guān)鍵特性 | 257 | 114 | 371 | 69.27% |
4 | PLSQL關(guān)鍵特性 | 70 | 21 | 91 | 76.92% |
5 | 操作符 | 38 | 0 | 38 | 100% |
6 | 數(shù)據(jù)類型 | 26 | 15 | 41 | 63.41% |
7 | 系統(tǒng)高級包 | 2 | 143 | 145 | 1.3793% |
8 | 系統(tǒng)函數(shù) | 282 | 434 | 716 | 39.38% |
9 | 系統(tǒng)視圖 | 1 | 126 | 127 | 0.78% |
匯總 | 808 | 1515 | 2323 | 34.78% |
其中操作符的兼容性是100%，其他的兼容性都還有一定的差距。DML兼容性接近70%，PL/SQL的語法兼容性接近80%，從這兩個(gè)指標(biāo)上看，應(yīng)用遷移難度也不算太大，但是想要平替是不大可能的。數(shù)據(jù)類型的兼容度只有63.41%，這是個(gè)比較麻煩的事情。
一級分類 | 二級分類 | 三級分類 | 四級分類 | 5.0.1 | 5.1.0 |
數(shù)據(jù)類型 | 字符型 | VARCHAR2(size [BYTE | CHAR]) | VARCHAR2(size CHAR) | 不兼容 | 不兼容 |
數(shù)據(jù)類型 | 字符型 | VARCHAR2(size [BYTE | CHAR]) | VARCHAR2(size BYTE) | 不兼容 | 不兼容 |
數(shù)據(jù)類型 | 字符型 | LONG | 不兼容 | 不兼容 | |
數(shù)據(jù)類型 | 字符型 | CHAR [(size [BYTE | CHAR])] | CHAR(size CHAR) | 不兼容 | 不兼容 |
數(shù)據(jù)類型 | 字符型 | CHAR [(size [BYTE | CHAR])] | CHAR(size BYTE) | 不兼容 | 不兼容 |
數(shù)據(jù)類型 | 字符型 | NCHAR[(size) [BYTE | CHAR]] | NCHAR(size CHAR) | 不兼容 | 不兼容 |
數(shù)據(jù)類型 | 字符型 | NCHAR[(size) [BYTE | CHAR]] | NCHAR(size BYTE) | 不兼容 | 不兼容 |
數(shù)據(jù)類型 | 數(shù)值型 | BINARY_FLOAT | 不兼容 | 不兼容 | |
數(shù)據(jù)類型 | 時(shí)間型 | TIMESTAMP [(fractional_seconds_precision)] WITH LOCAL TIME ZONE | 不兼容 | 不兼容 | |
數(shù)據(jù)類型 | JSON類型 | JSON | 不兼容 | 不兼容 | |
數(shù)據(jù)類型 | 二進(jìn)制型 | LONG RAW | 不兼容 | 不兼容 | |
數(shù)據(jù)類型 | 排序/偽列 | ROWID | 不兼容 | 不兼容 | |
數(shù)據(jù)類型 | 排序/偽列 | UROWID [(size)] | 不兼容 | 不兼容 | |
數(shù)據(jù)類型 | NCLOB型 | NCLOB | 不兼容 | 不兼容 | |
數(shù)據(jù)類型 | 二進(jìn)制文件 | BFILE | 不兼容 | 不兼容 | |
不過幸運(yùn)的是，這些不兼容的數(shù)據(jù)類型在國內(nèi)的應(yīng)用中使用較少。NCHAR/NCLOB可以通過轉(zhuǎn)換工具進(jìn)行轉(zhuǎn)碼，LONG/LONG RAW自從LOB出現(xiàn)后也很少被使用了，如果還有少量使用，可以通過工具轉(zhuǎn)為LOB字段即可。ROWID在早期的一些應(yīng)用中，為了優(yōu)化性能被使用得還是挺多的，這方面的應(yīng)用只能重新尋找新的優(yōu)化方案了。TIMESTAMP是比較容易被忽視的問題，因?yàn)榫鹊膯栴}，某些應(yīng)用在遷移后，需要對這方面的功能進(jìn)行校驗(yàn)。BFILE雖然用得不是很多，不過我還是見過一些的，一些10年以上的老系統(tǒng)，為了讓一些只讀的的大對象不影響數(shù)據(jù)庫性能，使用了BFILE。這方面的應(yīng)用改造還是有點(diǎn)工作量的。
系統(tǒng)視圖的兼容度最低，不過這方面想要改善比較容易。系統(tǒng)高級包的兼容度也比較低，如果應(yīng)用中對Oracle的高級包有重度依賴，那么遷移改造 工作量還是很大的。從總體上來看，openGauss 5.1.0在Oracle兼容性方面的提升比較慢，相比5.0.1的總體兼容度34%出頭，相差并不大，只是在系統(tǒng)兼容包方面有了小的提升。看樣子openGauss是把與Oracle的兼容性都留給了生態(tài)商用產(chǎn)品了。
今天簡單給大家分享了一下openGauss與Oracle的兼容性的一些統(tǒng)計(jì)數(shù)據(jù)。總體上來說，從Oracle向openGauss遷移還是可行的，不過對于大多數(shù)應(yīng)用來說，不可能簡單平替。當(dāng)然，基于openGauss的商用產(chǎn)品在這方面會(huì)做得更好，愿意掏銀子的用戶，選著海量Vastbase G100、恩墨MogDB、南大通用Gbase 8C等基于openGauss的商用數(shù)據(jù)庫，遷移難度會(huì)略低一些。其中Gbase 8C不光有集中式版本，還有類似于GaussDB的分布式版本。
