大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。
七月的可信数据库大会，信通院发了两个东西：数据库产业图谱，还有关键行业的AI数据库攻坚计划。有个判断传得很广：国产数据库已完成外围替代，正式攻坚核心业务系统。
作为做过几轮迁移的人，我听到这句，心里咯噔一下。这句话，份量比听上去重得多。外围好换，核心难啃，这不是一句话能带过的。今天把攻坚核心系统的卡点，从我的实战角度拆开讲。看完你就明白，最后一公里到底难在哪。我自己也还在迁移这条路上，边走边学。
一、外围替换完了，核心为什么难
先看替换的进程。外围系统，OA、门户、报表、档案，这类系统并发低、逻辑简单，标准SQL就能跑。替换它们，数据库团队加应用团队，几个月就能完事。
核心系统不一样。交易、账务、计费、生产制造，一个都轻不起来。并发高，可用性要求苛刻，还堆满了十多年攒下来的存储过程。动它们，等于在高速路上换轮胎。我把外围和核心拉了个表，差异一目了然。
| 维度 | 外围系统 | 核心系统 |
|---|---|---|
| 典型系统 | OA、门户、报表、档案 | 交易、账务、计费、生产 |
| 并发压力 | 低 | 高 |
| 可用性要求 | 可容忍短中断 | 秒级切换，RPO趋零 |
| 兼容性深度 | 标准SQL够用 | 存储过程、高级特性 |
| 替换风险 | 低 | 高，切换要演练 |
核心系统的难，难在它不是"能不能跑"，是"跑得稳不稳"。外围系统跑挂了，顶多内部骂两句。核心系统跑挂了，是事故，是追责。这个差别，决定了整个项目的打法。
二、卡点一：兼容性，存储过程是重灾区
核心系统用了十几年，代码量最大的是什么？存储过程、函数、包、触发器。这些东西是Oracle或者老版本数据库写的，迁移过去不是复制粘贴就能跑。
迁移第一步，先把对象盘清楚。我用这条SQL把要处理的代码对象数了一遍，数量出来，工作量心里就有数了。这一步别省，后面全靠它排期。
-- 迁移前：先盘出有多少需要处理的代码对象
SELECT object_type, COUNT(*) AS cnt
FROM dba_objects
WHERE owner = '业务库'
AND object_type IN ('PROCEDURE','FUNCTION','PACKAGE','TRIGGER','VIEW')
GROUP BY object_type;
盘完你就知道了。一个核心库，几百个存储过程是常态。每个都要过一遍，改一遍，测一遍。这还只是存储过程，函数和包还没算。
改的过程，坑都在细节。%TYPE这种Oracle独有的写法，在部分国产库中需要改成显式类型，具体取决于目标库的兼容能力。SYSDATE、NVL、字符串拼接，各家兼容程度不一样。隐式游标、自治事务、COMMIT行为，都得逐条验证。我整理了一个改写要点，贴出来。
-- Oracle存储过程改写要点（具体改写方式取决于目标库的兼容能力）
-- 以下示例以完全不兼容%TYPE的国产库为例
CREATE OR REPLACE PROCEDURE p_recalc(p_id NUMBER) AS
-- %TYPE：Oracle独有，部分国产库需改写为显式类型
v_qty stock.qty%TYPE;
-- SYSDATE：部分库不兼容，改写为标准函数
v_ts DATE := SYSDATE;
BEGIN
SELECT qty INTO v_qty FROM stock WHERE product_id = p_id;
-- NVL：改写为COALESCE（标准SQL）
v_qty := NVL(v_qty, 0);
-- 隐式游标、自治事务、COMMIT行为，都要逐条验证
UPDATE stock SET qty = v_qty + 1 WHERE product_id = p_id;
COMMIT;
END;
光存储过程这一项，占了整个迁移工作量的一半。这不是夸张，是实话。很多人低估了它，排期就崩在这，我吃过这个亏。
三、卡点二：高可用与容灾
核心系统第二个硬要求，高可用。外围系统允许短中断，核心系统要秒级切换，数据要趋零丢失。这是底线，不是加分项，迁移方案要按这个标准来设计。
RPO和RTO，是核心系统绕不开的两个词。RPO趋零，意味着主备数据要实时一致，不能靠定时备份。RTO要短，意味着故障切换要快，最好是自动的。这两个指标，迁移前就要明确。
迁移不是换掉数据库就完事。主备架构、容灾方案、切换演练，都要在新环境重新搭一遍。演练不是做一次，是定期做，做到条件反射。真到切换那天，才不会手忙脚乱。
我见过最怕的事，是迁移完了，容灾演练一次都没做过。真出故障，切换脚本能不能用都不知道。这种侥幸，早晚要还的。所以我一直把演练当必做项。
四、卡点三：性能与调优工具
核心系统并发高，对性能的要求是实打实的。同样的SQL，在Oracle上走索引，换到国产库，执行计划可能就变了。这不是谁差，是优化器算法不同。差异要一条条实测确认。
很多SQL要重新看执行计划，重新调优。慢查询、锁等待、连接池参数，全部要重新压测。我习惯建一张对比表，逐条记录差异。
工具链也是一块。监控、诊断、备份恢复、巡检，外围系统用的那套，核心系统不一定够用。新环境要有对应的工具和SOP，不然出了问题，连定位都慢。工具这个账，常在预算里被漏掉。
五、卡点四：生态与人才
最后一个卡点，是人。
国产库的生态在长，但DBA大部分经验还是老库的。存储过程怎么调优、死锁怎么定位、备份怎么排，都要重新学一遍。这不是一个人学，是一个团队学。
企业层面的账也要算。迁移期间，两套系统并行，一套老库一套新库，数据要同步，运维要双倍人力。这个成本，很多人没算进去。算进去之后，工期和预算都要重估。
但反过来看，这也是机会。会国产库迁移的DBA，现在是稀缺的。技能会过时，但迁移这件事本身，是能练出真本事的。踩过的坑，就是简历上的加分项。
前面说的都是准备和资源，最后一步是执行。切换这一下，才是真正见真章的地方。
六、切换这一下，最考验人
核心系统的切换，不是断掉老库、起新库就完事。这一步，前面所有准备都在这里兑现。做不好，前面全白干。
成熟的做法是双轨并行。新老库同时跑，数据实时同步，业务灰度切。先切一部分用户，观察稳定了，再全量。整个过程，要有随时回滚的预案。
我参与过的一次切换，凌晨开始，切完观察了一整天，才敢说成功。全程手都在抖。核心系统切换，容错空间非常小。一次失误，前面几个月的准备都要重来。
七、我的判断
信通院说攻坚核心业务系统，方向是对的，也是必须的。国产数据库的技术成熟度，这几年确实上来了。电科金仓、OceanBase这些头部厂商，都在核心系统上下了重注。这个趋势，不是宣传，是实打实的投入。
但攻坚不是发布会，是一场一场硬仗。兼容性、高可用、性能、生态，每一项都要厂商、ISV、用户一起磨。AI数据库攻坚计划把AI能力融进国产库，是给这场硬仗加火力。方向没错，剩下的是时间。
我的判断是，未来两三年，是国产数据库攻坚核心系统的窗口期。对DBA来说，这个窗口里最值钱的技能，是迁移实战经验。会迁移、会调优、能扛切换的人，会很抢手。我自己的经验，也是这么一点点攒出来的。
八、避坑清单
别拿外围系统的迁移经验套核心系统。外围几个月能完事，核心要按年算。工作量、风险、成本，都要重新评估。我见过团队按外围的工期排核心的活，最后全延期。
存储过程改写别只看语法对不对。语法过了，行为可能还是不一样。NULL的处理、日期格式、排序规则、并发下的结果，都要用数据对比验证。我踩过，NVL改COALESCE以为万事大吉，结果Oracle里空字符串等同于NULL，国产库把空字符串和NULL分开处理，行为就不一样了。
切换前必须做容灾演练，而且要多做几次。演练不是走过场，是发现切换脚本里的坑。真出故障再发现，代价是事故。我把演练当成上线前的必做项，一次都不能省。
你们团队在做核心系统国产化吗？碰到的最大的坑是什么？欢迎评论区聊聊。我猜很多人会说存储过程，评论区见分晓。
我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋
