各位，我是老张。
去年帮一个制造业客户做信创迁移评估。对方跑了十几年Oracle，存储过程加包体大概二十万行。
选型会上，几家厂商都说自己"高度兼容Oracle"。
客户很聪明，没信宣传，直接扔了一段存储过程过来让我们各家用自己的产品跑一遍。
那段过程不算复杂，用到了自治事务、DBMS_OUTPUT包、还有个嵌套的EXCEPTION处理。
结果呢？几家测下来，完全跑通的不多。有的语法报错，有的语法过了但返回结果不对，还有的在异常路径上行为和Oracle对不上。
这件事对我触动挺大。Oracle兼容性不是厂商宣传页上打个勾就完事的。这道关过不去，后面的性能、价格都白谈。
后来我们用同一段存储过程测了几个国产数据库，其中一家跑通了，结果和Oracle一致。当时我还挺意外，后来才搞明白它在PL/SQL兼容上下了真功夫。具体怎么做到的，后面拆兼容性框架的时候细说。
一、Oracle兼容，到底兼容什么？
很多人说"兼容Oracle"，以为就是SQL语法能跑通。这个理解太浅了。
Oracle兼容性分三层。
第一层：语法兼容。SQL解析器能认Oracle的语法扩展。CONNECT BY、ROWNUM、DECODE函数、(+)外连接写法这些，属于语法层的东西。
第二层：语义兼容。同样的SQL，执行结果必须一样。比如NULL在Oracle里的排序行为、VARCHAR2的空字符串处理、NUMBER类型的精度规则，这些都属于语义层。
第三层：行为兼容。边界场景、异常路径、并发语义，全都得对齐。自治事务的隔离行为、包变量的生命周期、触发器的执行顺序、SAVEPOINT的回滚粒度——这些东西在文档里可能只有一句话，但迁移的时候一个对不上就够排查三天。
说白了，语法兼容解决"能不能跑起来"的问题。但跑起来不等于跑对，语义兼容管的就是这个。再往下，边界场景和异常路径能不能和Oracle对齐，那是行为兼容的活儿。
三层都过关，迁移才有可能顺利。
说到底，验证这件事靠人工逐条测SQL忙不过来。比较靠谱的做法是：拿生产环境的真实SQL负载做回放对比，而不是挑几条示例SQL跑一遍就下结论。思路务实的话，语法扫描、负载回放、反向适配三层都做工具支撑，验证效率比手动测高一个量级。
二、兼容性评估矩阵：四个核心维度
根据我参与过的几个迁移项目，整理了一个评估矩阵。选型的时候可以从这四个维度去对比。
| 维度 | 考察要点 | 兼容性低的后果 |
|---|---|---|
| PL/SQL引擎 | 存储过程、函数、包体、触发器、自治事务、异常处理 | 存储过程全部重写，改造成本占迁移总工作量60%以上 |
| SQL方言扩展 | CONNECT BY、MODEL子句、PIVOT/UNPIVOT、正则函数、分析函数 | 复杂查询需要改写SQL，报表类应用受影响大 |
| 数据类型映射 | NUMBER精度、VARCHAR2空串处理、DATE含时间、RAW/BLOB、XMLType | 数据类型不匹配导致精度丢失或隐式转换报错 |
| 内置包与工具 | DBMS_OUTPUT、DBMS_LOB、DBMS_SCHEDULER、UTL_FILE、DBLink | 运维脚本和调度任务全部失效，DBA工作方式要重建 |
这里面PL/SQL引擎的权重最大。原因很现实——企业级Oracle应用里，存储过程和包体往往承载了大量业务逻辑。PL/SQL兼容度不高，意味着业务逻辑要从数据库层抽出来改写到应用层。这个工程量，在百万行级的系统里，可能要半年以上。
来看一个实际的评估对照：
| 兼容维度 | 兼容度高 | 兼容度中等 | 兼容度低 |
|---|---|---|---|
| PL/SQL引擎 | 存储过程直接运行，少量适配 | 需要修改30%左右的包体代码 | 基本需要全部重写 |
| SQL方言 | Oracle特有语法可直接使用 | 部分语法需替换，复杂查询需改写 | SQL基本都要改 |
| 数据类型 | 类型映射完整，隐式转换一致 | 需要手动处理类型转换 | 存在精度丢失风险 |
| 内置包 | 核心包支持，覆盖常用场景 | 部分包支持，需要替代方案 | 不支持，需应用层兜底 |
市面上做得相对成熟的，像KES，在PL/SQL引擎和SQL方言这两块的兼容度比较高。比如CONNECT BY这类Oracle特有语法不用改写，直接跑。存储过程、包体、自治事务的支持接近Oracle原生行为，改造量能控制在较小范围内。选型阶段用实际代码跑一遍验证，比看宣传材料靠谱得多。
三、迁移的真正难点：四个现实考量
说完技术评估，聊聊实际迁移中经常被忽略的问题。
1. 应用改造成本才是大头
很多人选型时盯着数据库License的价格看。说句实话，License费用在迁移总成本里可能只占两成。
大头是应用改造。
一个跑了十年的Oracle系统，里面有多少业务逻辑藏在存储过程里？有多少报表用了CONNECT BY做层级查询？有多少批处理任务依赖DBMS_SCHEDULER？这些东西不梳理清楚，选型就是盲选。
一个常见的估算方法：统计PL/SQL代码行数，乘以兼容性不匹配的改造比例，再乘以每行改造的人天成本。这个数字往往比数据库采购成本高出一个数量级。
2. DBA的迁移成本
Oracle DBA的知识体系是围绕Oracle构建的。AWR报告、ASH分析、执行计划解读、RMAN备份恢复，这些技能在新平台上不能说完全作废，但至少要重新学一套。
选型的时候要评估两件事：新数据库的运维工具链是否成熟，DBA团队需要多久能独立上手。
KES在这方面做了不少工作。KOPS/KEMCC统一管控平台，界面逻辑和Oracle OEM比较像，监控告警、备份恢复、性能诊断都有。KStudio开发工具支持PL/SQL调试，交互方式和Oracle SQL Developer接近。DBA上手不用从头学，而是在熟悉的范式下逐步适应。
培训方面，金仓有KCA/KCP认证体系，从入门到专家覆盖，快的个把月就能独立上手基础运维。
3. 生产切换的风险窗口
信创迁移不是开发环境跑通就完事了。生产环境里那些边界场景，并发锁竞争、长事务回滚、大对象读写、跨库事务，只有切到生产才能真正暴露。
兼容度高的数据库，这些场景的行为和Oracle接近，风险相对可控。兼容度低的，切换窗口可能要拉长到原来的两三倍。
4. 兼容性会随版本迭代收敛
最后一点可能和直觉相反。
兼容性不是一成不变的。国产数据库这两年版本更新很快，每个大版本都在补Oracle兼容性的缺口。选型时兼容度一般的，两年后可能就补得差不多了。
但问题是：你的迁移窗口等不等得起？
如果项目有明确的信创时间要求，选一个当前兼容度就达标的方案，比赌一个未来版本的兼容性承诺更稳妥。
四、一个选型决策框架
说回实操，给各位一个选型的决策框架。
第一步：盘点现有Oracle资产 → PL/SQL代码行数 → Oracle特有SQL数量 → 内部包和工具依赖清单 第二步：兼容性验证（用真实代码测） → 挑10段有代表性的存储过程 → 覆盖自治事务、异常处理、包体依赖、游标操作 → 在候选数据库上逐个跑通，记录改造点 第三步：估算改造成本 → 改造代码行数 × 每行人天 × 人天单价 → 加上DBA培训周期和测试周期 → 对比各方案的总拥有成本 第四步：评估风险 → 兼容度高的方案：切换窗口短，风险可控 → 兼容度低的方案：改造周期长，需预留充足缓冲补充一句：第二步如果靠人工逐条梳理，一个二十万行的系统可能要搞一两周。像KDMS这类兼容性评估工具能自动扫描全部存储过程、函数、触发器和SQL，生成评估报告，还能自动转换大部分Oracle语法。原本的人力密集型工作，用工具几小时就能出结果。
选型的本质是风险和成本的平衡。你的Oracle用得越"深"，PL/SQL越重、特有语法越多、内置包依赖越广，对Oracle兼容性的要求就越高。
这是技术判断，不是品牌偏好。
五、结论
信创数据库选型涉及的事不少。性能跑分、TPC-C成绩、功能清单，这些都重要。但Oracle兼容性这一关过不去，后面的指标看了也白看。
两个判断送给各位。
兼容性不是"支持"两个字能概括的。语法、语义、行为三个层面都要验证，用真实代码测，别信PPT。
改造成本才是真正的决策杠杆。License省下来的钱，可能还不够付应用改造的外包费。兼容度高的方案，能把应用改造量控制在5%到10%，DBA一个月左右能上手。兼容度低的，改造量可能跳到30%以上，DBA培训周期也得拉长。中间差出来的，不只是钱，还有时间。
选型说到底就一句话：你的Oracle越"重"，对兼容性的要求就越高。
回到文章开头的那个测试。金仓KES能跑通那段存储过程不是偶然。Oracle常用功能的兼容性做得比较全面，PL/SQL兼容度较高。实际迁移项目里，应用改造量能控制在较小比例。对大多数企业级应用来说，问题已经不是"能不能迁"，而是"迁得有多顺"。
我是老张，咱们下篇见。
