券商存量技术栈的标准画像是 IBM 小机（AIX/Power）+ Oracle + EMC 存储，所谓 IOE。信创改造要求把这条栈替换成国产组合：鲲鹏/海光芯片、麒麟/统信操作系统、达梦/OceanBase/TDSQL 数据库。外围系统改起来像装修，核心库改起来像心脏移植——这篇讲这场移植怎么做才不死在手术台上。
第一步永远是盘点：依赖清单比方案重要
迁移方案翻车的头号原因不是目标库不行，是不知道存量系统里到底有什么。文档和实际系统对不上是常态，可信的做法是从 Oracle 数据字典直接拉：
- 存储过程、函数、包的清单和代码行数（老核心动辄几千个存储过程，移植工作量就从这里来）；
- 应用侧 SQL 方言：ORM 映射文件、MyBatis 动态 SQL 里的
CONNECT BY、MERGE、(+)外连接写法、ROWNUM分页； - 定时作业：依赖
dbms_scheduler/dbms_job的批处理链路，和《日终批量处理总览》那条依赖图一一对应； - 周边工具：BI 直连、ETL 脚本、报表平台的数据源配置——这些在应用清单之外，漏一个就是一次生产事故。
盘点这一步没有技术含量，但有生死之别。我见过有项目做到一半发现还有 300 个存储过程没人认领，工期直接翻倍。
兼容性雷区：逐个说清楚
空字符串与 NULL。Oracle 里 '' 就是 NULL，这是Oracle最广为人知也最坑的语义。存量应用代码里 if (x == null) 和 if (x.isEmpty()) 往往只写了一种，换库之后另一种语义出现，空串和 NULL 开始分流，查询结果莫名其妙少了或多了。迁移审计要把所有对空串敏感的代码点翻出来逐个确认。
长度定义的单位。Oracle 的 VARCHAR2(20) 默认按字节计，中文按 GBK 两字节、UTF-8 三字节。存量字段进 UTF-8 国产库，同样"20"能装的中文字数变了；反向也有坑——应用侧按字符截断的逻辑要全量审一遍。
存储过程移植量。各国产库的 Oracle 兼容度差异很大， OceanBase 有专门的 Oracle 模式，达梦兼容性也不错，但"不错"的意思是 90% 能跑——剩下 10% 要靠人肉改写和回归。物化视图、分区交换、CONNECT BY 递归、dbms_* 系统包，每一项都要过测试基线（《清算测试黄金文件》那套对比方法在迁移场景直接复用）。
字符集与排序规则。GBK 存量数据进 UTF-8 库是全量转码，比较排序的 collation 变了，原来"按拼音排序"的界面行为可能悄悄改变——业务验收要包含这类行为层面的确认，不只是数据对平。
验证策略：双轨并行，靠 diff 说话
迁移验证的正确姿势不是"测完再切"，是新旧并行跑一段时间，用比对结果决定何时切：
- 批量场景天然适合双轨：同一份输入文件，老库存储过程跑一遍，新库跑一遍，结果逐字段 diff（清算那篇讲的黄金文件方法原样搬来）。每天跑、连续跑，直到连续 N 天零差异；
- 交易场景用影子流量：网关镜像真实报文，新库做影子写入只比对不返回，验证写路径的正确性，不影响生产应答；
- 覆盖度：双轨期至少要覆盖一个完整的月末、季末、权益登记日——高峰场景的边界 case 不在普通日子里。
双轨期建议按季度计。一个月的零差异可能只是没碰到边界，三个月覆盖的周期事件才够支撑切换决策。
分阶段路径与组织成本
切换顺序从外围到核心：管理报表库 → 估值核算 → 柜台查询类 → 清算 → 核心交易。每一阶段的标准动作：双轨验证 → 选窗口切换（避开财报期，进变更冻结日历）→ 旧系统保留只读 N 年（审计追溯要求，别急着下电）。
最后一个被低估的成本是人的知识迁移：DBA 团队从 AWR 诊断转向新库的诊断工具链，运维监控的阈值和告警全部重建，故障手册逐条改写。技术问题都有解，组织知识的断层才是最大的风险——留足并行期让老专家带新人，比任何兼容层都值钱。
国产化改造最难的不是把系统搬过去，而是证明搬过去的系统和原来行为一致——在证券行业，"看起来一样"和"每一分钱都对得上"之间隔着整个测试体系。把这个差距当回事的项目都活下来了。