為響應(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。




