為響應(yīng)公司擁抱云原生去Oracle戰(zhàn)略方向，從今年7月份開(kāi)始，我們已經(jīng)開(kāi)始了各種調(diào)研。

先聊聊待遷移的系統(tǒng)

我們拿公司內(nèi)部核心營(yíng)銷(xiāo)系統(tǒng)（下稱(chēng)“營(yíng)銷(xiāo)云”）作為試點(diǎn)，營(yíng)銷(xiāo)云最早要追溯到2014年，當(dāng)年公司購(gòu)買(mǎi)了Oracle的Siebel系統(tǒng)，

基于Siebel開(kāi)發(fā)了配套的營(yíng)銷(xiāo)系統(tǒng)，囊括公司銷(xiāo)售渠道，銷(xiāo)售訂單等等功能。這是營(yíng)銷(xiāo)云的前身。因?yàn)镾iebel本身比較重量級(jí)，每次營(yíng)銷(xiāo)云有功能擴(kuò)展都需要?jiǎng)拥絊iebel，

所以后面營(yíng)銷(xiāo)云逐步改造脫離Siebel，直到2019年完成全部功能脫離，但是用的還是Siebel的數(shù)據(jù)庫(kù)。目前現(xiàn)狀仍然是單體應(yīng)用。

隨著業(yè)務(wù)的發(fā)展，目前營(yíng)銷(xiāo)云已經(jīng)有上千個(gè)頁(yè)面。業(yè)務(wù)功能復(fù)雜，與集團(tuán)其他應(yīng)用系統(tǒng)有深度的集成。這大大提高了我們更換數(shù)據(jù)庫(kù)的難度。

系統(tǒng)是以SAAS的形式為全國(guó)各地經(jīng)銷(xiāo)商服務(wù)。為了不影響業(yè)務(wù)，我們一開(kāi)始定的基調(diào)是，不能大范圍修改代碼以及原有sql語(yǔ)句。

一開(kāi)始我們找到了PolarDb，polarDb可以兼容oracle語(yǔ)法。無(wú)奈我們?cè)谧稣{(diào)研驗(yàn)證的時(shí)候，卡在了數(shù)據(jù)遷移這步。剛好這時(shí)我們又找到了OceanBase，由此開(kāi)始了

OceanBase的嘗試。

兼容性驗(yàn)證

OceanBase號(hào)稱(chēng)可以兼容90%以上Oracle常用語(yǔ)法以及存儲(chǔ)過(guò)程等等，從Oracle遷移到OB可以無(wú)縫或少量修改即可。這正好滿(mǎn)足我們的要求，我們馬上開(kāi)始了驗(yàn)證階段。

我們首先使用了OB團(tuán)隊(duì)提供的工具進(jìn)行Oracle版本兼容性的校驗(yàn)，校驗(yàn)結(jié)果是100%兼容。

數(shù)據(jù)遷移驗(yàn)證

我們馬上進(jìn)行了數(shù)據(jù)遷移的驗(yàn)證。為了模擬真實(shí)的情況，我們直接拿生產(chǎn)環(huán)境的Oracle庫(kù)來(lái)遷移。去除Oracle本身的日志，整個(gè)庫(kù)的數(shù)據(jù)量大小是20-30G，涉及數(shù)據(jù)庫(kù)對(duì)象467個(gè)（表+視圖）

數(shù)據(jù)怎么遷移，我們遇到三個(gè)難點(diǎn)。

1、營(yíng)銷(xiāo)云應(yīng)用以及Oracle都部署在廣州的私有云，OB那時(shí)在華南還沒(méi)開(kāi)站點(diǎn)，我們不希望應(yīng)用在廣州，庫(kù)在華東

2、我們服務(wù)不能停太久，必須要盡可能縮短遷移時(shí)間，留足夠時(shí)間驗(yàn)證生產(chǎn)問(wèn)題

3、如何從私有云Oracle傳輸?shù)絆B。

我們的解決方案：

經(jīng)過(guò)跟OB團(tuán)隊(duì)的深入交流，他們把原計(jì)劃在12月在華南開(kāi)站的工作提前到9月來(lái)做了。所以接下來(lái)是數(shù)據(jù)傳輸?shù)膯?wèn)題了。

