大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。
上个月团队接了个去O的活，让我先盘家底。系统清单拉出来，二十多个库，一大半还跑在Oracle 11g和12c上。这两个版本早就停服了，没补丁，出了问题没法兜底。报告交上去那天，领导问了一句：这些库2027前都得换完，排期怎么给？说实话，我给不出来。不是不知道工作量，是不知道同行走到哪了。快的是不是已经切完核心了，慢的还在外围打转？自己算快还是算慢，心里真没数。
这篇就聊三件事。政策时间线怎么定的，六大行业各自走到哪了，剩下的硬骨头怎么啃。数据标了出处，你可以自己再核。
一、2027 卡的不是同一条线
先把坐标定准。2022年9月底，国资委下发79号文，要求国央企在2027年底前完成信创替代。文件把替代对象分了三个梯度：
| 梯度 | 覆盖系统 | 推进节奏 |
|---|---|---|
| 全面替换 | OA、门户、邮箱、档案、经营管理系统 | 基本完成 |
| 应替尽替 | ERP、CRM、风控、战略决策支持 | 高峰期 |
| 能替尽替 | 生产制造、软件研发平台 | 起步到加速 |
所以2027不是一夜全切，是分梯度的完成线。数据库跟着这条线走，办公类的库早换完了，ERP换到一半，核心交易系统才刚起步。另一条线来自Oracle自己，这条很多人没算进去。
| Oracle 版本 | Premier 支持结束 | Extended 支持结束 | 当前状态 |
|---|---|---|---|
| 11g R2 | 2015-01 | 2020-12 | 已停服 |
| 12c R1 | 2018-07 | 2022-07 | 已停服 |
| 12c R2 | 2022-03 | 不提供 | 已停服 |
| 18c | 2021-06 | 不提供 | 已停服 |
| 19c | 2029-12 | 2032-12 | 支持中 |
11g R2的扩展支持2020年底就到期了，12c、18c也全部停服。我手上那二十多个库，全落在这个区间里。另一头，Oracle自己也在收缩。据公开报道，2026财年裁员约2.1万人，员工总数从约16.2万降到14.1万，中国区参保人数降了约55%。
IDC 数据显示，2025年国内本地部署数据库市场，国产厂商份额已到71%，但金融核心场景里Oracle还占约三成。两条线叠在一起，2027就不只是政策节点了，存量 Oracle的安全、成本、架构，三笔账一起到期。
二、六大行业，各自走到哪了
先看全景。这张表是多家研报口径的交叉结果，同行业不同来源有出入，我取了区间。
| 行业 | 替代进度 | 卡在哪 |
|---|---|---|
| 党政 | 约 80%，接近尾声 | 社保、税务等核心政务 |
| 金融 | 非核心超 50%，核心约 15% | 核心交易、账务、跑批 |
| 电信 | 核心系统突破中 | 计费、网间结算 |
| 能源 | 不足 15% | 调度、集控 |
| 制造 | 不足 5% | 多实例整合 |
| 医疗教育 | 不足 5% | HIS 的 HTAP 需求 |
党政进度最快，替换率约80%。OA、公文流转、信息报送基本换完了，剩下社保经办、税务征收、行政审批，这几类复杂得多。这里有个可查的案例：某中央政府机关核心系统从Oracle 11g RAC迁到国产数据库，涉及8000多张表、3000多个视图、230多个存储过程和函数，自动化迁移率99.6%。这个数字有意思的不是高，是大批量对象已经不靠人力堆了。
再来看金融，这个行业最硬。国泰君安研报测算，银行业非核心系统替换比例已突破50%，核心系统还在15%左右，证券和保险的核心系统低于20%。招商证券的口径更直白：金融行业海外数据库仍占主导，Oracle约 55%，DB2约 19%。政策目标是2027年金融渗透率超70%，从15%到70%，中间隔着核心交易和账务。金融核心难在哪？RAC共享存储架构，普通主备顶不上；日终跑批窗口卡死，慢一分钟就是事故；账务一致性不允许有分毫差错。
接着看电信，进度仅次于金融。三大运营商都在CRM、BOSS、账务中心做了替换，招商证券数据显示，核心网替换后事务处理能力提升35%，授权成本降低50%。据公开资料，中国移动部署了约2000套国产数据库，覆盖21个机构。电信对厂商长期服务能力的要求比多数行业更严，这种量级的运维，一锤子买卖接不住。
能源的替代率最低，案例却最硬。电力调度这种系统，停一秒都是事故。国家电网智能电力调度系统用KingbaseES覆盖26个网省公司，据公开资料已稳定运行十余年，日均处理遥测数据超20亿点。某省调D5000系统的迁移涉及387个PL/SQL存储过程、2100多条含CONNECT BY的层级查询SQL，迁完零语法报错、零逻辑偏差。山东、河南电力的智慧计量工控系统，迁移时9小时跑完了6.8T全量数据。在这种不能停的系统上跑十年，比什么测试报告都有说服力。
制造业慢一拍，需求最实在。Oracle常和MySQL混用，多实例、多套系统是常态。他们还想借机整合，把几十个实例收进一个集群。选型看多实例纳管和运维效率，别只看跑分。
医疗教育刚起步，替换率不足5%。HIS既要跑事务又要做实时分析，对HTAP有硬需求，教育受预算周期影响，节奏更缓。这两类我的建议一样：先动外围，别急着碰核心。
三、Oracle 比 MySQL 难在哪
MySQL换库，难点在应用层。Oracle换库，难点在数据库自己身上。先说代码对象的量级：MySQL用户存储过程用得少，业务逻辑大多写在应用里；Oracle用户十几年攒下来的PL/SQL动辄几百个，还带着Package、触发器、DBMS_JOB调度。动手前先盘清楚有多少对象，这条SQL我每个项目都先跑：
SELECT object_type, COUNT(*) AS cnt
FROM dba_objects
WHERE owner = '订单库'
AND object_type IN (
'PROCEDURE','FUNCTION',
'PACKAGE','PACKAGE BODY','TRIGGER'
)
GROUP BY object_type
ORDER BY cnt DESC;
数量出来只是第一步，真正定工期的是业务依赖度。上千行的存储过程可能早没人调了，十几行的触发器却卡在核心链路上，得拉着业务一起过调用链。
再说架构。Oracle RAC是共享存储集群，多节点同时读写同一份数据，换成普通主备是架构降级，性能和可用性都往下走。要平移，目标库得有对应的共享存储集群方案，多节点同时读写一份数据，RPO能压到零，RTO在10秒以内。这两个数是我在RAC替换项目里最先问的，问不清楚，方案就不敢往下写。
最后是隐性行为差异，也是最坑的一层。语法能过，行为不一定对，看这段改写：
-- Oracle 写法：引用列类型
v_qty orders.qty%TYPE;
-- 兼容度不足时的改写：显式声明
v_qty NUMBER(18,2);
NUMBER不指定精度时是任意精度，迁过去容易溢出。VARCHAR2的长度按字节还是按字符算，取决于原库字符集。Oracle的DATE自带时分秒，时区处理稍有不慎，报表分组就错位。空字符串在Oracle里等同于NULL，有些库把这两个分开处理。这些都是"能跑但结果不一样"的坑，语法扫描扫不出来。
兼容度上补一句。金仓是我用过的国产库里，PL/SQL这一块做得比较深的。某省级电网项目的实测数据是，超90%的 SQL、近九成PL/SQL可以零修改迁移。但得清醒：剩下那一成，才是吃人力的地方。
四、去O迁移五步法
前面讲进度和难点，这段讲动作。我把经手过的项目拆成五步，每一步都有交付物。
第一步，兼容性评估。工具全量扫描源库，把对象分成三类：直接兼容、小改可用、需要重构。KDMS我在项目里用过，报告会直接给出改造清单和难度分级，红色对象有多少，项目周期基本就定了。
第二步，代码改写。别平均用力，按调用频次和业务重要度排序，先改高频链路。每个改过的对象配一组回归用例。
第三步，全量数据迁移。结构先迁，数据后迁，LOB这类大字段单独跑批处理工具，别指望一把梭。
第四步，增量同步。这一步决定割接窗口能做多小。金仓异构数据同步软件（KFS）基于日志解析抓变更，业务不用停。山东电力的案例里，KFS同步速率提升4倍，700GB的日增量做到了秒级延迟。
第五步，割接与验证。割接前配双向同步，留一条回退通道。验证分三层：行数核对、字段抽样比HASH、核心流程跑通。三层都过了才算迁完。
这五步里，第三步和第五步最容易出问题，也最容易被压工期。压掉的，通常割接当晚还回来。
五、你的库排第几批
开头那个排期，我确实给不出来，但优先级能排。三个问题过一遍，顺序就出来了。第一个问题：这套库还在支持期吗？对照前面的停服表，11g、12c上的库风险是现成的，19c还有几年缓冲，但缓冲期是拿来准备的，不是拿来拖的。
第二个问题：它属于哪个梯度？全面替换类的，2027前必须动；应替尽替类的，排在高峰期；能替尽替类的，看资源和时机。第三个问题：它在核心链路吗？这决定了你要不要共享存储集群这一级的架构，不在核心链路的，先换外围练手就够。三个问题交叉，四类系统的顺序就清楚了，资源先压到最急的那一类。
选型阶段我很少看广告，一般只问三件事：这个产品有没有在核心生产系统上连续跑很多年，测试环境拿奖不算数；迁移工具链完不完整，评估、迁移、同步、校验缺一环都要人力补；厂商服务网络在不在本地，响应时效写不写进合同。三条问下来，候选名单一般就剩两三个了，这时候再谈产品细节才有效率。
六、避坑清单
最常被跳过的是兼容性评估。直接装工具开跑，几百个存储过程会教你做人，返工的成本比评估高得多。也别只看语法过不过，要看行为对不对，类型精度、字符长度、时区处理、空值语义，都是"能跑但结果不一样"。
别把 RAC 当普通主备迁，省下来的事会在业务高峰期加倍还回去。别漏掉应用层，JDBC 驱动、ORM 方言、连接池参数，数据库迁完应用连不上，等于白干。
最后一条，也是最贵的一条：回退预案别写成文件就完事，得真跑一遍。练过和没练过，割接那晚是两种心态。
写在最后
2027年这道线，一头是政策，一头是Oracle自己的支持周期，两条线一起压过来，能腾挪的时间不多。我经手的项目里，推得动的都是同一个路子：先扫兼容性，拿到评估报告，把"大概能迁"变成"多少对象要改、分几级难度"，有了这张纸，排期和预算才有得谈。
金仓是我在电力、能源、制造类项目里接触比较多的一个，对Oracle兼容做得深，迁移工具链齐，核心系统上也跑了十几年。手里有存量系统要动的，先扫一遍兼容性，用数据说话，比听谁都说自己行要实在。
你们公司的 Oracle 系统排到第几批了？卡在哪一环？评论区聊聊。
我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋
