搞Oracle到PostgreSQL遷移這件事圈子里聊得最多的不是工具選哪個而是怎么讓業(yè)務(wù)別停太久、數(shù)據(jù)到底搬對沒有、出了問題能不能跑回去這三個靈魂拷問。我最近完整跟完了一個核心交易系統(tǒng)的遷移項目正好把整套打法梳理一遍給準備上車的朋友當(dāng)個參考。先說結(jié)論Oracle遷PostgreSQL難點從來不在怎么導(dǎo)數(shù)據(jù)而在遷移鏈條的整體設(shè)計。你只有把低業(yè)務(wù)中斷、可校驗、可回退當(dāng)成一個整體目標來拆解才能避免那種數(shù)據(jù)導(dǎo)完了、業(yè)務(wù)起不來、回也回不去的尷尬局面。1. 遷移項目啟動前先想清楚怎么切再動手1.1 遷移背景與目標拆解我們這個項目是從Oracle 11g遷到PostgreSQL 14源庫大概有3TB數(shù)據(jù)核心業(yè)務(wù)表最大的一張超過8億行還有不少用到了CLOB、分區(qū)、存儲過程的老業(yè)務(wù)。業(yè)務(wù)側(cè)給的要求很明確停機窗口最多4小時切換后一個月內(nèi)如果發(fā)現(xiàn)重大問題必須能回退并且遷移完成后要拿出讓業(yè)務(wù)信服的數(shù)據(jù)一致性證明。這三條要求翻譯成技術(shù)語言就是低業(yè)務(wù)中斷不能搞先停庫全量導(dǎo)出再全量導(dǎo)入的老套路必須走全量增量同步的雙軌方案把真正的停機時間壓縮到只需要處理增量追趕和切換驗證這兩個環(huán)節(jié)?？尚ｒ炦w移完成后要用行數(shù)、校驗和、抽樣比對等手段證明數(shù)據(jù)沒丟、沒多、沒錯。不是拿兩條SQL對一下數(shù)量就完事而是要能經(jīng)得起業(yè)務(wù)和審計的追問。可回退切換后保留完整的回退通道包括源庫持續(xù)運行、反向同步機制、回退演練預(yù)案。一旦業(yè)務(wù)驗證不通過能在一個小時內(nèi)切回Oracle且不丟新增數(shù)據(jù)。這三個目標不是并列關(guān)系而是互相牽制的。比如為了可回退你可能需要在一段時間內(nèi)同時維護兩套庫的寫入為了低中斷你的增量同步工具必須足夠穩(wěn)定否則追趕不上就會無限拉長停機窗口為了可校驗又必須在遷移過程中保留足夠的審計痕跡方便回退時對賬。1.2 遷移前的源庫調(diào)研與風(fēng)險清單很多項目死在第一步?jīng)]搞清楚源庫里到底有什么就開始動手。我建議遷移前至少花一到兩周做一次徹底的源庫體檢輸出一份風(fēng)險清單。我們當(dāng)時重點排查了以下幾類東西對象清單表、索引、約束、序列、視圖、物化視圖、存儲過程、函數(shù)、包、觸發(fā)器、同義詞、DB Link。每一項都要統(tǒng)計數(shù)量并評估改造工作量。千萬別小看同義詞和DB Link業(yè)務(wù)SQL里如果大量使用遷移后全都要改。SQL使用情況抓取AWR報告和近一段時間的慢SQL重點看用了哪些Oracle獨有語法比如CONNECT BY層次查詢、()外連接、ROWNUM分頁、NVL、SYSDATE、MERGE、LISTAGG等。這些是SQL改造的重災(zāi)區(qū)。數(shù)據(jù)類型分布NUMBER、VARCHAR2、DATE、CLOB、BLOB、LONG、RAW、ROWID等類型的字段數(shù)量和最大長度。尤其是CLOB和LONG遷移后要用TEXT替代但業(yè)務(wù)代碼里對CLOB的操作方式可能需要調(diào)整。存儲過程復(fù)雜度統(tǒng)計有多少存儲過程、總代碼行數(shù)、用到了哪些Oracle獨有包DBMS_SQL、DBMS_JOB、DBMS_ALERT、UTL_FILE等。這部分改造成本往往被嚴重低估。我們項目里有1300多個存儲過程最終花了整個項目40%的工時在改寫上面。依賴關(guān)系應(yīng)用與數(shù)據(jù)庫的交互方式包括連接方式JDBC、OCI、ODBC、事務(wù)隔離級別、會話級參數(shù)設(shè)置、臨時表使用情況。應(yīng)用層的連接串、驅(qū)動、SQL寫法都要納入改造范圍。體檢報告出來后要讓業(yè)務(wù)方、DBA、開發(fā)三方一起評審明確哪些東西可以原樣遷哪些必須改造遷哪些是僵尸對象可以果斷拋棄。這一步做扎實了后面所有的方案才有依據(jù)。2. 低業(yè)務(wù)中斷的核心打法全量增量雙軌遷移2.1 遷移工具選型與取舍工具選型沒有標準答案核心看你的源庫版本、目標庫版本、數(shù)據(jù)總量、同步實時性要求和團隊熟悉度。我們當(dāng)時對比了三條路線Ora2Pg開源免費Perl寫的能把表結(jié)構(gòu)、數(shù)據(jù)、序列、視圖、存儲過程整體轉(zhuǎn)換支持直接連Oracle導(dǎo)出再導(dǎo)入PostgreSQL。優(yōu)點是自動化程度高缺點是大表導(dǎo)出用COPY方式對源庫有一定壓力而且存儲過程轉(zhuǎn)換質(zhì)量一般只能轉(zhuǎn)個骨架復(fù)雜邏輯基本還得人工改。pgloader同樣開源從Oracle讀數(shù)據(jù)到PostgreSQL非?？煊玫囊彩荂OPY協(xié)議支持并行加載。但DDL遷移能力弱主要用來搬數(shù)據(jù)。自研抽取同步腳本用Python寫一套基于JDBC的全量導(dǎo)出和增量抽取腳本配合調(diào)度平臺實現(xiàn)斷點續(xù)傳和數(shù)據(jù)校驗。靈活性最高但開發(fā)量不小。我們最終采用了Ora2Pg轉(zhuǎn)結(jié)構(gòu)pgloader搬全量自研增量同步腳本Debezium做變更捕獲的組合方案。結(jié)構(gòu)轉(zhuǎn)換用Ora2Pg生成初始DDL再人工修全量數(shù)據(jù)用pgloader并行加載增量部分考慮到源庫是Oracle 11gDebezium的Oracle插件要裝額外組件最后是自己寫了一套基于日志的增量抽取程序。這里給個建議如果是Oracle 12c及以上Debezium是較好的增量同步方案社區(qū)活躍且支持斷點續(xù)傳11g就得掂量掂量了。2.2 全量遷移的并行與限速策略全量數(shù)據(jù)遷移最容易翻車的地方是導(dǎo)太猛把源庫IO打滿業(yè)務(wù)直接告警導(dǎo)太慢又趕不上停機窗口。所以并行度和限速必須提前設(shè)計。我們按表維度拆分任務(wù)用了一個簡單的規(guī)則小于100萬行的表單表單任務(wù)順序執(zhí)行100萬到1000萬行的表按主鍵范圍拆成4到8個分片并行超過1000萬行的表按主鍵范圍拆成16到32個分片每個分片獨立連接、獨立事務(wù)。同時設(shè)置了全局并發(fā)上限保證源庫的活躍會話數(shù)不超過20。pgloader本身有個batch concurrency參數(shù)可以控制并行度但實測下來對Oracle源庫支持一般所以我更推薦自己寫一個簡單的調(diào)度器用一張任務(wù)表記錄每個分片的狀態(tài)調(diào)度線程從里面撈待執(zhí)行的任務(wù)分發(fā)給工作線程工作線程處理完更新狀態(tài)出錯自動重試三次還是失敗就進入人工處理隊列。這里有個非常關(guān)鍵的細節(jié)全量遷移必須在增量同步啟動之前完成并且要記錄全量導(dǎo)出的數(shù)據(jù)快照時間點。我們的做法是全量開始前先在源庫開啟歸檔日志和補充日志然后啟動增量抽取程序?qū)崟r解析日志寫入Kafka全量導(dǎo)出的每張表在導(dǎo)出前記錄一個SCNSystem Change Number快照導(dǎo)出完成后用這個SCN到增量同步里做數(shù)據(jù)拼接。這樣才能保證全量導(dǎo)出期間產(chǎn)生的增量變更不會丟。2.3 增量同步與業(yè)務(wù)雙寫設(shè)計增量同步的目標是讓PostgreSQL和Oracle的數(shù)據(jù)差距保持在分鐘級以內(nèi)這樣停機切換時只需要把最后幾分鐘的增量追上就能關(guān)窗口。我們的增量鏈路是Oracle歸檔日志 → LogMiner解析 → Kafka → 自研消費者程序 → 應(yīng)用到PostgreSQL。為什么用LogMiner而不是直接用OGG主要是因為OGG授權(quán)成本和部署復(fù)雜度在當(dāng)時的環(huán)境下不劃算。LogMiner有幾個坑要提前踩必須提前開啟最小補充日志Supplemental Log否則LogMiner拿不到更新前的字段值UPDATE語句沒法正確重放。LogMiner解析出來的DDL語句不能直接拿到PostgreSQL執(zhí)行需要做語法轉(zhuǎn)換比如ALTER TABLE xxx ADD (col NUMBER)要改成ALTER TABLE xxx ADD COLUMN col NUMERIC。大事務(wù)解析會產(chǎn)生大量Redo記錄LogMiner內(nèi)存可能扛不住要設(shè)置合理的UTL_FILE落地目錄分段讀取。增量應(yīng)用端的沖突處理也需要設(shè)計。雙軌運行期間如果應(yīng)用還在繼續(xù)寫Oracle我們的增量程序會把這些變更實時投遞到PostgreSQL兩邊數(shù)據(jù)保持一致。但如果某個時刻增量應(yīng)用出現(xiàn)問題、落后太多或者業(yè)務(wù)在驗證階段直接在PostgreSQL上面做了修改就會產(chǎn)生回環(huán)沖突。我們的策略是切換之前所有寫操作只走OraclePostgreSQL只接受增量投遞的歷史數(shù)據(jù)切換之后應(yīng)用層切到PostgreSQLOracle那邊不再接收業(yè)務(wù)寫流量。這套單向?qū)憽㈦p向讀的策略在切換前把沖突可能性降到最低。2.4 停機窗口內(nèi)的切換步驟清單就算增量同步再穩(wěn)定切換當(dāng)天也必須有SOP每一步到什么狀態(tài)、由誰確認都要提前定義好。我們的切換清單大概是這樣的業(yè)務(wù)側(cè)發(fā)布維護通知應(yīng)用層開啟只讀模式或直接停止寫流量等待增量同步追上確認Oracle和PostgreSQL的數(shù)據(jù)延遲為0停止Oracle側(cè)的寫操作記錄停止時間點增量程序消費完Kafka里所有消息應(yīng)用完最后一筆變更執(zhí)行數(shù)據(jù)校驗?zāi)_本下一節(jié)細說確認兩邊數(shù)據(jù)一致關(guān)閉增量同步程序防止PostgreSQL繼續(xù)接收Oracle的變更應(yīng)用層修改數(shù)據(jù)庫連接配置切換到PostgreSQL執(zhí)行一批關(guān)鍵的冒煙測試SQL確認核心業(yè)務(wù)功能正常觀察5到10分鐘確認無異常后對外宣布切換完成。整個切換過程耗時大概1.5小時算上全量數(shù)據(jù)校驗、應(yīng)用重連、緩存預(yù)熱最終停機窗口控制在3小時左右滿足4小時的要求。這里要注意第5步的數(shù)據(jù)校驗不能等全部跑完才判斷我們在切換前就做過多次全量預(yù)校驗在增量持續(xù)運行的情況下切換當(dāng)天只做增量部分的差異性校驗和隨機抽表比對。3. 數(shù)據(jù)校驗方案讓業(yè)務(wù)信服的三個層次3.1 第一層行數(shù)與總量校驗最基礎(chǔ)的校驗是行數(shù)比對。對每張表執(zhí)行SELECT COUNT(*)兩邊對不上就說明有問題。但COUNT在大表上很慢動輒幾分鐘甚至更久。我們當(dāng)時是用pg_comparison這類工具直接對比但更通用的做法是按主鍵范圍分段統(tǒng)計行數(shù)每段一個任務(wù)并行跑最后匯總。如果源表和目標表都沒有主鍵Oracle里確實存在這種爛表那校驗就只能退而求其次按所有字段做GROUP BY后再COUNT或者用COUNT(*)配合SUM(HASH)來粗查。這類表數(shù)量不多還好如果很多強烈建議在建表階段就幫它們補上主鍵或唯一約束否則后續(xù)的數(shù)據(jù)一致性驗證基本沒法做。行數(shù)校驗是必要條件但不是充分條件行數(shù)一樣不代表數(shù)據(jù)一樣所以還要做第二層。3.2 第二層字段級CRC校驗與哈希比對第二層是對每一行的所有字段拼起來做哈希兩邊比對哈希值是否一致。具體做法是在源庫Oracle寫一段SQL把每行需要比對的字段用DBMS_CRYPTO.HASH或STANDARD_HASH算出一個哈希值SELECT id, STANDARD_HASH(col1 || | || col2 || | || col3, SHA256) AS row_hash FROM my_table;在目標庫PostgreSQL用同樣的拼接規(guī)則算哈希SELECT id, encode(sha256(convert_to(col1 || | || col2 || | || col3, UTF8)), hex) AS row_hash FROM my_table;兩邊按主鍵關(guān)聯(lián)對比row_hash是否一致把所有不一致的主鍵ID撈出來交給業(yè)務(wù)確認。這里有幾個坑必須注意拼接字符串里的分隔符不能和字段值本身沖突。我一般用兩個特殊字符比如||~|~||并提前檢查字段值里是否包含這些字符。字段值里的NULL要統(tǒng)一處理。Oracle里空字符串就是NULL而PostgreSQL里空字符串和NULL是不同的。我們統(tǒng)一約定NULL或空串都替換成一個特殊標記比如NULL。浮點類型BINARY_DOUBLE、NUMBER帶小數(shù)在Oracle和PostgreSQL二進制存儲上有差異直接拼接字符串做哈?？赡艹霈F(xiàn)看起來一樣、哈希不一樣的誤報。處理方法是對數(shù)值類型先做格式化統(tǒng)一保留到小數(shù)點后6位或更多確保兩邊字符串一致。大數(shù)據(jù)量下表字段特別多時哈希計算會非常消耗源庫CPU。我們當(dāng)時在源庫用只讀快照或者備庫上跑哈希校驗避免影響生產(chǎn)。3.3 第三層業(yè)務(wù)規(guī)則抽樣比對哈希校驗?zāi)鼙ＷC技術(shù)層面的數(shù)據(jù)一致但業(yè)務(wù)方更關(guān)心他們用起來對不對。所以我們額外設(shè)計了一套業(yè)務(wù)規(guī)則的抽樣比對從核心業(yè)務(wù)表里隨機抽取若干個ID把該ID關(guān)聯(lián)的訂單、明細、流水全查出來業(yè)務(wù)方人工核對把一批統(tǒng)計報表SQL分別在Oracle和PostgreSQL上跑一遍比對聚合結(jié)果是否一致把幾個典型的復(fù)雜查詢多表關(guān)聯(lián)、子查詢、窗口函數(shù)在新庫上執(zhí)行業(yè)務(wù)方確認執(zhí)行結(jié)果和口徑符合預(yù)期。這個環(huán)節(jié)的意義不止于查數(shù)據(jù)還在于讓業(yè)務(wù)方建立對遷移結(jié)果的信任。技術(shù)團隊說一百句校驗過了不如業(yè)務(wù)方自己抽幾個單子確認來得踏實。3.4 校驗工具與自動化我們整個校驗體系是跑在一個自研的校驗平臺上的支持配置表清單、校驗類型、閾值和通知渠道。技術(shù)上不復(fù)雜核心就是一個任務(wù)調(diào)度器加一堆校驗?zāi)_本。不過如果你沒有自研條件有幾個現(xiàn)成工具可以參考pg_comparison專門做PostgreSQL與PostgreSQL/Oracle等多庫數(shù)據(jù)對比支持行數(shù)、全量、抽樣對比能輸出差異報告。DataGrip/DBeaver的數(shù)據(jù)對比功能適合小表、交互式核對不適合大批量自動化。xtc校驗工具一些開源實現(xiàn)里有基于CRC或MD5的文件級校驗?zāi)芰Φ苯佑迷跀?shù)據(jù)庫遷移上還是得改造。我的建議是工具只是輔助校驗方案和口徑才是核心。先把口徑和字段映射規(guī)則定義清楚工具只是幫你把規(guī)則跑起來。4. 可回退機制給業(yè)務(wù)一顆定心丸4.1 回退方案設(shè)計的兩種路線回退最理想的方案是雙活也就是切換后Oracle和PostgreSQL都保持可寫應(yīng)用層按比例把流量分攤到兩邊某一側(cè)出問題可以隨時把流量全部切到另一側(cè)。但雙活對數(shù)據(jù)一致性的要求極高寫入沖突處理的復(fù)雜度也很大普通項目很難真正做到。我們實際采用的是切換后保留源庫只讀反向同步增量的半雙活方案。具體來說切換時Oracle側(cè)停止業(yè)務(wù)寫入但數(shù)據(jù)庫實例不關(guān)閉歸檔日志繼續(xù)保留切換后增量同步程序反向工作監(jiān)聽PostgreSQL的變更用PostgreSQL的邏輯復(fù)制功能把變更同步回Oracle如果業(yè)務(wù)驗證期間發(fā)現(xiàn)重大問題需要回退我們先把PostgreSQL寫入停止等最后一批變更同步到Oracle然后應(yīng)用連接切回Oracle就能在較短時間內(nèi)恢復(fù)服務(wù)。這個方案的關(guān)鍵在于反向同步的可靠性和時延。PostgreSQL的邏輯復(fù)制Logical Replication機制比較成熟但把邏輯復(fù)制的變更重放到Oracle端還是得靠自研程序或中間件。我們當(dāng)時是寫了一個消費者從PostgreSQL的WAL里解析出變更再合成SQL語句應(yīng)用到Oracle。這里有個現(xiàn)實問題PostgreSQL邏輯復(fù)制默認只適合PostgreSQL到PostgreSQL跨庫重放得自己處理類型映射和SQL方言差異工作量不小。4.2 回退窗口與觀察期設(shè)計回退不是無限期的業(yè)務(wù)方也不能想什么時候退就什么時候退。我們在項目計劃里明確了一個回退觀察期切換后一個月內(nèi)業(yè)務(wù)如果發(fā)現(xiàn)重大數(shù)據(jù)或功能問題啟動回退流程超過一個月認為遷移已經(jīng)穩(wěn)定不再支持自動回退Oracle源庫進入只讀歸檔狀態(tài)。這個觀察期不是隨便定的是根據(jù)業(yè)務(wù)體量和風(fēng)險容忍度協(xié)商出來的。觀察期越長反向同步的維護成本和資源成本越高太短業(yè)務(wù)不放心。我見過有些項目觀察期只有一周結(jié)果第四天暴雷回退的時候反同步數(shù)據(jù)量太大差點沒退干凈。一般來說業(yè)務(wù)量大的核心系統(tǒng)觀察期建議不低于兩周最好是一個月非核心系統(tǒng)可以適當(dāng)縮短。4.3 回退演練不能等到出事才練回退方案寫了幾頁紙但真正出事的時候能不能按流程執(zhí)行只有練過才知道。我們在正式切換之前做了兩次完整的回退演練每次都能暴露問題。第一次演練暴露出一個經(jīng)典問題切換后業(yè)務(wù)在PostgreSQL上生成了大量新數(shù)據(jù)回退時要把這些數(shù)據(jù)反向同步回Oracle結(jié)果因為表結(jié)構(gòu)里有個字段類型映射不一致導(dǎo)致批量INSERT失敗。這類問題如果不演練真到回退的時候就是災(zāi)難。第二次演練我們提前修正了映射又測了流量切換的腳本確認應(yīng)用重啟后能讀到Oracle的最新數(shù)據(jù)整個回退耗時控制在40分鐘內(nèi)。所以我的建議是回退演練必須包含數(shù)據(jù)層和應(yīng)用層兩層驗證。數(shù)據(jù)層驗證反向同步是否完整、一致應(yīng)用層驗證連接切換、緩存清理、配置修改是否順利。只測數(shù)據(jù)不測應(yīng)用回退后業(yè)務(wù)還是起不來。5. 常見問題與排查技巧實錄整個遷移過程中我們踩過的坑和排查過的問題不少挑幾個有代表性的寫在這里供大家參考。5.1 Oracle的CONNECT BY在PostgreSQL里怎么改Oracle的層次查詢CONNECT BY PRIOR是遷移的高頻改造點。PostgreSQL沒有直接對應(yīng)的語法要用遞歸CTEWITH RECURSIVE改寫。比如Oracle里SELECT emp_id, mgr_id, LEVEL FROM emp START WITH mgr_id IS NULL CONNECT BY PRIOR emp_id mgr_id;改成PostgreSQLWITH RECURSIVE emp_tree AS ( SELECT emp_id, mgr_id, 1 AS level FROM emp WHERE mgr_id IS NULL UNION ALL SELECT e.emp_id, e.mgr_id, t.level 1 FROM emp e JOIN emp_tree t ON e.mgr_id t.emp_id ) SELECT emp_id, mgr_id, level FROM emp_tree;這里注意遞歸CTE的性能調(diào)優(yōu)空間比較大如果樹的深度和寬度都很大比如超過10層、幾十萬節(jié)點建議提前用真實數(shù)據(jù)量壓測必要時加search_depth之類的優(yōu)化手段。5.2ROWNUM和ROW_NUMBER()的等價改寫Oracle里用ROWNUM做分頁很常見SELECT * FROM ( SELECT t.*, ROWNUM rn FROM big_table t ) WHERE rn BETWEEN 101 AND 200;PostgreSQL里直接用LIMIT/OFFSETSELECT * FROM big_table ORDER BY id LIMIT 100 OFFSET 100;這里有個容易踩的隱形坑Oracle的ROWNUM是在排序之前生成的所以如果原SQL里寫了ORDER BY再套ROWNUM語義上是先取前N行再排序和PostgreSQL的LIMIT語義先排序再取前N行不一樣。改寫時必須先確認原SQL的業(yè)務(wù)意圖不然數(shù)據(jù)就錯了。5.3 CLOB字段遷移到TEXT后的性能問題Oracle的CLOB在PostgreSQL里一般對應(yīng)TEXT類型。看起來簡單但實測發(fā)現(xiàn)一個現(xiàn)象某些業(yè)務(wù)對CLOB字段做頻繁的UPDATE和SELECT在Oracle里有專門的LOB段和空間管理性能還行到PostgreSQL的TEXT上如果寫入的文本很大幾十KB到幾MBTOAST機制會觸發(fā)壓縮和外部存儲性能會有波動。我們的處理辦法把大文本字段單獨拆到一張擴展表里和主表用外鍵關(guān)聯(lián)需要時才JOIN出來。如果業(yè)務(wù)確實要頻繁讀寫大文本還可以把external存儲打開避免每次查詢都加載整個大字段。5.4 空字符串與NULL的語義差異Oracle里和NULL是等價的SELECT NVL(, x) FROM dual返回x。PostgreSQL里不是NULL。這一條差異在數(shù)據(jù)遷移時特別容易產(chǎn)生臟數(shù)據(jù)。我們在校驗階段發(fā)現(xiàn)不少表的某些字段兩邊值看起來不一致查了半天才發(fā)現(xiàn)是源庫存在空字符串遷移時我們統(tǒng)一轉(zhuǎn)換成了NULL但業(yè)務(wù)代碼里有用判斷的邏輯導(dǎo)致行為變了。后來我們定了規(guī)范Oracle到PostgreSQL遷移時空字符串按照Oracle語義統(tǒng)一轉(zhuǎn)NULL同時業(yè)務(wù)代碼里所有 的判斷改為IS NULL。這個規(guī)范在改造階段就要同步給開發(fā)團隊。5.5 分區(qū)表遷移的正確姿勢Oracle的分區(qū)表遷移到PostgreSQL有幾種方案用PostgreSQL原生分區(qū)表基于聲明式分區(qū)或者用繼承分區(qū)或者用pg_partman這類擴展。我們的經(jīng)驗如果分區(qū)數(shù)量不大幾十到幾百個用原生聲明式分區(qū)就夠了如果分區(qū)數(shù)量上千原生分區(qū)的元數(shù)據(jù)管理會有壓力可以考慮用pg_partman管理自動建分區(qū)。遷移時的一個常見坑Oracle分區(qū)表的全局索引和分區(qū)索引在PostgreSQL里沒有完全對應(yīng)的概念需要根據(jù)業(yè)務(wù)SQL的過濾條件重新設(shè)計索引策略。不要照搬Oracle的索引結(jié)構(gòu)否則查詢性能會很差。5.6 序列遷移的斷檔問題Oracle的SEQUENCE不保證連續(xù)PostgreSQL的SEQUENCE也一樣。但兩邊序列的CACHE和INCREMENT配置不同步可能導(dǎo)致ID沖突或斷檔。我們遷移時把Oracle序列的LAST_NUMBER和INCREMENT_BY記錄到PostgreSQL序列的同名參數(shù)上還要考慮增量同步階段兩邊應(yīng)用各拿各的序列號等切換后PostgreSQL序列起始值必須比Oracle當(dāng)前值大很多否則切過來后新生成的ID可能和同步回來的歷史數(shù)據(jù)撞車。這個問題真的很隱蔽但如果爆了就是主鍵沖突直接拖垮切換。建議切換前用腳本檢查所有序列的當(dāng)前值確保PostgreSQL側(cè)的值遠高于Oracle側(cè)。5.7 常見問題速查表問題現(xiàn)象常見原因排查/處理辦法校驗時哈希不一致字段拼接順序不一致、NULL/空串沒統(tǒng)一、浮點精度差異統(tǒng)一拼接規(guī)則字段值做標準化增量同步延遲持續(xù)增大Kafka消費能力不足、目標庫應(yīng)用能力差、大事務(wù)卡住增加消費者并行度排查大事務(wù)必要時手動補數(shù)切換后應(yīng)用報驅(qū)動錯誤JDBC連接串或驅(qū)動版本不兼容Postgres JDBC驅(qū)動與Oracle JDBC驅(qū)動用法不同檢查URL參數(shù)、schema設(shè)置存儲過程執(zhí)行失敗PL/SQL和PL/pgSQL語法差異人工改寫重點處理游標、動態(tài)SQL、異常處理查詢性能嚴重下降統(tǒng)計信息未收集、索引缺失、優(yōu)化器差異切換后立即執(zhí)行ANALYZE根據(jù)執(zhí)行計劃補索引回退時反向同步失敗類型映射不一致、主鍵沖突、循環(huán)依賴提前演練建立主鍵沖突處理規(guī)則類型映射表要用同一份我自己走完這個項目后最深的體會是數(shù)據(jù)庫遷移拼的不是單點技術(shù)有多強而是流程管理和風(fēng)險把控。這三個目標——低中斷、可校驗、可回退——每一個都對應(yīng)著一整套方案和工具鏈而它們之間又互相影響。建議準備動手的朋友先把你現(xiàn)有的停機窗口、數(shù)據(jù)量、業(yè)務(wù)容忍度都擺出來用這些邊界條件去倒推每一步該怎么做。方案設(shè)計得越細執(zhí)行的時候才越穩(wěn)。再補充一點遷移過程中所有腳本和命令一定要先在小環(huán)境里完整演練一遍帶上真實數(shù)據(jù)量的1%到5%壓測一下性能別等到正式切換才發(fā)現(xiàn)導(dǎo)出速度、校驗耗時、增量延遲這些數(shù)字完全不可控。