我們首先從阿里云上申請(qǐng)一臺(tái)服務(wù)器安裝跟生產(chǎn)環(huán)境同版本的Oracle, 從生產(chǎn)環(huán)境Oracle導(dǎo)出數(shù)據(jù)，通過(guò)拉專(zhuān)線的方式把數(shù)據(jù)傳輸?shù)桨⒗镌品?wù)器，再把數(shù)據(jù)導(dǎo)入到服務(wù)器上的Oracle里面。

最后通過(guò)OB提供的OMS工具遷移阿里云Oracle的數(shù)據(jù)至OB。整個(gè)遷移過(guò)程耗時(shí)在3-4小時(shí)，這個(gè)是我們能接受的。

OMS工具遷移分兩步，先遷移結(jié)構(gòu)，再遷移數(shù)據(jù)。在遷移結(jié)構(gòu)的時(shí)候，遇到個(gè)別表結(jié)構(gòu)校驗(yàn)的警告信息，我們忽略繼續(xù)遷移，但沒(méi)有對(duì)后續(xù)數(shù)據(jù)遷移造成影響。

遷移后應(yīng)用驗(yàn)證

到此，數(shù)據(jù)庫(kù)已成功遷移至OB。接下來(lái)是營(yíng)銷(xiāo)云應(yīng)用的改造。我們的改造基本上就是引入OB的jdbc驅(qū)動(dòng)包，以及修改數(shù)據(jù)庫(kù)連接。

抽取了一個(gè)相對(duì)復(fù)雜的業(yè)務(wù)功能做驗(yàn)證。主要驗(yàn)證 ：

1、sql語(yǔ)法兼容性

2、查詢(xún)耗時(shí)

得出結(jié)論：

1、sql語(yǔ)法支持絕大部分，包括常用的Oracle函數(shù)。

2、性能問(wèn)題，開(kāi)始的時(shí)候明顯感覺(jué)比原來(lái)用Oracle的時(shí)候響應(yīng)慢了不少。個(gè)別語(yǔ)句直接報(bào)查詢(xún)超時(shí)。經(jīng)OB團(tuán)隊(duì)的協(xié)助，定位出我們的表沒(méi)有在關(guān)鍵字段創(chuàng)建索引，把索引建好后查詢(xún)響應(yīng)跟原Oracle相當(dāng)。在得知這個(gè)問(wèn)題之后，筆者在OB后臺(tái)拉出所有慢SQL，都做了一遍索引優(yōu)化。

這里拋個(gè)問(wèn)題，原Oracle相同的表也是沒(méi)有建索引的，但在用Oracle的時(shí)候沒(méi)有表現(xiàn)出性能問(wèn)題。后來(lái)筆者在Oracle上也建上相同的索引，Oracle的查詢(xún)性能再次提高，但是總體差別不大。（本來(lái)就已經(jīng)是幾十毫秒耗時(shí)）

后續(xù)

陣痛了半個(gè)月之后，目前營(yíng)銷(xiāo)云已經(jīng)在穩(wěn)定運(yùn)行。

筆者在日常操作OB的過(guò)程中，總結(jié)了如下幾點(diǎn)OB需要優(yōu)化的地方

1、merge語(yǔ)句的using 子語(yǔ)句只支持單表，不支持復(fù)雜查詢(xún)。

2、dblink暫時(shí)還不支持 OB連Oracle（OB團(tuán)隊(duì)說(shuō)3.0版本會(huì)支持）

3、批量提交的數(shù)據(jù)量大小目前限制死100M。原來(lái)用Oracle可以正常執(zhí)行的語(yǔ)句，例如merge,  insert select ，create table select，等等語(yǔ)句，遇到數(shù)據(jù)量大的時(shí)候會(huì)直接報(bào)錯(cuò)

4、管理后臺(tái)做的略為粗糙了一點(diǎn)，例如在查看慢SQL的時(shí)候，個(gè)別sql比較長(zhǎng)，頁(yè)面直接就截?cái)嗔耍瑹o(wú)法得知完整sql語(yǔ)句。截止到筆者寫(xiě)這篇文章的時(shí)候，這問(wèn)題還沒(méi)修復(fù)

我們此次遷移算是公司的先頭部隊(duì)，后續(xù)其他系統(tǒng)可能也會(huì)做遷移，屆時(shí)會(huì)重點(diǎn)關(guān)注dblink的模塊。因?yàn)槲覀儙讉€(gè)核心系統(tǒng)大量用到dblink。