戰(zhàn)：從工具選型到性能調(diào)優(yōu)的避坑指南)
我這里沒有現(xiàn)成的項(xiàng)目正文、關(guān)鍵詞和摘要可用只能根據(jù)這個(gè)標(biāo)題本身把一線遷移過程中實(shí)際會(huì)遇到的事講清楚。做過多套從國(guó)外商用數(shù)據(jù)庫往國(guó)產(chǎn)數(shù)據(jù)庫遷的活之后最大的感受是遷移本身并不難難的是遷移之前沒人告訴你的那些隱性成本和看起來能跑但實(shí)際是錯(cuò)的改寫。這篇文章就圍繞工具選型、參數(shù)配置、性能調(diào)優(yōu)三條主線展開我把踩過的坑和修正過程一起寫出來希望能幫后面接手這類活兒的人少走幾趟彎路。1. 遷移前先搞清楚這次遷移真正難在哪很多人拿到遷移任務(wù)后第一反應(yīng)是找工具其實(shí)這是順序錯(cuò)了。工具解決的是怎么搬但真正決定項(xiàng)目成敗的是搬過去能不能跑、跑得對(duì)不對(duì)這屬于兼容性評(píng)估的范疇。我在多個(gè)項(xiàng)目里發(fā)現(xiàn)將近一半的延期和返工都出在遷移前的評(píng)估階段而不是遷移執(zhí)行階段。1.1 兼容性評(píng)估別只測(cè)SQL要連數(shù)據(jù)行為一起測(cè)先說兼容性評(píng)估。很多團(tuán)隊(duì)的做法是拿業(yè)務(wù)SQL清單到目標(biāo)庫上跑一遍能跑通就算兼容跑不通就交給開發(fā)改。這種評(píng)估方式太粗糙了因?yàn)閿?shù)據(jù)庫遷移里最隱蔽的問題根本不是SQL語法而是數(shù)據(jù)行為的差異。舉個(gè)例子Oracle里空字符串和NULL是兩回事你敢寫WHERE col Oracle會(huì)把空串轉(zhuǎn)成NULL所以這個(gè)條件永遠(yuǎn)不成立。KingbaseES早期的兼容模式里不一定保持這個(gè)行為。再比如NUMBER類型在Oracle里可以存整數(shù)也可以存小數(shù)精度范圍極大遷到KingbaseES如果用NUMERIC那問題不大但如果評(píng)估時(shí)沒注意類型映射工具給自動(dòng)映射成了INT那小數(shù)位直接被截?cái)嗌暇€后賬單金額差幾毛錢這種事都能發(fā)生。所以做兼容性評(píng)估時(shí)我建議至少準(zhǔn)備三層檢查語法層現(xiàn)有應(yīng)用里的SQL能不能在目標(biāo)庫跑通工具一般能覆蓋語義層同樣的SQL在兩邊返回結(jié)果是否一致特別是空值、排序、聚合、類型轉(zhuǎn)換這些基礎(chǔ)行為數(shù)據(jù)層存量數(shù)據(jù)里的邊界值、超長(zhǎng)字符串、特殊字符能否無損落庫語義層和數(shù)據(jù)層往往需要編寫專門的對(duì)比腳本把同一批數(shù)據(jù)分別在兩個(gè)庫上跑同一套查詢邏輯然后做結(jié)果集比對(duì)。這個(gè)環(huán)節(jié)不要偷懶也不要只看抽樣結(jié)果能全量比對(duì)就全量比對(duì)。1.2 盤點(diǎn)對(duì)象時(shí)最容易漏掉的那幾類對(duì)象盤點(diǎn)也是遷移前的重要環(huán)節(jié)。建表結(jié)構(gòu)、索引、視圖這些大家基本不會(huì)漏容易漏的是以下幾類序列Oracle應(yīng)用里SEQ.NEXTVAL隨處可見遷到KingbaseES如果不處理序列應(yīng)用一跑就直接報(bào)錯(cuò)觸發(fā)器用于審計(jì)、默認(rèn)值填充、級(jí)聯(lián)操作的觸發(fā)器遷移時(shí)常常被忽略導(dǎo)致業(yè)務(wù)邏輯靜默缺失包和存儲(chǔ)過程Oracle的PL/SQL包里有變量、游標(biāo)、異常處理KingbaseES的兼容模式能處理一部分但復(fù)雜包經(jīng)常需要手工改寫物化視圖及其刷新機(jī)制如果源端有物化視圖并且業(yè)務(wù)依賴定期刷新目標(biāo)端也得有對(duì)應(yīng)的實(shí)現(xiàn)和調(diào)度同義詞很多老系統(tǒng)里同義詞用得很多這也屬于需要顯式遷移的對(duì)象我之前接手過一個(gè)模擬系統(tǒng)光序列就有一百多個(gè)分布在幾十個(gè)表上。遷移工具自動(dòng)處理了一部分但有幾張表的主鍵用的是TRIGGER SEQUENCE的方式在插入前用觸發(fā)器取序列值工具沒有識(shí)別出這個(gè)模式。結(jié)果數(shù)據(jù)導(dǎo)進(jìn)去之后新插入的記錄主鍵直接沖突調(diào)試了整整一天才定位到是觸發(fā)器少建了幾個(gè)。這種問題在評(píng)估階段如果細(xì)盤對(duì)象是完全可以提前發(fā)現(xiàn)的。1.3 停機(jī)窗口和數(shù)據(jù)量決定遷移策略評(píng)估完兼容性之后就要確定遷移策略。策略主要取決于兩個(gè)因素停機(jī)窗口和數(shù)據(jù)量。停機(jī)窗口很短比如兩小時(shí)以內(nèi)數(shù)據(jù)量又大幾百GB那基本只能靠存量數(shù)據(jù)全量導(dǎo)出導(dǎo)入加增量數(shù)據(jù)同步兩條腿走路。增量同步是技術(shù)難度最高的部分好在KingbaseES在這塊有配套的同步工具可以對(duì)接日志需要提前聯(lián)調(diào)。停機(jī)窗口比較充裕數(shù)據(jù)量也就幾十GB那更簡(jiǎn)單直接停應(yīng)用、導(dǎo)數(shù)據(jù)、校驗(yàn)、啟動(dòng)一條龍下來就完事了。另外還需要考慮網(wǎng)絡(luò)帶寬。源端和目標(biāo)端如果不在同一機(jī)房中間帶寬只有百兆那幾百GB的數(shù)據(jù)怎么壓縮、怎么多線程傳輸都要提前設(shè)計(jì)。千萬別等遷移當(dāng)天再測(cè)網(wǎng)速那是給自己埋雷。2. 工具選型先分清你要的是搬數(shù)據(jù)還是搬業(yè)務(wù)工具選型這塊我的建議是先想清楚一個(gè)核心問題你是要搬數(shù)據(jù)還是搬業(yè)務(wù)這兩個(gè)訴求對(duì)應(yīng)的工具路徑完全不一樣。市面上很多宣傳都說自己能做到一鍵遷移、業(yè)務(wù)無感但實(shí)際用下來能自動(dòng)化處理90%的常規(guī)對(duì)象就已經(jīng)是優(yōu)秀水平剩下10%的硬骨頭基本都得靠人寫腳本硬啃。2.1 數(shù)據(jù)遷移工具怎么選批量數(shù)據(jù)的搬運(yùn)工如果目標(biāo)只是把數(shù)據(jù)從一個(gè)庫搬到另一個(gè)庫那么核心關(guān)注點(diǎn)是這批數(shù)據(jù)有多重、數(shù)據(jù)要不要轉(zhuǎn)換、停在窗口內(nèi)的限制是什么。在真實(shí)項(xiàng)目中我常用的方案分三類通用ETL工具、數(shù)據(jù)庫原生邏輯備份工具、以及數(shù)據(jù)同步類工具。三類工具各有各的適用場(chǎng)景工具類型典型代表優(yōu)點(diǎn)局限性通用ETL/同步框架DataX、Kettle等數(shù)據(jù)源適配廣、可視化、可定制轉(zhuǎn)換邏輯大批量表結(jié)構(gòu)遷移仍需配合DDL轉(zhuǎn)換性能調(diào)參需要細(xì)致數(shù)據(jù)庫原生邏輯導(dǎo)出導(dǎo)入expdp/impdp輔助分析、目標(biāo)庫自帶導(dǎo)出工具、copy命令等類型映射準(zhǔn)確、性能較高、適合同生態(tài)遷移跨庫遷移時(shí)DDL、存儲(chǔ)過程等對(duì)象仍需額外轉(zhuǎn)換數(shù)據(jù)同步工具基于日志的增量同步工具這里指數(shù)據(jù)庫廠商配套的同步組件停機(jī)窗口可以縮到很短、支持增量追平環(huán)境要求較嚴(yán)苛、偶爾有斷點(diǎn)續(xù)傳問題這里我不建議一上來就選最重的同步方案。如果數(shù)據(jù)量不大、窗口夠用全量邏輯導(dǎo)出導(dǎo)入又快又穩(wěn)出問題時(shí)排查鏈路也短。同步工具適合的是那種必須把停機(jī)時(shí)間壓縮到分鐘級(jí)的苛刻場(chǎng)景。2.2 結(jié)構(gòu)遷移工具能幫你生成80%的DDL和PL/SQL結(jié)構(gòu)遷移比數(shù)據(jù)遷移要難得多特別是Oracle里的PL/SQL、包、函數(shù)、視圖、觸發(fā)器。好在絕大多數(shù)國(guó)產(chǎn)庫包括KingbaseES在內(nèi)生態(tài)里都有專門的遷移評(píng)估和轉(zhuǎn)換工具這類工具通常做的事情是掃描Oracle下的全部對(duì)象按類型分類列出自動(dòng)完成一部分DDL和PL/SQL的語法轉(zhuǎn)換輸出轉(zhuǎn)換報(bào)告標(biāo)注哪些對(duì)象轉(zhuǎn)換成功、哪些需要人工處理這類工具輸出的轉(zhuǎn)換成功率有沒有參考價(jià)值有但別全信。我曾經(jīng)在一個(gè)項(xiàng)目上拿一套復(fù)雜的業(yè)務(wù)包做測(cè)試工具報(bào)的轉(zhuǎn)換成功率不到80%剩下的全靠人工補(bǔ)但另一套比較規(guī)范的系統(tǒng)工具幾乎全部自動(dòng)處理完了。所以工具的自動(dòng)化程度和源系統(tǒng)本身的寫法規(guī)不規(guī)范高度相關(guān)。這里有一個(gè)很實(shí)用的經(jīng)驗(yàn)如果在評(píng)估階段發(fā)現(xiàn)源系統(tǒng)里大量使用了一些較為復(fù)雜的高級(jí)特性比如自治事務(wù)、動(dòng)態(tài)SQL、帶OUT參數(shù)的存儲(chǔ)過程調(diào)用那你基本就要做好人工改造至少兩三周的心理準(zhǔn)備。千萬不要只看工具報(bào)告上的百分比。2.3 人工改造怎么拆解才高效人工改造是最耗時(shí)但也最不可跳過的環(huán)節(jié)。高效拆解的關(guān)鍵是把改造任務(wù)分類按難度排序不要眉毛胡子一把抓。結(jié)合我的實(shí)戰(zhàn)改造清單一般這么拆純語法改寫NVL改COALESCE、SYSDATE改CURRENT_TIMESTAMP、||或CONCAT語義核對(duì)。這類工作量大但機(jī)械適合交給工具批量處理人工抽查驗(yàn)證。邏輯等價(jià)改寫ROWNUM分頁改LIMIT、外連接寫法()改標(biāo)準(zhǔn)LEFT JOIN。這類需要改的人理解兩邊語義差異適合由熟悉SQL的工程師處理逐個(gè)走讀。結(jié)構(gòu)性改造存儲(chǔ)過程里的包狀態(tài)、批量收集、動(dòng)態(tài)SQL重構(gòu)這類往往是性能殺手需要結(jié)合應(yīng)用調(diào)用關(guān)系一起考慮建議由資深工程師負(fù)責(zé)。另外改造時(shí)一定要保留一份源SQL與目標(biāo)SQL對(duì)照清單每條SQL都要能追溯到業(yè)務(wù)含義否則后面聯(lián)調(diào)時(shí)根本沒法定位問題。我見過有些團(tuán)隊(duì)改完就不管了上線后一條SQL結(jié)果不對(duì)找了半天也定位不到是哪個(gè)應(yīng)用觸發(fā)出來的就是吃了沒有對(duì)應(yīng)關(guān)系的虧。3. 參數(shù)配置遷移之前把坑提前踩平參數(shù)配置是避坑指南里的重量級(jí)章節(jié)。很多人覺得參數(shù)配置就是改幾個(gè)內(nèi)存大小但實(shí)際涉及的層面很多從數(shù)據(jù)庫初始化參數(shù)到客戶端連接串再到遷移任務(wù)自身的并發(fā)度每個(gè)參數(shù)都可能成為壓垮駱駝的最后一根稻草。3.1 實(shí)例參數(shù)按目標(biāo)負(fù)載而不是按源庫配置先說數(shù)據(jù)庫實(shí)例參數(shù)。KingbaseES的內(nèi)核與開源數(shù)據(jù)庫生態(tài)有緊密關(guān)系很多經(jīng)典參數(shù)可以借鑒參考但不要照搬Oracle那套思維。常見需要調(diào)整的關(guān)鍵參數(shù)包括shared_buffers共享緩沖區(qū)如果服務(wù)器內(nèi)存充足可以按物理內(nèi)存的約1/4來設(shè)置但要留意操作系統(tǒng)緩存配合。設(shè)置太小熱點(diǎn)數(shù)據(jù)頻繁落盤性能直線下降。work_mem工作內(nèi)存排序、哈希操作會(huì)用到的內(nèi)存。設(shè)置太大會(huì)導(dǎo)致并發(fā)場(chǎng)景下內(nèi)存溢出設(shè)置太小又會(huì)讓排序落盤。建議結(jié)合業(yè)務(wù)實(shí)際并發(fā)量來評(píng)估不要拍腦袋。maintenance_work_mem維護(hù)操作內(nèi)存創(chuàng)建索引、收集統(tǒng)計(jì)信息這類操作使用。這個(gè)參數(shù)在遷移建索引階段影響巨大調(diào)大一些能顯著縮短操作時(shí)間。checkpoint相關(guān)大量數(shù)據(jù)導(dǎo)入時(shí)檢查點(diǎn)觸發(fā)頻繁會(huì)導(dǎo)致落盤抖動(dòng)。適度調(diào)大檢查點(diǎn)間隔和緩沖區(qū)平穩(wěn)完成導(dǎo)入再說。WAL相關(guān)參數(shù)導(dǎo)入場(chǎng)景下可以放松一些持久化策略加快寫入但前提是能接受導(dǎo)入過程中異常斷電可能丟失數(shù)據(jù)的風(fēng)險(xiǎn)。遷移階段可以臨時(shí)調(diào)業(yè)務(wù)上線后要恢復(fù)為穩(wěn)妥配置。還有個(gè)參數(shù)別忽略連接數(shù)上限。遷移時(shí)往往會(huì)有多個(gè)工具和腳本同時(shí)連庫如果連接數(shù)設(shè)得太小很多任務(wù)會(huì)直接連不上看起來像網(wǎng)絡(luò)故障。3.2 連接串和驅(qū)動(dòng)參數(shù)被忽略的隱形因素連接串和驅(qū)動(dòng)這塊很多問題不是參數(shù)本身錯(cuò)了而是版本不匹配導(dǎo)致的行為差異。我們?cè)谶w移時(shí)經(jīng)常遇到這樣的情況JDBC驅(qū)動(dòng)版本過低對(duì)目標(biāo)庫某些類型支持不完整讀出來的字符串長(zhǎng)度不對(duì)或者日期格式解析異常。建議用官方推薦的驅(qū)動(dòng)分支并且讓應(yīng)用和遷移腳本統(tǒng)一驅(qū)動(dòng)管理。prepareThreshold或等價(jià)機(jī)制值得重點(diǎn)關(guān)注。默認(rèn)情況下來自某些驅(qū)動(dòng)的語句在執(zhí)行多次時(shí)會(huì)做服務(wù)端預(yù)編譯好處是性能更好但壞處是如果應(yīng)用里習(xí)慣用字符串拼接SQL的方式服務(wù)端預(yù)編譯空間的占用和解析開銷可能會(huì)成為瓶頸。必要時(shí)需要把預(yù)編譯閾值調(diào)低或關(guān)閉。還有fetchSize抓取行數(shù)。很多做數(shù)據(jù)比對(duì)或大批量導(dǎo)出的腳本默認(rèn)抓取方式會(huì)一次性把結(jié)果集全部拉進(jìn)內(nèi)存數(shù)據(jù)一大就直接內(nèi)存溢出。顯式設(shè)置合理的抓取行數(shù)比如每次抓取1000行能解決很多奇怪的內(nèi)存問題。這一點(diǎn)在從Oracle遷到KingbaseES后尤其明顯因?yàn)閮蛇咈?qū)動(dòng)對(duì)游標(biāo)和結(jié)果集的默認(rèn)處理行為并不一致。3.3 遷移任務(wù)自身的參數(shù)并行度不是越大越好做數(shù)據(jù)導(dǎo)入時(shí)很多人會(huì)犯一個(gè)誤區(qū)并行度拉滿。常見的做法是同時(shí)開幾十個(gè)線程導(dǎo)數(shù)據(jù)結(jié)果目標(biāo)庫的鎖競(jìng)爭(zhēng)、檢查點(diǎn)壓力、日志壓力全部拉滿整體速度反而比8個(gè)線程還慢。我的經(jīng)驗(yàn)是并行度先按CPU核數(shù)的60%-70%起步再觀察監(jiān)控如果IO等待不高、CPU還有余量再逐步加大批量大小單事務(wù)批量行數(shù)以500到2000行為宜太大會(huì)導(dǎo)致內(nèi)存開銷高、回滾段壓力大太小則提交次數(shù)過多日志寫入頻繁導(dǎo)入順序先導(dǎo)父表再導(dǎo)子表或者先禁用約束導(dǎo)完再重建。如果按原樣直接導(dǎo)外鍵約束會(huì)讓導(dǎo)入速度大打折扣另外為遷移準(zhǔn)備的賬號(hào)權(quán)限要給足但又不能超出必要范圍。我遇到過遷移賬號(hào)沒有目標(biāo)庫序列的修改權(quán)限導(dǎo)致自動(dòng)生成序列的起始值不對(duì)導(dǎo)入數(shù)據(jù)后序列又從1開始結(jié)果主鍵沖突。這種小坑調(diào)試起來非常耗神。4. 處理Oracle專有寫法從能跑到跑得對(duì)的距離這一章主要講Oracle里那些特有寫法遷到KingbaseES后容易出現(xiàn)語法不報(bào)錯(cuò)但結(jié)果不對(duì)或語法報(bào)錯(cuò)但不知道換成什么的案例。每一條我都盡量把背景和改寫思路一起講清楚。4.1 dual、sysdate、rownum這些老朋友dual 表。Oracle里SELECT SYSDATE FROM DUAL這類寫法非常普遍。KingbaseES在兼容模式下內(nèi)置了對(duì)dual的支持所以大部分場(chǎng)景直接能跑。但要注意不是所有帶dual的語句都能原樣落地如果語句里用了Oracle特有的函數(shù)問題會(huì)轉(zhuǎn)移到函數(shù)本身。建議評(píng)估階段集中搜索FROM DUAL逐個(gè)確認(rèn)關(guān)聯(lián)的函數(shù)都被目標(biāo)庫支持。SYSDATE。Oracle的SYSDATE精度是秒級(jí)別而KingbaseES推薦用CURRENT_TIMESTAMP也能工作但返回精度更高。數(shù)據(jù)插入時(shí)如果字段是DATE這種精度差異通常不會(huì)造成問題但如果業(yè)務(wù)里做了時(shí)間差運(yùn)算可能在邊界上產(chǎn)生差異。更穩(wěn)妥的方案是統(tǒng)一改成CURRENT_TIMESTAMP并做一輪結(jié)果驗(yàn)證別讓線上出現(xiàn)時(shí)間多了0.001秒這種糾纏不清的case。ROWNUM。ROWNUM在Oracle里既用于分頁也用于限制返回行數(shù)。KingbaseES里常規(guī)替代是LIMIT。這里有一個(gè)最常見的坑Oracle里ROWNUM 1是取第一行但ROWNUM 1是永遠(yuǎn)不返回行有人機(jī)械改成LIMIT 1后把原本想看有沒有數(shù)據(jù)的邏輯變成了取第一行業(yè)務(wù)語義不同。-- Oracle: SELECT * FROM (SELECT * FROM t ORDER BY id DESC) WHERE ROWNUM 10; -- KingbaseES: SELECT * FROM t ORDER BY id DESC LIMIT 10;這類改寫看起來簡(jiǎn)單但漏掉外部嵌套、錯(cuò)寫排序字段的事情時(shí)有發(fā)生一定要用真實(shí)數(shù)據(jù)前后對(duì)比。4.2 序列與自增列不檢查起始值就等于埋雷序列遷移是主鍵沖突的第一大來源。Oracle里序列通常是獨(dú)立對(duì)象應(yīng)用在插入前顯式調(diào)用NEXTVAL。遷到KingbaseES后你面臨兩個(gè)選擇保留獨(dú)立序列對(duì)象改寫調(diào)用方式改成自增列含identity或其他自增機(jī)制然后改造應(yīng)用去掉顯式調(diào)用我個(gè)人的建議如果應(yīng)用里調(diào)用序列的地方非常多改成自增列反而是一項(xiàng)大工程因?yàn)樗胁迦胝Z句都要?jiǎng)?。不如保留序列?duì)象只把調(diào)用方式做適配。但不管選哪種都必須手動(dòng)校準(zhǔn)序列的起始值讓它大于當(dāng)前表里的最大ID。補(bǔ)救辦法是在遷移后執(zhí)行序列設(shè)置類操作。比如SELECT setval(seq_xxx, (SELECT max(id) FROM table_xxx));這個(gè)動(dòng)作一定要寫在遷移步驟清單里而且要放在數(shù)據(jù)導(dǎo)入之后執(zhí)行否則就會(huì)出現(xiàn)數(shù)據(jù)導(dǎo)完了、序列還在原地踏步的悲劇。4.3 空表、LOB、分區(qū)表隱蔽的數(shù)據(jù)完整性殺手空表。Oracle的某些版本里空表在遷移工具掃描時(shí)是不占空間的如果遷移工具依賴數(shù)據(jù)字典里的段信息可能漏掉空表結(jié)構(gòu)。結(jié)果就是表沒建出來業(yè)務(wù)一跑就報(bào)表或視圖不存在。處理方式是遷移前先對(duì)空表做一次建表語句生成確保結(jié)構(gòu)遷移階段全部覆蓋。LOB字段。CLOB、BLOB遷移的常見問題是碎片化、性能差和編碼差異。尤其是超大CLOB如果工具默認(rèn)一次性讀入內(nèi)存極易OOM。建議分批讀取、寫入。分區(qū)表。Oracle的分區(qū)策略多種多樣范圍分區(qū)、列表分區(qū)、哈希分區(qū)都有。KingbaseES支持的分區(qū)種類也很多但映射關(guān)系不是一一對(duì)應(yīng)的。遷移時(shí)要重點(diǎn)檢查分區(qū)鍵類型和邊界值定義避免邊界數(shù)據(jù)進(jìn)入錯(cuò)誤分區(qū)。-- Oracle 范圍分區(qū)示例 CREATE TABLE sale ( id NUMBER, sale_date DATE ) PARTITION BY RANGE (sale_date) ( PARTITION p2023 VALUES LESS THAN (TO_DATE(2024-01-01,YYYY-MM-DD)), PARTITION p2024 VALUES LESS THAN (TO_DATE(2025-01-01,YYYY-MM-DD)) ); -- KingbaseES 適配寫法 CREATE TABLE sale ( id numeric, sale_date date ) PARTITION BY RANGE (sale_date); CREATE TABLE sale_p2023 PARTITION OF sale FOR VALUES FROM (2023-01-01) TO (2024-01-01); CREATE TABLE sale_p2024 PARTITION OF sale FOR VALUES FROM (2024-01-01) TO (2025-01-01);注意邊界語義差異Oracle用LESS THAN分區(qū)的上邊界是不包含的而KingbaseES的分區(qū)范圍寫法默認(rèn)也是上邊界不包含這點(diǎn)還好。但如果分區(qū)鍵是時(shí)間戳類型邊界值兩邊的寫法精度不一致可能出現(xiàn)微妙的差異需要仔細(xì)對(duì)齊。4.4 PL/SQL改寫不要只在語法上做文章PL/SQL包和存儲(chǔ)過程遷移是最耗時(shí)的一環(huán)。改寫的關(guān)鍵不只是語法還包括變量類型、游標(biāo)、隱式游標(biāo)屬性、異常處理、動(dòng)態(tài)SQL等側(cè)面。比較典型的改寫點(diǎn)%TYPE和%ROWTYPE目標(biāo)庫是否支持對(duì)應(yīng)的屬性聲明通常支持但嵌套在包變量里時(shí)要看兼容程度FORALL和BULK COLLECT批量處理語法能否直接兼容如果不能需要改成循環(huán)加集合類型的處理方式性能上要注意別退化太嚴(yán)重自治事務(wù)Oracle里的PRAGMA AUTONOMOUS_TRANSACTION用于在事務(wù)中隔離一段獨(dú)立提交。KingbaseES對(duì)自治事務(wù)有一定支持但語義邊界要仔細(xì)驗(yàn)證特別是嵌套和異?；貪L的場(chǎng)景動(dòng)態(tài)SQLEXECUTE IMMEDIATE在目標(biāo)庫里通常也有對(duì)應(yīng)寫法但綁定變量的類型推斷有所不同偶爾會(huì)出現(xiàn)運(yùn)行時(shí)類型轉(zhuǎn)換錯(cuò)誤一個(gè)很重要的建議PL/SQL改造完成后不要只在單元層面驗(yàn)證。要把它放進(jìn)完整的應(yīng)用調(diào)用鏈里做集成測(cè)試因?yàn)楹芏喟g共享了全局變量或游標(biāo)狀態(tài)分開測(cè)試看不出問題合在一起就跑出臟數(shù)據(jù)。5. 性能調(diào)優(yōu)從慢到不能忍到符合預(yù)期遷移完成后性能調(diào)優(yōu)是另一個(gè)大塊工作。很多團(tuán)隊(duì)覺得數(shù)據(jù)導(dǎo)過去就完事了結(jié)果業(yè)務(wù)一上線原來200毫秒的查詢變成5秒才發(fā)現(xiàn)性能問題才剛開始。性能調(diào)優(yōu)要分階段做不要一上來就亂改SQL。5.1 先看執(zhí)行計(jì)劃再談優(yōu)化遇到慢查詢第一步永遠(yuǎn)是看執(zhí)行計(jì)劃而不是憑經(jīng)驗(yàn)加索引。KingbaseES支持EXPLAIN ANALYZE可以查看真實(shí)執(zhí)行信息和耗時(shí)分布。拿到執(zhí)行計(jì)劃后重點(diǎn)關(guān)注幾個(gè)信號(hào)Seq Scan順序掃描大表說明缺索引或者統(tǒng)計(jì)信息沒更新Nested Loop 循環(huán)嵌套如果內(nèi)外表基數(shù)都很大可能要改成哈希連接排序操作內(nèi)存溢出說明work_mem設(shè)置不足或者查詢本身需要簡(jiǎn)化行數(shù)估算偏差大基本是統(tǒng)計(jì)信息陳舊先收集統(tǒng)計(jì)信息再觀察我見過一個(gè)典型案例某查詢?cè)贠racle上秒回遷到KingbaseES后十幾秒。執(zhí)行計(jì)劃顯示大表與小表連接時(shí)選擇了嵌套循環(huán)因?yàn)榻y(tǒng)計(jì)信息沒有更新優(yōu)化器估錯(cuò)了小表的行數(shù)。手動(dòng)執(zhí)行一次統(tǒng)計(jì)信息收集后執(zhí)行計(jì)劃切換成了哈希連接查詢降到幾百毫秒。這種情況先不要改SQL把統(tǒng)計(jì)信息做準(zhǔn)就已經(jīng)解決一大半問題。5.2 統(tǒng)計(jì)信息、索引和外鍵索引遷移后第一件事就是收集統(tǒng)計(jì)信息。不管是導(dǎo)數(shù)據(jù)還是導(dǎo)入后重建索引統(tǒng)計(jì)信息都可能是舊值或缺失。用高采樣率把全部表統(tǒng)計(jì)一遍比任何調(diào)優(yōu)都更基礎(chǔ)。索引層面有幾個(gè)容易忽略的點(diǎn)外鍵列必須有索引Oracle里如果外鍵列缺索引某些DML比如刪除父表記錄可能觸發(fā)全表鎖或全表掃描。KingbaseES沒有自動(dòng)幫你在外鍵列建索引的機(jī)制遷移后要手工補(bǔ)函數(shù)索引Oracle里WHERE UPPER(col) ABC可以走函數(shù)索引目標(biāo)庫也支持表達(dá)式索引但遷移工具不一定能自動(dòng)轉(zhuǎn)換這類定義部分索引帶WHERE條件的索引如果源庫有對(duì)應(yīng)機(jī)制可以遷移過來有助于減小索引體積-- 例補(bǔ)外鍵索引 CREATE INDEX idx_order_user ON orders(user_id); -- 例表達(dá)式索引 CREATE INDEX idx_user_name_upper ON users(UPPER(user_name));索引也不是越多越好。很多系統(tǒng)從Oracle遷過來原庫里的索引九成都是有效的但偶爾有些冗余索引只會(huì)拖慢導(dǎo)入速度。遷移時(shí)先把必要的唯一索引、主鍵索引建好業(yè)務(wù)驗(yàn)證之后再根據(jù)慢查詢反饋補(bǔ)二級(jí)索引這是比較穩(wěn)健的順序。5.3 查詢改寫OR改UNION、IN改EXISTS這些老套路KingbaseES優(yōu)化器能力已經(jīng)相當(dāng)不錯(cuò)但還是有一些查詢模式容易踩坑。以下幾個(gè)改寫方向是實(shí)戰(zhàn)中高頻使用的大表上的OR多個(gè)條件用OR連接時(shí)優(yōu)化器有時(shí)很難選擇合適的索引改寫為UNION ALL或拆成多條SQL往往更快IN子查詢數(shù)據(jù)量大如果子查詢返回行數(shù)很多且外表也大改寫成EXISTS或顯式的JOIN可能更高效。這個(gè)不要機(jī)械套用要實(shí)測(cè)深分頁LIMIT 100000, 20這種深分頁需要掃描并丟棄前面大量行有足夠索引支撐時(shí)可以考慮密鑰集分頁子查詢拉平有些嵌套子查詢?cè)趫?zhí)行計(jì)劃里被拉平效果更好手動(dòng)改寫有時(shí)反而更差一切以執(zhí)行計(jì)劃為準(zhǔn)這里再強(qiáng)調(diào)一次改寫參考可以看但一定用數(shù)據(jù)說話。同樣的SQL在這套數(shù)據(jù)量下走A方案快換一套數(shù)據(jù)分布可能B方案更好。團(tuán)隊(duì)里應(yīng)該形成每個(gè)改寫都必須跑EXPLAIN和實(shí)際耗時(shí)對(duì)比的約定。5.4 大批量導(dǎo)入性能從小時(shí)級(jí)到分鐘級(jí)數(shù)據(jù)導(dǎo)入慢是遷移現(xiàn)場(chǎng)最常見的焦慮源之一。優(yōu)化導(dǎo)入速度通常從幾個(gè)方向同時(shí)下手禁用或延遲索引導(dǎo)入前先刪除非唯一索引導(dǎo)完再重建。這個(gè)辦法對(duì)幾百GB的表能省出大量時(shí)間調(diào)整導(dǎo)入事務(wù)粒度不要每行一個(gè)事務(wù)也不要超大事務(wù)一把梭。批量提交搭配合理的事務(wù)大小既保證進(jìn)度可控也讓數(shù)據(jù)異常時(shí)可定位并行寫多表如果表之間沒有外鍵約束依賴可以分表并行導(dǎo)入。有依賴關(guān)系的表按拓?fù)渑判驕p少約束檢查的開銷避開高峰遷移盡量放在系統(tǒng)低峰期避免跟正常業(yè)務(wù)爭(zhēng)搶IO和CPU我記憶里有一次遷移一個(gè)大批量歷史表幾千萬行。第一次傻乎乎開著大量索引導(dǎo)跑了一個(gè)多小時(shí)后來改成先刪非唯一索引、調(diào)大一批導(dǎo)入量、再并行導(dǎo)四張關(guān)聯(lián)表最后不到20分鐘導(dǎo)完建索引又花了5分鐘。這個(gè)對(duì)比足夠說明導(dǎo)入策略對(duì)最終耗時(shí)有決定性影響。另外導(dǎo)入過程中要持續(xù)觀察計(jì)數(shù)器和系統(tǒng)負(fù)載。如果發(fā)現(xiàn)磁盤IO已經(jīng)打滿并行度再高也沒用反倒可能拖垮整個(gè)實(shí)例。這時(shí)候?qū)幙赏Ｏ聛碚{(diào)整也別硬跑到底。5.5 數(shù)據(jù)校驗(yàn)上線前的最后一道防線數(shù)據(jù)校驗(yàn)不解決性能問題但它解決的是性能再高但數(shù)據(jù)錯(cuò)了等于白干的問題。校驗(yàn)分幾個(gè)層次總量校驗(yàn)統(tǒng)計(jì)每個(gè)表的行數(shù)、關(guān)鍵字段的sum值兩側(cè)對(duì)比抽樣校驗(yàn)按主鍵抽樣比對(duì)單個(gè)字段尤其關(guān)注字符型字段尾空格、數(shù)值精度、日期格式邏輯校驗(yàn)針對(duì)業(yè)務(wù)關(guān)鍵口徑比如訂單金額匯總、用戶狀態(tài)分布編寫校驗(yàn)SQL在兩側(cè)分別跑對(duì)比結(jié)果應(yīng)用回歸最有效的一層直接用測(cè)試賬號(hào)跑業(yè)務(wù)流程看有沒有功能報(bào)錯(cuò)和數(shù)據(jù)異常校驗(yàn)?zāi)_本建議在遷移前就寫好別等數(shù)據(jù)導(dǎo)完再臨時(shí)寫。臨時(shí)寫的腳本又慢又容易漏而且校驗(yàn)SQL本身也要在兩個(gè)庫上跑兩邊語法未必完全一致提前驗(yàn)證校驗(yàn)?zāi)_本是很有必要的。6. 上線切換和回退把退路留好心里不慌遷移項(xiàng)目最后一步是切換上線。切換方案里必須包含三個(gè)要素切換步驟、驗(yàn)證步驟、回退步驟。很多人準(zhǔn)備工作做得很細(xì)但回退方案寫得草率結(jié)果真出問題時(shí)手忙腳亂。我的建議是切換當(dāng)天按這個(gè)順序走停止應(yīng)用寫入確認(rèn)源庫不再有新數(shù)據(jù)產(chǎn)生執(zhí)行最后一輪增量同步或補(bǔ)數(shù)記錄源庫和目標(biāo)庫的校驗(yàn)快照應(yīng)用連接串切換到目標(biāo)庫跑核心業(yè)務(wù)冒煙用例啟動(dòng)完整業(yè)務(wù)觀察監(jiān)控回退方案要提前演練。7. 聊聊我自己的感受做了幾個(gè)遷移項(xiàng)目之后我最大的體會(huì)是遷移這件事真正難的從來不是搬數(shù)據(jù)這個(gè)動(dòng)作而是如何在搬完之后讓業(yè)務(wù)感覺什么都沒發(fā)生。工具選型選得再好參數(shù)調(diào)得再順最后決定成敗的還是那些反復(fù)校驗(yàn)、逐條對(duì)照、不斷追問為什么兩邊結(jié)果不一樣的笨功夫。如果你正在負(fù)責(zé)類似的遷移建議務(wù)必要留出充足的緩沖時(shí)間。工具評(píng)估三成的時(shí)間對(duì)象盤點(diǎn)兩成改造四成切換和驗(yàn)證兩成這樣比例下來項(xiàng)目不會(huì)太慌。真要說有什么金句值得記住那就是別相信任何一次性的自動(dòng)遷移結(jié)果人工驗(yàn)證和回歸測(cè)試永遠(yuǎn)不能省。 Oracle到KingbaseES遷移實(shí)戰(zhàn)：從工具選型到性能調(diào)優(yōu)的避坑指南
我這里沒有現(xiàn)成的項(xiàng)目正文、關(guān)鍵詞和摘要可用只能根據(jù)這個(gè)標(biāo)題本身把一線遷移過程中實(shí)際會(huì)遇到的事講清楚。做過多套從國(guó)外商用數(shù)據(jù)庫往國(guó)產(chǎn)數(shù)據(jù)庫遷的活之后最大的感受是遷移本身并不難難的是遷移之前沒人告訴你的那些隱性成本和看起來能跑但實(shí)際是錯(cuò)的改寫。這篇文章就圍繞工具選型、參數(shù)配置、性能調(diào)優(yōu)三條主線展開我把踩過的坑和修正過程一起寫出來希望能幫后面接手這類活兒的人少走幾趟彎路。1. 遷移前先搞清楚這次遷移真正難在哪很多人拿到遷移任務(wù)后第一反應(yīng)是找工具其實(shí)這是順序錯(cuò)了。工具解決的是怎么搬但真正決定項(xiàng)目成敗的是搬過去能不能跑、跑得對(duì)不對(duì)這屬于兼容性評(píng)估的范疇。我在多個(gè)項(xiàng)目里發(fā)現(xiàn)將近一半的延期和返工都出在遷移前的評(píng)估階段而不是遷移執(zhí)行階段。1.1 兼容性評(píng)估別只測(cè)SQL要連數(shù)據(jù)行為一起測(cè)先說兼容性評(píng)估。很多團(tuán)隊(duì)的做法是拿業(yè)務(wù)SQL清單到目標(biāo)庫上跑一遍能跑通就算兼容跑不通就交給開發(fā)改。這種評(píng)估方式太粗糙了因?yàn)閿?shù)據(jù)庫遷移里最隱蔽的問題根本不是SQL語法而是數(shù)據(jù)行為的差異。舉個(gè)例子Oracle里空字符串和NULL是兩回事你敢寫WHERE col Oracle會(huì)把空串轉(zhuǎn)成NULL所以這個(gè)條件永遠(yuǎn)不成立。KingbaseES早期的兼容模式里不一定保持這個(gè)行為。再比如NUMBER類型在Oracle里可以存整數(shù)也可以存小數(shù)精度范圍極大遷到KingbaseES如果用NUMERIC那問題不大但如果評(píng)估時(shí)沒注意類型映射工具給自動(dòng)映射成了INT那小數(shù)位直接被截?cái)嗌暇€后賬單金額差幾毛錢這種事都能發(fā)生。所以做兼容性評(píng)估時(shí)我建議至少準(zhǔn)備三層檢查語法層現(xiàn)有應(yīng)用里的SQL能不能在目標(biāo)庫跑通工具一般能覆蓋語義層同樣的SQL在兩邊返回結(jié)果是否一致特別是空值、排序、聚合、類型轉(zhuǎn)換這些基礎(chǔ)行為數(shù)據(jù)層存量數(shù)據(jù)里的邊界值、超長(zhǎng)字符串、特殊字符能否無損落庫語義層和數(shù)據(jù)層往往需要編寫專門的對(duì)比腳本把同一批數(shù)據(jù)分別在兩個(gè)庫上跑同一套查詢邏輯然后做結(jié)果集比對(duì)。這個(gè)環(huán)節(jié)不要偷懶也不要只看抽樣結(jié)果能全量比對(duì)就全量比對(duì)。1.2 盤點(diǎn)對(duì)象時(shí)最容易漏掉的那幾類對(duì)象盤點(diǎn)也是遷移前的重要環(huán)節(jié)。建表結(jié)構(gòu)、索引、視圖這些大家基本不會(huì)漏容易漏的是以下幾類序列Oracle應(yīng)用里SEQ.NEXTVAL隨處可見遷到KingbaseES如果不處理序列應(yīng)用一跑就直接報(bào)錯(cuò)觸發(fā)器用于審計(jì)、默認(rèn)值填充、級(jí)聯(lián)操作的觸發(fā)器遷移時(shí)常常被忽略導(dǎo)致業(yè)務(wù)邏輯靜默缺失包和存儲(chǔ)過程Oracle的PL/SQL包里有變量、游標(biāo)、異常處理KingbaseES的兼容模式能處理一部分但復(fù)雜包經(jīng)常需要手工改寫物化視圖及其刷新機(jī)制如果源端有物化視圖并且業(yè)務(wù)依賴定期刷新目標(biāo)端也得有對(duì)應(yīng)的實(shí)現(xiàn)和調(diào)度同義詞很多老系統(tǒng)里同義詞用得很多這也屬于需要顯式遷移的對(duì)象我之前接手過一個(gè)模擬系統(tǒng)光序列就有一百多個(gè)分布在幾十個(gè)表上。遷移工具自動(dòng)處理了一部分但有幾張表的主鍵用的是TRIGGER SEQUENCE的方式在插入前用觸發(fā)器取序列值工具沒有識(shí)別出這個(gè)模式。結(jié)果數(shù)據(jù)導(dǎo)進(jìn)去之后新插入的記錄主鍵直接沖突調(diào)試了整整一天才定位到是觸發(fā)器少建了幾個(gè)。這種問題在評(píng)估階段如果細(xì)盤對(duì)象是完全可以提前發(fā)現(xiàn)的。1.3 停機(jī)窗口和數(shù)據(jù)量決定遷移策略評(píng)估完兼容性之后就要確定遷移策略。策略主要取決于兩個(gè)因素停機(jī)窗口和數(shù)據(jù)量。停機(jī)窗口很短比如兩小時(shí)以內(nèi)數(shù)據(jù)量又大幾百GB那基本只能靠存量數(shù)據(jù)全量導(dǎo)出導(dǎo)入加增量數(shù)據(jù)同步兩條腿走路。增量同步是技術(shù)難度最高的部分好在KingbaseES在這塊有配套的同步工具可以對(duì)接日志需要提前聯(lián)調(diào)。停機(jī)窗口比較充裕數(shù)據(jù)量也就幾十GB那更簡(jiǎn)單直接停應(yīng)用、導(dǎo)數(shù)據(jù)、校驗(yàn)、啟動(dòng)一條龍下來就完事了。另外還需要考慮網(wǎng)絡(luò)帶寬。源端和目標(biāo)端如果不在同一機(jī)房中間帶寬只有百兆那幾百GB的數(shù)據(jù)怎么壓縮、怎么多線程傳輸都要提前設(shè)計(jì)。千萬別等遷移當(dāng)天再測(cè)網(wǎng)速那是給自己埋雷。2. 工具選型先分清你要的是搬數(shù)據(jù)還是搬業(yè)務(wù)工具選型這塊我的建議是先想清楚一個(gè)核心問題你是要搬數(shù)據(jù)還是搬業(yè)務(wù)這兩個(gè)訴求對(duì)應(yīng)的工具路徑完全不一樣。市面上很多宣傳都說自己能做到一鍵遷移、業(yè)務(wù)無感但實(shí)際用下來能自動(dòng)化處理90%的常規(guī)對(duì)象就已經(jīng)是優(yōu)秀水平剩下10%的硬骨頭基本都得靠人寫腳本硬啃。2.1 數(shù)據(jù)遷移工具怎么選批量數(shù)據(jù)的搬運(yùn)工如果目標(biāo)只是把數(shù)據(jù)從一個(gè)庫搬到另一個(gè)庫那么核心關(guān)注點(diǎn)是這批數(shù)據(jù)有多重、數(shù)據(jù)要不要轉(zhuǎn)換、停在窗口內(nèi)的限制是什么。在真實(shí)項(xiàng)目中我常用的方案分三類通用ETL工具、數(shù)據(jù)庫原生邏輯備份工具、以及數(shù)據(jù)同步類工具。三類工具各有各的適用場(chǎng)景工具類型典型代表優(yōu)點(diǎn)局限性通用ETL/同步框架DataX、Kettle等數(shù)據(jù)源適配廣、可視化、可定制轉(zhuǎn)換邏輯大批量表結(jié)構(gòu)遷移仍需配合DDL轉(zhuǎn)換性能調(diào)參需要細(xì)致數(shù)據(jù)庫原生邏輯導(dǎo)出導(dǎo)入expdp/impdp輔助分析、目標(biāo)庫自帶導(dǎo)出工具、copy命令等類型映射準(zhǔn)確、性能較高、適合同生態(tài)遷移跨庫遷移時(shí)DDL、存儲(chǔ)過程等對(duì)象仍需額外轉(zhuǎn)換數(shù)據(jù)同步工具基于日志的增量同步工具這里指數(shù)據(jù)庫廠商配套的同步組件停機(jī)窗口可以縮到很短、支持增量追平環(huán)境要求較嚴(yán)苛、偶爾有斷點(diǎn)續(xù)傳問題這里我不建議一上來就選最重的同步方案。如果數(shù)據(jù)量不大、窗口夠用全量邏輯導(dǎo)出導(dǎo)入又快又穩(wěn)出問題時(shí)排查鏈路也短。同步工具適合的是那種必須把停機(jī)時(shí)間壓縮到分鐘級(jí)的苛刻場(chǎng)景。2.2 結(jié)構(gòu)遷移工具能幫你生成80%的DDL和PL/SQL結(jié)構(gòu)遷移比數(shù)據(jù)遷移要難得多特別是Oracle里的PL/SQL、包、函數(shù)、視圖、觸發(fā)器。好在絕大多數(shù)國(guó)產(chǎn)庫包括KingbaseES在內(nèi)生態(tài)里都有專門的遷移評(píng)估和轉(zhuǎn)換工具這類工具通常做的事情是掃描Oracle下的全部對(duì)象按類型分類列出自動(dòng)完成一部分DDL和PL/SQL的語法轉(zhuǎn)換輸出轉(zhuǎn)換報(bào)告標(biāo)注哪些對(duì)象轉(zhuǎn)換成功、哪些需要人工處理這類工具輸出的轉(zhuǎn)換成功率有沒有參考價(jià)值有但別全信。我曾經(jīng)在一個(gè)項(xiàng)目上拿一套復(fù)雜的業(yè)務(wù)包做測(cè)試工具報(bào)的轉(zhuǎn)換成功率不到80%剩下的全靠人工補(bǔ)但另一套比較規(guī)范的系統(tǒng)工具幾乎全部自動(dòng)處理完了。所以工具的自動(dòng)化程度和源系統(tǒng)本身的寫法規(guī)不規(guī)范高度相關(guān)。這里有一個(gè)很實(shí)用的經(jīng)驗(yàn)如果在評(píng)估階段發(fā)現(xiàn)源系統(tǒng)里大量使用了一些較為復(fù)雜的高級(jí)特性比如自治事務(wù)、動(dòng)態(tài)SQL、帶OUT參數(shù)的存儲(chǔ)過程調(diào)用那你基本就要做好人工改造至少兩三周的心理準(zhǔn)備。千萬不要只看工具報(bào)告上的百分比。2.3 人工改造怎么拆解才高效人工改造是最耗時(shí)但也最不可跳過的環(huán)節(jié)。高效拆解的關(guān)鍵是把改造任務(wù)分類按難度排序不要眉毛胡子一把抓。結(jié)合我的實(shí)戰(zhàn)改造清單一般這么拆純語法改寫NVL改COALESCE、SYSDATE改CURRENT_TIMESTAMP、||或CONCAT語義核對(duì)。這類工作量大但機(jī)械適合交給工具批量處理人工抽查驗(yàn)證。邏輯等價(jià)改寫ROWNUM分頁改LIMIT、外連接寫法()改標(biāo)準(zhǔn)LEFT JOIN。這類需要改的人理解兩邊語義差異適合由熟悉SQL的工程師處理逐個(gè)走讀。結(jié)構(gòu)性改造存儲(chǔ)過程里的包狀態(tài)、批量收集、動(dòng)態(tài)SQL重構(gòu)這類往往是性能殺手需要結(jié)合應(yīng)用調(diào)用關(guān)系一起考慮建議由資深工程師負(fù)責(zé)。另外改造時(shí)一定要保留一份源SQL與目標(biāo)SQL對(duì)照清單每條SQL都要能追溯到業(yè)務(wù)含義否則后面聯(lián)調(diào)時(shí)根本沒法定位問題。我見過有些團(tuán)隊(duì)改完就不管了上線后一條SQL結(jié)果不對(duì)找了半天也定位不到是哪個(gè)應(yīng)用觸發(fā)出來的就是吃了沒有對(duì)應(yīng)關(guān)系的虧。3. 參數(shù)配置遷移之前把坑提前踩平參數(shù)配置是避坑指南里的重量級(jí)章節(jié)。很多人覺得參數(shù)配置就是改幾個(gè)內(nèi)存大小但實(shí)際涉及的層面很多從數(shù)據(jù)庫初始化參數(shù)到客戶端連接串再到遷移任務(wù)自身的并發(fā)度每個(gè)參數(shù)都可能成為壓垮駱駝的最后一根稻草。3.1 實(shí)例參數(shù)按目標(biāo)負(fù)載而不是按源庫配置先說數(shù)據(jù)庫實(shí)例參數(shù)。KingbaseES的內(nèi)核與開源數(shù)據(jù)庫生態(tài)有緊密關(guān)系很多經(jīng)典參數(shù)可以借鑒參考但不要照搬Oracle那套思維。常見需要調(diào)整的關(guān)鍵參數(shù)包括shared_buffers共享緩沖區(qū)如果服務(wù)器內(nèi)存充足可以按物理內(nèi)存的約1/4來設(shè)置但要留意操作系統(tǒng)緩存配合。設(shè)置太小熱點(diǎn)數(shù)據(jù)頻繁落盤性能直線下降。work_mem工作內(nèi)存排序、哈希操作會(huì)用到的內(nèi)存。設(shè)置太大會(huì)導(dǎo)致并發(fā)場(chǎng)景下內(nèi)存溢出設(shè)置太小又會(huì)讓排序落盤。建議結(jié)合業(yè)務(wù)實(shí)際并發(fā)量來評(píng)估不要拍腦袋。maintenance_work_mem維護(hù)操作內(nèi)存創(chuàng)建索引、收集統(tǒng)計(jì)信息這類操作使用。這個(gè)參數(shù)在遷移建索引階段影響巨大調(diào)大一些能顯著縮短操作時(shí)間。checkpoint相關(guān)大量數(shù)據(jù)導(dǎo)入時(shí)檢查點(diǎn)觸發(fā)頻繁會(huì)導(dǎo)致落盤抖動(dòng)。適度調(diào)大檢查點(diǎn)間隔和緩沖區(qū)平穩(wěn)完成導(dǎo)入再說。WAL相關(guān)參數(shù)導(dǎo)入場(chǎng)景下可以放松一些持久化策略加快寫入但前提是能接受導(dǎo)入過程中異常斷電可能丟失數(shù)據(jù)的風(fēng)險(xiǎn)。遷移階段可以臨時(shí)調(diào)業(yè)務(wù)上線后要恢復(fù)為穩(wěn)妥配置。還有個(gè)參數(shù)別忽略連接數(shù)上限。遷移時(shí)往往會(huì)有多個(gè)工具和腳本同時(shí)連庫如果連接數(shù)設(shè)得太小很多任務(wù)會(huì)直接連不上看起來像網(wǎng)絡(luò)故障。3.2 連接串和驅(qū)動(dòng)參數(shù)被忽略的隱形因素連接串和驅(qū)動(dòng)這塊很多問題不是參數(shù)本身錯(cuò)了而是版本不匹配導(dǎo)致的行為差異。我們?cè)谶w移時(shí)經(jīng)常遇到這樣的情況JDBC驅(qū)動(dòng)版本過低對(duì)目標(biāo)庫某些類型支持不完整讀出來的字符串長(zhǎng)度不對(duì)或者日期格式解析異常。建議用官方推薦的驅(qū)動(dòng)分支并且讓應(yīng)用和遷移腳本統(tǒng)一驅(qū)動(dòng)管理。prepareThreshold或等價(jià)機(jī)制值得重點(diǎn)關(guān)注。默認(rèn)情況下來自某些驅(qū)動(dòng)的語句在執(zhí)行多次時(shí)會(huì)做服務(wù)端預(yù)編譯好處是性能更好但壞處是如果應(yīng)用里習(xí)慣用字符串拼接SQL的方式服務(wù)端預(yù)編譯空間的占用和解析開銷可能會(huì)成為瓶頸。必要時(shí)需要把預(yù)編譯閾值調(diào)低或關(guān)閉。還有fetchSize抓取行數(shù)。很多做數(shù)據(jù)比對(duì)或大批量導(dǎo)出的腳本默認(rèn)抓取方式會(huì)一次性把結(jié)果集全部拉進(jìn)內(nèi)存數(shù)據(jù)一大就直接內(nèi)存溢出。顯式設(shè)置合理的抓取行數(shù)比如每次抓取1000行能解決很多奇怪的內(nèi)存問題。這一點(diǎn)在從Oracle遷到KingbaseES后尤其明顯因?yàn)閮蛇咈?qū)動(dòng)對(duì)游標(biāo)和結(jié)果集的默認(rèn)處理行為并不一致。3.3 遷移任務(wù)自身的參數(shù)并行度不是越大越好做數(shù)據(jù)導(dǎo)入時(shí)很多人會(huì)犯一個(gè)誤區(qū)并行度拉滿。常見的做法是同時(shí)開幾十個(gè)線程導(dǎo)數(shù)據(jù)結(jié)果目標(biāo)庫的鎖競(jìng)爭(zhēng)、檢查點(diǎn)壓力、日志壓力全部拉滿整體速度反而比8個(gè)線程還慢。我的經(jīng)驗(yàn)是并行度先按CPU核數(shù)的60%-70%起步再觀察監(jiān)控如果IO等待不高、CPU還有余量再逐步加大批量大小單事務(wù)批量行數(shù)以500到2000行為宜太大會(huì)導(dǎo)致內(nèi)存開銷高、回滾段壓力大太小則提交次數(shù)過多日志寫入頻繁導(dǎo)入順序先導(dǎo)父表再導(dǎo)子表或者先禁用約束導(dǎo)完再重建。如果按原樣直接導(dǎo)外鍵約束會(huì)讓導(dǎo)入速度大打折扣另外為遷移準(zhǔn)備的賬號(hào)權(quán)限要給足但又不能超出必要范圍。我遇到過遷移賬號(hào)沒有目標(biāo)庫序列的修改權(quán)限導(dǎo)致自動(dòng)生成序列的起始值不對(duì)導(dǎo)入數(shù)據(jù)后序列又從1開始結(jié)果主鍵沖突。這種小坑調(diào)試起來非常耗神。4. 處理Oracle專有寫法從能跑到跑得對(duì)的距離這一章主要講Oracle里那些特有寫法遷到KingbaseES后容易出現(xiàn)語法不報(bào)錯(cuò)但結(jié)果不對(duì)或語法報(bào)錯(cuò)但不知道換成什么的案例。每一條我都盡量把背景和改寫思路一起講清楚。4.1 dual、sysdate、rownum這些老朋友dual 表。Oracle里SELECT SYSDATE FROM DUAL這類寫法非常普遍。KingbaseES在兼容模式下內(nèi)置了對(duì)dual的支持所以大部分場(chǎng)景直接能跑。但要注意不是所有帶dual的語句都能原樣落地如果語句里用了Oracle特有的函數(shù)問題會(huì)轉(zhuǎn)移到函數(shù)本身。建議評(píng)估階段集中搜索FROM DUAL逐個(gè)確認(rèn)關(guān)聯(lián)的函數(shù)都被目標(biāo)庫支持。SYSDATE。Oracle的SYSDATE精度是秒級(jí)別而KingbaseES推薦用CURRENT_TIMESTAMP也能工作但返回精度更高。數(shù)據(jù)插入時(shí)如果字段是DATE這種精度差異通常不會(huì)造成問題但如果業(yè)務(wù)里做了時(shí)間差運(yùn)算可能在邊界上產(chǎn)生差異。更穩(wěn)妥的方案是統(tǒng)一改成CURRENT_TIMESTAMP并做一輪結(jié)果驗(yàn)證別讓線上出現(xiàn)時(shí)間多了0.001秒這種糾纏不清的case。ROWNUM。ROWNUM在Oracle里既用于分頁也用于限制返回行數(shù)。KingbaseES里常規(guī)替代是LIMIT。這里有一個(gè)最常見的坑Oracle里ROWNUM 1是取第一行但ROWNUM 1是永遠(yuǎn)不返回行有人機(jī)械改成LIMIT 1后把原本想看有沒有數(shù)據(jù)的邏輯變成了取第一行業(yè)務(wù)語義不同。-- Oracle: SELECT * FROM (SELECT * FROM t ORDER BY id DESC) WHERE ROWNUM 10; -- KingbaseES: SELECT * FROM t ORDER BY id DESC LIMIT 10;這類改寫看起來簡(jiǎn)單但漏掉外部嵌套、錯(cuò)寫排序字段的事情時(shí)有發(fā)生一定要用真實(shí)數(shù)據(jù)前后對(duì)比。4.2 序列與自增列不檢查起始值就等于埋雷序列遷移是主鍵沖突的第一大來源。Oracle里序列通常是獨(dú)立對(duì)象應(yīng)用在插入前顯式調(diào)用NEXTVAL。遷到KingbaseES后你面臨兩個(gè)選擇保留獨(dú)立序列對(duì)象改寫調(diào)用方式改成自增列含identity或其他自增機(jī)制然后改造應(yīng)用去掉顯式調(diào)用我個(gè)人的建議如果應(yīng)用里調(diào)用序列的地方非常多改成自增列反而是一項(xiàng)大工程因?yàn)樗胁迦胝Z句都要?jiǎng)?。不如保留序列?duì)象只把調(diào)用方式做適配。但不管選哪種都必須手動(dòng)校準(zhǔn)序列的起始值讓它大于當(dāng)前表里的最大ID。補(bǔ)救辦法是在遷移后執(zhí)行序列設(shè)置類操作。比如SELECT setval(seq_xxx, (SELECT max(id) FROM table_xxx));這個(gè)動(dòng)作一定要寫在遷移步驟清單里而且要放在數(shù)據(jù)導(dǎo)入之后執(zhí)行否則就會(huì)出現(xiàn)數(shù)據(jù)導(dǎo)完了、序列還在原地踏步的悲劇。4.3 空表、LOB、分區(qū)表隱蔽的數(shù)據(jù)完整性殺手空表。Oracle的某些版本里空表在遷移工具掃描時(shí)是不占空間的如果遷移工具依賴數(shù)據(jù)字典里的段信息可能漏掉空表結(jié)構(gòu)。結(jié)果就是表沒建出來業(yè)務(wù)一跑就報(bào)表或視圖不存在。處理方式是遷移前先對(duì)空表做一次建表語句生成確保結(jié)構(gòu)遷移階段全部覆蓋。LOB字段。CLOB、BLOB遷移的常見問題是碎片化、性能差和編碼差異。尤其是超大CLOB如果工具默認(rèn)一次性讀入內(nèi)存極易OOM。建議分批讀取、寫入。分區(qū)表。Oracle的分區(qū)策略多種多樣范圍分區(qū)、列表分區(qū)、哈希分區(qū)都有。KingbaseES支持的分區(qū)種類也很多但映射關(guān)系不是一一對(duì)應(yīng)的。遷移時(shí)要重點(diǎn)檢查分區(qū)鍵類型和邊界值定義避免邊界數(shù)據(jù)進(jìn)入錯(cuò)誤分區(qū)。-- Oracle 范圍分區(qū)示例 CREATE TABLE sale ( id NUMBER, sale_date DATE ) PARTITION BY RANGE (sale_date) ( PARTITION p2023 VALUES LESS THAN (TO_DATE(2024-01-01,YYYY-MM-DD)), PARTITION p2024 VALUES LESS THAN (TO_DATE(2025-01-01,YYYY-MM-DD)) ); -- KingbaseES 適配寫法 CREATE TABLE sale ( id numeric, sale_date date ) PARTITION BY RANGE (sale_date); CREATE TABLE sale_p2023 PARTITION OF sale FOR VALUES FROM (2023-01-01) TO (2024-01-01); CREATE TABLE sale_p2024 PARTITION OF sale FOR VALUES FROM (2024-01-01) TO (2025-01-01);注意邊界語義差異Oracle用LESS THAN分區(qū)的上邊界是不包含的而KingbaseES的分區(qū)范圍寫法默認(rèn)也是上邊界不包含這點(diǎn)還好。但如果分區(qū)鍵是時(shí)間戳類型邊界值兩邊的寫法精度不一致可能出現(xiàn)微妙的差異需要仔細(xì)對(duì)齊。4.4 PL/SQL改寫不要只在語法上做文章PL/SQL包和存儲(chǔ)過程遷移是最耗時(shí)的一環(huán)。改寫的關(guān)鍵不只是語法還包括變量類型、游標(biāo)、隱式游標(biāo)屬性、異常處理、動(dòng)態(tài)SQL等側(cè)面。比較典型的改寫點(diǎn)%TYPE和%ROWTYPE目標(biāo)庫是否支持對(duì)應(yīng)的屬性聲明通常支持但嵌套在包變量里時(shí)要看兼容程度FORALL和BULK COLLECT批量處理語法能否直接兼容如果不能需要改成循環(huán)加集合類型的處理方式性能上要注意別退化太嚴(yán)重自治事務(wù)Oracle里的PRAGMA AUTONOMOUS_TRANSACTION用于在事務(wù)中隔離一段獨(dú)立提交。KingbaseES對(duì)自治事務(wù)有一定支持但語義邊界要仔細(xì)驗(yàn)證特別是嵌套和異?；貪L的場(chǎng)景動(dòng)態(tài)SQLEXECUTE IMMEDIATE在目標(biāo)庫里通常也有對(duì)應(yīng)寫法但綁定變量的類型推斷有所不同偶爾會(huì)出現(xiàn)運(yùn)行時(shí)類型轉(zhuǎn)換錯(cuò)誤一個(gè)很重要的建議PL/SQL改造完成后不要只在單元層面驗(yàn)證。要把它放進(jìn)完整的應(yīng)用調(diào)用鏈里做集成測(cè)試因?yàn)楹芏喟g共享了全局變量或游標(biāo)狀態(tài)分開測(cè)試看不出問題合在一起就跑出臟數(shù)據(jù)。5. 性能調(diào)優(yōu)從慢到不能忍到符合預(yù)期遷移完成后性能調(diào)優(yōu)是另一個(gè)大塊工作。很多團(tuán)隊(duì)覺得數(shù)據(jù)導(dǎo)過去就完事了結(jié)果業(yè)務(wù)一上線原來200毫秒的查詢變成5秒才發(fā)現(xiàn)性能問題才剛開始。性能調(diào)優(yōu)要分階段做不要一上來就亂改SQL。5.1 先看執(zhí)行計(jì)劃再談優(yōu)化遇到慢查詢第一步永遠(yuǎn)是看執(zhí)行計(jì)劃而不是憑經(jīng)驗(yàn)加索引。KingbaseES支持EXPLAIN ANALYZE可以查看真實(shí)執(zhí)行信息和耗時(shí)分布。拿到執(zhí)行計(jì)劃后重點(diǎn)關(guān)注幾個(gè)信號(hào)Seq Scan順序掃描大表說明缺索引或者統(tǒng)計(jì)信息沒更新Nested Loop 循環(huán)嵌套如果內(nèi)外表基數(shù)都很大可能要改成哈希連接排序操作內(nèi)存溢出說明work_mem設(shè)置不足或者查詢本身需要簡(jiǎn)化行數(shù)估算偏差大基本是統(tǒng)計(jì)信息陳舊先收集統(tǒng)計(jì)信息再觀察我見過一個(gè)典型案例某查詢?cè)贠racle上秒回遷到KingbaseES后十幾秒。執(zhí)行計(jì)劃顯示大表與小表連接時(shí)選擇了嵌套循環(huán)因?yàn)榻y(tǒng)計(jì)信息沒有更新優(yōu)化器估錯(cuò)了小表的行數(shù)。手動(dòng)執(zhí)行一次統(tǒng)計(jì)信息收集后執(zhí)行計(jì)劃切換成了哈希連接查詢降到幾百毫秒。這種情況先不要改SQL把統(tǒng)計(jì)信息做準(zhǔn)就已經(jīng)解決一大半問題。5.2 統(tǒng)計(jì)信息、索引和外鍵索引遷移后第一件事就是收集統(tǒng)計(jì)信息。不管是導(dǎo)數(shù)據(jù)還是導(dǎo)入后重建索引統(tǒng)計(jì)信息都可能是舊值或缺失。用高采樣率把全部表統(tǒng)計(jì)一遍比任何調(diào)優(yōu)都更基礎(chǔ)。索引層面有幾個(gè)容易忽略的點(diǎn)外鍵列必須有索引Oracle里如果外鍵列缺索引某些DML比如刪除父表記錄可能觸發(fā)全表鎖或全表掃描。KingbaseES沒有自動(dòng)幫你在外鍵列建索引的機(jī)制遷移后要手工補(bǔ)函數(shù)索引Oracle里WHERE UPPER(col) ABC可以走函數(shù)索引目標(biāo)庫也支持表達(dá)式索引但遷移工具不一定能自動(dòng)轉(zhuǎn)換這類定義部分索引帶WHERE條件的索引如果源庫有對(duì)應(yīng)機(jī)制可以遷移過來有助于減小索引體積-- 例補(bǔ)外鍵索引 CREATE INDEX idx_order_user ON orders(user_id); -- 例表達(dá)式索引 CREATE INDEX idx_user_name_upper ON users(UPPER(user_name));索引也不是越多越好。很多系統(tǒng)從Oracle遷過來原庫里的索引九成都是有效的但偶爾有些冗余索引只會(huì)拖慢導(dǎo)入速度。遷移時(shí)先把必要的唯一索引、主鍵索引建好業(yè)務(wù)驗(yàn)證之后再根據(jù)慢查詢反饋補(bǔ)二級(jí)索引這是比較穩(wěn)健的順序。5.3 查詢改寫OR改UNION、IN改EXISTS這些老套路KingbaseES優(yōu)化器能力已經(jīng)相當(dāng)不錯(cuò)但還是有一些查詢模式容易踩坑。以下幾個(gè)改寫方向是實(shí)戰(zhàn)中高頻使用的大表上的OR多個(gè)條件用OR連接時(shí)優(yōu)化器有時(shí)很難選擇合適的索引改寫為UNION ALL或拆成多條SQL往往更快IN子查詢數(shù)據(jù)量大如果子查詢返回行數(shù)很多且外表也大改寫成EXISTS或顯式的JOIN可能更高效。這個(gè)不要機(jī)械套用要實(shí)測(cè)深分頁LIMIT 100000, 20這種深分頁需要掃描并丟棄前面大量行有足夠索引支撐時(shí)可以考慮密鑰集分頁子查詢拉平有些嵌套子查詢?cè)趫?zhí)行計(jì)劃里被拉平效果更好手動(dòng)改寫有時(shí)反而更差一切以執(zhí)行計(jì)劃為準(zhǔn)這里再強(qiáng)調(diào)一次改寫參考可以看但一定用數(shù)據(jù)說話。同樣的SQL在這套數(shù)據(jù)量下走A方案快換一套數(shù)據(jù)分布可能B方案更好。團(tuán)隊(duì)里應(yīng)該形成每個(gè)改寫都必須跑EXPLAIN和實(shí)際耗時(shí)對(duì)比的約定。5.4 大批量導(dǎo)入性能從小時(shí)級(jí)到分鐘級(jí)數(shù)據(jù)導(dǎo)入慢是遷移現(xiàn)場(chǎng)最常見的焦慮源之一。優(yōu)化導(dǎo)入速度通常從幾個(gè)方向同時(shí)下手禁用或延遲索引導(dǎo)入前先刪除非唯一索引導(dǎo)完再重建。這個(gè)辦法對(duì)幾百GB的表能省出大量時(shí)間調(diào)整導(dǎo)入事務(wù)粒度不要每行一個(gè)事務(wù)也不要超大事務(wù)一把梭。批量提交搭配合理的事務(wù)大小既保證進(jìn)度可控也讓數(shù)據(jù)異常時(shí)可定位并行寫多表如果表之間沒有外鍵約束依賴可以分表并行導(dǎo)入。有依賴關(guān)系的表按拓?fù)渑判驕p少約束檢查的開銷避開高峰遷移盡量放在系統(tǒng)低峰期避免跟正常業(yè)務(wù)爭(zhēng)搶IO和CPU我記憶里有一次遷移一個(gè)大批量歷史表幾千萬行。第一次傻乎乎開著大量索引導(dǎo)跑了一個(gè)多小時(shí)后來改成先刪非唯一索引、調(diào)大一批導(dǎo)入量、再并行導(dǎo)四張關(guān)聯(lián)表最后不到20分鐘導(dǎo)完建索引又花了5分鐘。這個(gè)對(duì)比足夠說明導(dǎo)入策略對(duì)最終耗時(shí)有決定性影響。另外導(dǎo)入過程中要持續(xù)觀察計(jì)數(shù)器和系統(tǒng)負(fù)載。如果發(fā)現(xiàn)磁盤IO已經(jīng)打滿并行度再高也沒用反倒可能拖垮整個(gè)實(shí)例。這時(shí)候?qū)幙赏Ｏ聛碚{(diào)整也別硬跑到底。5.5 數(shù)據(jù)校驗(yàn)上線前的最后一道防線數(shù)據(jù)校驗(yàn)不解決性能問題但它解決的是性能再高但數(shù)據(jù)錯(cuò)了等于白干的問題。校驗(yàn)分幾個(gè)層次總量校驗(yàn)統(tǒng)計(jì)每個(gè)表的行數(shù)、關(guān)鍵字段的sum值兩側(cè)對(duì)比抽樣校驗(yàn)按主鍵抽樣比對(duì)單個(gè)字段尤其關(guān)注字符型字段尾空格、數(shù)值精度、日期格式邏輯校驗(yàn)針對(duì)業(yè)務(wù)關(guān)鍵口徑比如訂單金額匯總、用戶狀態(tài)分布編寫校驗(yàn)SQL在兩側(cè)分別跑對(duì)比結(jié)果應(yīng)用回歸最有效的一層直接用測(cè)試賬號(hào)跑業(yè)務(wù)流程看有沒有功能報(bào)錯(cuò)和數(shù)據(jù)異常校驗(yàn)?zāi)_本建議在遷移前就寫好別等數(shù)據(jù)導(dǎo)完再臨時(shí)寫。臨時(shí)寫的腳本又慢又容易漏而且校驗(yàn)SQL本身也要在兩個(gè)庫上跑兩邊語法未必完全一致提前驗(yàn)證校驗(yàn)?zāi)_本是很有必要的。6. 上線切換和回退把退路留好心里不慌遷移項(xiàng)目最后一步是切換上線。切換方案里必須包含三個(gè)要素切換步驟、驗(yàn)證步驟、回退步驟。很多人準(zhǔn)備工作做得很細(xì)但回退方案寫得草率結(jié)果真出問題時(shí)手忙腳亂。我的建議是切換當(dāng)天按這個(gè)順序走停止應(yīng)用寫入確認(rèn)源庫不再有新數(shù)據(jù)產(chǎn)生執(zhí)行最后一輪增量同步或補(bǔ)數(shù)記錄源庫和目標(biāo)庫的校驗(yàn)快照應(yīng)用連接串切換到目標(biāo)庫跑核心業(yè)務(wù)冒煙用例啟動(dòng)完整業(yè)務(wù)觀察監(jiān)控回退方案要提前演練。7. 聊聊我自己的感受做了幾個(gè)遷移項(xiàng)目之后我最大的體會(huì)是遷移這件事真正難的從來不是搬數(shù)據(jù)這個(gè)動(dòng)作而是如何在搬完之后讓業(yè)務(wù)感覺什么都沒發(fā)生。工具選型選得再好參數(shù)調(diào)得再順最后決定成敗的還是那些反復(fù)校驗(yàn)、逐條對(duì)照、不斷追問為什么兩邊結(jié)果不一樣的笨功夫。如果你正在負(fù)責(zé)類似的遷移建議務(wù)必要留出充足的緩沖時(shí)間。工具評(píng)估三成的時(shí)間對(duì)象盤點(diǎn)兩成改造四成切換和驗(yàn)證兩成這樣比例下來項(xiàng)目不會(huì)太慌。真要說有什么金句值得記住那就是別相信任何一次性的自動(dòng)遷移結(jié)果人工驗(yàn)證和回歸測(cè)試永遠(yuǎn)不能省。