企业官网建设流程全解析

国产化替代这两年是真真切切地压到了每个做传统数据业务的团队头上。我去年接了一个从 Oracle 迁移到金仓数据库的项目，原本以为把表结构和存储过程搬过去就完事，结果真正跑起来才发现，Oracle 迁移最大的成本根本不在"搬家"，而在那些藏在 SQL 里的"问题词"——就是那些 Oracle 里写着顺手、语法也合法，但换到金仓之后要么直接报错、要么不报错但结果不对的写法。

这篇文章我不打算泛泛而谈"金仓兼容性如何如何"，而是把我在实际迁移验证中拆解过的几类问题词整理出来，包括每种问题词的表象、根因、验证方法和修复写法。文章里涉及的具体案例都来自我实际跑过的迁移验证过程，希望能给正在做 Oracle 迁金仓、或者准备做国产化迁移评估的朋友一些可以直接参考的排查思路。

1. 先搞清楚金仓的"Oracle兼容模式"到底兼容了什么

拿到金仓数据库的第一件事，我建议你不要急着导数据，先花半天时间把兼容性问题搞清楚。金仓（KingbaseES）的 Oracle 兼容不是"换个内核"那么简单，它是在 PostgreSQL 内核之上做了一层语法兼容层，启动时可以通过参数开关控制兼容模式，所以在讨论问题词之前，得先确认你连接的数据库实例到底开没开 Oracle 兼容开关。

1.1 兼容模式开关是迁移验证的前提条件

金仓默认有一个ora_input_emulation_type之类的参数控制 Oracle 兼容级别，具体参数名在不同版本里可能略有差异，我项目里用的是 V8 版本，需要在数据目录的配置文件（kingbase.conf）里确认兼容模式。实际操作中我是这么验证的：

SHOW ora_input_emulation_type;

如果返回值显示的是ora或者oracle相关的模式，说明当前会话驻留在 Oracle 兼容模式下；如果返回的是pg或者空值，那你写的NVL、SYSDATE、ROWNUM这些 Oracle 方言大概率会直接报语法错误。这个开关决定了后面所有问题词的验证环境，务必要在最开始确认清楚。

还有一点容易忽略：金仓的兼容模式可以分库设置，也可以按会话设置。同一个集群里，A 库可能跑的是 Oracle 兼容语法，B 库却是标准 PostgreSQL 语法，迁移验证时如果连错了库，很容易把"兼容性故障"误判成"金仓不支持"，白折腾半天。我习惯在每次跑验证脚本之前，先执行一句SELECT NVL(1,0);，能正常返回就说明当前会话确实在 Oracle 兼容模式下。

1.2 兼容性验证的对象：不止是 SQL，还有行为语义

踩过坑之后我总结了一个判断标准：凡是 Oracle 和 PostgreSQL 在语义上有本质分歧的地方，就是金仓兼容层最容易出问题的地方。语法不兼容通常会直接报错，这种问题反而好解决，查文档改语法就行；真正难缠的是"语法能跑、结果不对"的行为差异，比如字符串拼接、空值处理、日期格式化的默认规则，这些差异不跑到具体业务 SQL 上根本发现不了。

所以在做问题词拆解时，我把验证对象分成四层：

• 数据类型层：NUMBER、VARCHAR2、DATE、TIMESTAMP 的精度和行为差异
• SQL 语法层：分页、伪列、层级查询、集合运算等写法差异
• 函数行为层：NVL、TO_DATE、TRUNC、INSTR 等函数在边界情况下的返回值差异
• 对象与过程层：存储过程、包、触发器、序列等数据库对象的迁移表现

后面几节我就按这四层逐个拆解。这种分层的好处是验证时可以按层设计用例，每一层都有独立的检查脚本，出问题时能快速定位是哪一类兼容性缺口，而不是在茫茫 SQL 里瞎猜。

2. 数据类型与隐式转换：问题词"高发区"里的典型代表

数据类型层面上，金仓对 Oracle 的数据类型名做了映射兼容，NUMBER、VARCHAR2、CLOB这些关键词都能识别，但"能识别"不等于"行为一致"。下面这几个问题词是我在验证中碰到的高频项。

2.1 NUMBER 精度与小数位的行为差异

Oracle 里的NUMBER是一个变精度类型，你可以写NUMBER不带任何参数，这时候它能存任意精度的小数，整数部分和小数部分都近乎无限扩展。金仓里的NUMBER映射到什么类型，直接决定了你迁移表之后会不会出现精度丢失。

我在一个财务类业务表上就遇到过这种情况。原表结构是这样的：

CREATE TABLE fin_detail ( id NUMBER, amount NUMBER(12, 2), rate NUMBER );

迁移到金仓后，amount NUMBER(12,2)这种带精度的字段没问题，但rate NUMBER这个裸定义让我踩了坑。金仓把裸NUMBER映射为 PostgreSQL 的NUMERIC是带任意精度的，理论上是好事，但实际查询时发现，应用端通过 JDBC 拿到的rate字段元数据精度为0, 0，和 Oracle 驱动返回的精度信息不一致，结果数据层做金额校验时把rate当成了整型处理。

验证时我用的方法很简单，直接造一组边界数据插入再查出来，对比驱动返回的ResultSetMetaData精度：

CREATE TABLE tmp_num_test ( id NUMBER, val1 NUMBER, val2 NUMBER(10, 3), val3 NUMBER(5, 0) ); INSERT INTO tmp_num_test VALUES (1, 12345.67890123456789, 12345.678, 12345); SELECT * FROM tmp_num_test;

在金仓里执行这条 INSERT，val1的 20 位小数能完整存进去，这跟 Oracle 一致；但如果你在 Oracle 里执行同样的插入，val1也照样能存进去。问题不出在存储，出在 JDBC 客户端拿到的精度元数据上。所以我建议做数据类型兼容验证时，不要只看 SQL 客户端里的展示结果，一定要用你业务实际使用的驱动程序去连，检查getPrecision()和getScale()的返回值。

2.2 VARCHAR2 的字符长度语义：字节与字符的"文字游戏"

这可能是迁移后第一个在页面上暴露的问题。Oracle 的VARCHAR2(20)默认是"字节"长度，一个中文占 3 个字节（UTF-8 下），所以VARCHAR2(20)只能存 6 个汉字；而金仓的VARCHAR2(20)在兼容模式下是按"字符"算的，能存 20 个汉字。

这个差异往好了说是金仓对开发者更友好，但往坏了说，如果业务代码里依赖 Oracle 的字节截断行为，迁移后就会出现数据存进去了但应用端校验报长度超限的情况。我验证时专门写了一个对照脚本：

-- Oracle 执行结果：ORA-12899 值过大 -- 金仓执行结果：正常插入 CREATE TABLE tmp_varchar_test (name VARCHAR2(20)); INSERT INTO tmp_varchar_test VALUES ('国产数据库兼容性迁移验证测试');

这句插入在 Oracle 里会因字节超限报错，在金仓里却能成功。这不能简单说金仓不对，而是要提醒你：迁移前必须梳理业务里有没有依赖 Oracle 字节长度语义做数据校验的地方，如果有，建表语句要显式改成VARCHAR2(60 CHAR)这种形式，让两种库的行为保持一致。

2.3 TO_NUMBER 隐式转换：过滤"不可转为数字的字符串"

热搜词里有一条"oracle 过滤不可转为数字的字符串"，这绝对是迁移验证中的高频问题。很多老系统里会写这种 SQL：

SELECT * FROM tmp_user_info WHERE TO_NUMBER(user_no) BETWEEN 1000 AND 2000;

在 Oracle 里这条 SQL 能跑的前提是，user_no字段里不能存在非数字字符串，否则执行时会直接报 ORA-01722。而金仓对TO_NUMBER的容错行为做了调整——在某些兼容级别下，TO_NUMBER('abc')不报错，返回 0 或者 NULL，这看起来像是金仓更友好，但结果就是业务结果集被悄悄放大。

我遇到的实际案例是一个老系统里用TO_NUMBER过滤非数字订单号，Oracle 时代靠报错把脏数据暴露出来，切到金仓后报错没了，脏数据直接被算进了统计报表，直到月底对账才发现数字对不上。这个问题词的教训是：迁移后不能只看 SQL 是否跑得通，还要验证边界数据下的行为是否和 Oracle 一致。

验证方法如下，三种写法逐一对比：

-- 用例1：纯数字字符串，两库应返回相同结果 SELECT TO_NUMBER('123') FROM DUAL; -- 用例2：混入字母，Oracle 报 ORA-01722，金仓需确认是否报错 SELECT TO_NUMBER('12a3') FROM DUAL; -- 用例3：空字符串，Oracle 中 TO_NUMBER('') 返回 NULL，金仓需确认 SELECT TO_NUMBER('') FROM DUAL;

建议把这三个用例跑一遍，如果金仓在用例2上的行为和 Oracle 不一致，最快的修复方式是改写业务 SQL，主动加过滤条件，不要依赖数据库的隐式转换容错。比如改成：

SELECT * FROM tmp_user_info WHERE REGEXP_LIKE(user_no, '^[0-9]+$') AND TO_NUMBER(user_no) BETWEEN 1000 AND 2000;

这样无论是 Oracle 还是金仓，语义都被显式钉死了，不再受数据库兼容层行为差异的影响。

2.4 DATE 与 TIMESTAMP：毫秒精度和时间格式的默认值

"oracle毫秒转换日期格式"也是热搜里的高频词，这暴露了另一个常见痛点。Oracle 的 DATE 类型本身包含时分秒，但精度只到秒；而 TIMESTAMP 可以带小数秒。金仓兼容 Oracle 时，DATE 的映射策略在不同版本里是有差别的，有的版本把 DATE 映射成timestamp(0)，有的保持date。

让我印象最深的是SYSDATE和TRUNC(SYSDATE)的行为差异。在 Oracle 里：

SELECT TRUNC(SYSDATE) FROM DUAL; -- 返回当天零点，格式由 NLS 参数决定，通常是 '2024-01-01 00:00:00'

这条语句在金仓里能跑，但返回值的显示格式可能不带时间部分，或者带时间部分但时分秒不是零。如果业务代码里对这个结果做字符串拼接，比如'单号-' || TO_CHAR(TRUNC(SYSDATE), 'YYYYMMDD')，两边结果通常是一致的；但如果是TO_CHAR(SYSDATE, 'DD-MON-YY')这种依赖 Oracle 默认 NLS 日期格式的写法，十有八九要在金仓里改格式串。

我的建议是，迁移前做一轮 SQL 扫描，把所有涉及TO_DATE、TO_CHAR、SYSDATE、TRUNC(SYSDATE)的 SQL 全部提取出来，统一改写格式串，不要用数据库默认格式。这个动作看着琐碎，但它能避开一整个类别的兼容性问题。

3. 语法层面的问题词：分页、伪列与层级查询的差异现场

语法层面的问题词是最容易在迁移工具扫描阶段被发现的，因为它们在 SQL 文本里长得很独特。但发现容易，改对难。这一节我挑三个典型案例讲透。

3.1 ROWNUM 分页：改写 LIMIT 不是唯一方案

"oracle分页"是所有迁移项目都绕不开的坎。Oracle 经典的ROWNUM分页写法长这样：

SELECT * FROM ( SELECT t.*, ROWNUM AS rn FROM tmp_order t WHERE ROWNUM <= 40 ) WHERE rn > 20;

金仓对ROWNUM做了兼容，简单场景下能用，但有一个细节陷阱：金仓的ROWNUM兼容是基于对结果集的模拟，不是像 Oracle 那样在执行计划层面实现的。这意味着当 SQL 里同时存在ROWNUM和ORDER BY时，两条 SQL 的执行顺序可能不同。

Oracle 里下面这条 SQL：

SELECT * FROM ( SELECT t.*, ROWNUM AS rn FROM tmp_order t ORDER BY t.create_time DESC ) WHERE rn BETWEEN 1 AND 20;

由于内层先做了ROWNUM赋值再排序，取到的是"未排序前的前 20 行再排序"，而不是"排序后的前 20 行"，这是 Oracle 的老坑。而金仓在兼容ROWNUM时可能会优化成先排序再取行号，导致分页结果和 Oracle 不一致。

我在验证中碰到过一次这个问题，当时两个库跑出来的第一页数据完全不一样，排查了半小时才意识到是ROWNUM的执行逻辑差异。所以我的建议是：凡是有 ORDER BY 的分页 SQL，不要用ROWNUM，直接改成LIMIT/OFFSET或者标准的窗口函数ROW_NUMBER() OVER (ORDER BY ...)，一次性规避行为差异：

-- 推荐写法：窗口函数分页，两库行为一致 SELECT * FROM ( SELECT t.*, ROW_NUMBER() OVER (ORDER BY t.create_time DESC) AS rn FROM tmp_order t ) x WHERE x.rn BETWEEN 1 AND 20;

3.2 CONNECT BY 层级查询：兼容但不等于高效

层级查询（树形结构）是 Oracle 体系里非常成熟的能力，START WITH ... CONNECT BY PRIOR ...。金仓支持这种语法，但我在实际跑一个 5 万节点的树形表时发现，性能和 Oracle 差了一个量级。

这个问题的根源在于金仓把 CONNECT BY 语法改写成了递归 CTE 来执行，逻辑等价但执行计划完全不同。Oracle 对 CONNECT BY 有专门的优化路径，而金仓的改写方案是通用的递归查询，遇到深层次遍历（比如 10 层以上的父子关系）时，中间结果集的膨胀会比 Oracle 严重得多。

验证方法很简单，拿业务里最重的树查询，在两个库里分别执行并对比执行计划和耗时。如果性能差异明显，我的处理办法是改写为递归 CTE：

WITH RECURSIVE tree_cte AS ( SELECT id, parent_id, name, 1 AS level FROM tmp_org WHERE parent_id IS NULL UNION ALL SELECT c.id, c.parent_id, c.name, p.level + 1 FROM tmp_org c JOIN tree_cte p ON c.parent_id = p.id ) SELECT * FROM tree_cte;

这个改写方案在两库里都能跑出稳定的执行计划，虽然 Oracle 上可能不如原生 CONNECT BY 快，但胜在行为统一，后续维护成本低。如果要保性能，也可以考虑把树形数据冗余成"祖先链"字段，用普通索引查询替代递归，但这属于设计层面的改动了，得业务方一起拍板。

3.3 DUAL 表与空查询：一个被遗忘的问题词

"oracle中dual最多存多大"这个热搜词看着有点戏谑，但背后有个真实问题：Oracle 的SELECT ... FROM DUAL在金仓里确实能跑，金仓提供了兼容的 DUAL 视图，但它的语义和 Oracle 的"单行单列虚拟表"是有微妙差别的。

Oracle 里SELECT 1 FROM DUAL永远返回一行；金仓的 DUAL 在某些版本里是真实表，如果被误插入数据（虽然默认不允许），或者会话级搜索路径配置不对，FROM DUAL可能出现查不出数据的情况。我建议所有涉及 DUAL 的 SQL，在金仓里统一改成不带 FROM 子句的写法：

-- Oracle 写法 SELECT SYSDATE FROM DUAL; -- 金仓推荐写法：省略 FROM SELECT SYSDATE; -- 如果需要多行常量，用 VALUES SELECT * FROM (VALUES (1), (2), (3)) AS t(id);

这种改写对应用透明，还能少一次对 DUAL 表的访问，算是迁移中的顺手优化。

4. 函数行为差异：不报错、但结果不对，才是最难查的

函数层面的兼容性验证，我总结了一个经验：报错的差异好改，静默的差异害死人。下面这几个函数是我在验证中确认过行为差异的，每一个都值得在你的问题词清单里占个位置。

4.1 INSTR 与字符串包含判断的兼容陷阱

"oracle判断字符串是否包含某个字符串"这个热搜词对应的典型写法是：

SELECT * FROM tmp_log WHERE INSTR(message, 'ERROR') > 0;

Oracle 里INSTR是严格按字符位置匹配的，找不到返回 0。金仓的INSTR兼容实现，在绝大多数情况下行为一致，但我遇到过一次边界问题：当搜索字符串为空串''时，Oracle 的INSTR('abc', '')返回 1（空串被认为出现在第一个字符位置），而金仓在某个兼容级别下返回 0。导致WHERE INSTR(message, '') > 0这种不太合理但语法合法的 SQL，在两库上筛选出的行数不同。

更稳妥的做法是迁移时把"是否包含"这类判断全部改写为LIKE或POSITION：

-- Oracle 风格 WHERE INSTR(message, 'ERROR') > 0; -- 金仓/通用风格 WHERE message LIKE '%ERROR%'; -- 或者 WHERE POSITION('ERROR' IN message) > 0;

LIKE的语义在 Oracle 和金仓之间基本一致（除了转义符细节，如果业务里有用到\作为转义符，要在LIKE后加ESCAPE子句显式声明），改写后不需要再为INSTR的边界行为担忧。

4.2 NVL 与 COALESCE：不是简单的替换关系

NVL(a, b)是 Oracle 用户的肌肉记忆，金仓也支持这个函数。但如果你以为它和COALESCE(a, b)完全等价，那就在空字符串和空值上容易踩坑。

Oracle 里NVL的逻辑是：如果第一个参数是NULL，返回第二个参数；否则返回第一个参数。关键是 Oracle 里空字符串''和NULL在大多数场景下是等价的（'' IS NULL为真）。而金仓兼容模式下，''会被当成一个长度为 0 的非空字符串来处理。

验证用例：

-- Oracle：结果为空字符串，等价于 NULL SELECT NVL('', 'fallback') FROM DUAL; -- 金仓：结果为空字符串，但判断 IS NULL 为假 SELECT NVL('', 'fallback') FROM DUAL; SELECT NVL('', 'fallback') IS NULL FROM DUAL;

两条 SQL 显示结果可能是相同的空字符串，但如果你在存储过程里写了IF NVL(a, '') IS NULL THEN这种代码，金仓和 Oracle 走的分支就会不同。建议统一把NVL在业务逻辑敏感的位置改成显式的CASE WHEN ... IS NULL写法，彻底绕开行为差异。

4.3 TO_CHAR 数字格式化：格式模板的细节差异

TO_CHAR在 Oracle 里功能极其丰富，TO_CHAR(1234.5, 'FM999G999D00')这种格式模板在金仓里不能说完全不支持，但支持的格式元素集有差异。我在验证金额展示时踩过一个坑：Oracle 的TO_CHAR(0, 'FM9990.00')返回0.00，金仓在同样格式下返回.00，少了整数部分的 0。

这个问题的根源是FM（fill mode）格式修饰符在两种数据库中的实现细节不同。Oracle 的 FM 会去掉前导空格但保留必要的 0，金仓的 FM 在某些版本里把整数部分的 0 也去掉了。修复方式有两个：一是改用TO_CHAR时把格式串写得让两库都满意，比如'FM9990.00'里多写一个 0 位；二是在应用层做数值格式化，不要在 SQL 里依赖数据库的TO_CHAR规则。

我的建议是第二种，因为数据库里的TO_CHAR格式本身就容易踩各种细节差异，而且测试覆盖很难做到穷尽，让应用层把结果转成字符串展示，反而更可控。

5. PL/SQL 与数据库对象迁移：包、触发器、序列的连环坑

从单条 SQL 上升到存储过程和包，问题词的复杂度会跳一个台阶。因为不再只是语法翻译的问题，还涉及执行上下文、游标行为、异常处理机制。这里我只讲自己在验证过程中遇到过的、有代表性的三类问题。

5.1 PACKAGE 包迁移：DBMS_OUTPUT 和自治事务

"oracle package"这个热搜词说明包迁移确实是刚需。金仓提供了CREATE OR REPLACE PACKAGE和PACKAGE BODY的兼容语法，但包内部的 PUT/GET 逻辑和事务行为需要重点验证。

我迁移过一个批量对账的包，里面用到了DBMS_OUTPUT.PUT_LINE打印日志、PRAGMA AUTONOMOUS_TRANSACTION做独立事务。Oracle 中自治事务的意思是：子程序中的提交/回滚不影响外层事务。金仓在兼容PRAGMA AUTONOMOUS_TRANSACTION时，在某些版本里需要写成AS PRAGMA AUTONOMOUS_TRANSACTION;跟在声明区，但注意金仓必须在声明段落里显式声明，顺序不对就报错。

验证包行为时，我习惯写一个最小复现脚本，把包的每个公有子程序都调用一遍，然后检查三件事：

1. 包是否能编译通过（金仓的包编译错误提示通常能直接指向不兼容的语法位置）；
2. 包内对全局变量的修改是否符合预期；
3. 自治事务是否真的与外层事务隔离——这个要在包调用结束后主动回滚，再去另一会话查数据是否已提交。

5.2 VARRAY 变长数组：从嵌套表到数组的取舍

"oracle 变长数组"这个热搜词比较冷门，但它是一个很有代表性的类型兼容问题。Oracle 里VARRAY作为集合类型，经常被用在存储过程的参数传递中。金仓在集合类型的兼容上，说实话还比较初级，VARRAY的语法能识别，但如果你的代码里写了varray.FIRST、varray.LAST、varray.EXTEND这些集合方法，支持程度就参差不齐了。

我的建议是迁移的时候尽量把VARRAY这种 Oracle 专有的集合类型换成金仓兼容模式下更容易支持的数组类型，或者在包内部这样处理：如果VARRAY只用于临时存储中间结果，就直接改用临时表；如果是传给 SQL 用的，用字符串拼接的方式传递，在 SQL 内部用UNNEST或类似函数展开。虽然丑，但在迁移期能把复杂度降下来。

5.3 序列迁移：NEXTVAL 与 CURRVAL 的会话边界问题

序列（SEQUENCE）迁移表面上看很简单，创建同名序列、把当前值调整到和 Oracle 一致就行。但我在验证中发现一个容易翻车的小点：CURRVAL的会话边界差异。

Oracle 里CURRVAL必须在当前会话中先调用过NEXTVAL才能使用，否则报 ORA-08002。金仓的序列兼容层在某些版本中对这个检查不严格，跨会话直接调用CURRVAL可能返回一个历史值而不报错。这意味着如果业务代码里有"先查CURRVAL再决定下一步"的逻辑，在金仓上会因为拿到的不是当前会话最近一次NEXTVAL的值而出错。

验证脚本：

-- 会话A SELECT seq_test.NEXTVAL FROM DUAL; -- 新开会话B，不调用 NEXTVAL，直接查 CURRVAL -- Oracle：ORA-08002 -- 金仓：可能能查到值 SELECT seq_test.CURRVAL FROM DUAL;

修复方式是把序列的CURRVAL用法改成程序里显式拿变量保存NEXTVAL的返回值，或者用金仓提供的兼容开关把CURRVAL行为强制设为 Oracle 模式。取决于版本，这个开关不是默认开启的，得在数据库配置里手动加。

5.4 触发器与动态 SQL：注意执行时机差异

触发器迁移的坑更多是在细节上。Oracle 的BEFORE INSERT触发器里:NEW字段赋值，金仓兼容模式下也支持，但有一个不同：Oracle 里在BEFORE触发器中修改:NEW字段后，插入操作会自动使用新值；金仓在部分版本里如果你不显式把:NEW的值赋回列，插入的可能是旧值。我写过一段测试：

CREATE OR REPLACE TRIGGER trg_set_create_time BEFORE INSERT ON tmp_audit_log FOR EACH ROW BEGIN :NEW.create_time := SYSDATE; END;

在 Oracle 里插入tmp_audit_log不传create_time，用触发器默认值；在金仓里同样的触发器和插入语句，有的版本插入后create_time还是NULL，需要把插入 SQL 改成VALUES (..., SYSDATE)或者把触发器改成AFTER INSERT配合 UPDATE。这个差异很隐蔽，建议在迁移验证用例里单独给触发器建一组"插入时不带该字段"的用例，专门检查:NEW赋值是否生效。

6. 验证体系怎么搭：从问题词清单到双跑回归

讲完了具体的问题词，这一节聊方法论。我在迁移项目里最终沉淀的验证方法，可以总结为三步：建问题词清单、做差异预检查、双跑回归验证。

6.1 问题词清单是迁移验证的"靶子"

所谓问题词，不只是某个关键词，而是"一个关键词 + 一个使用场景 + 一个边界条件"的组合体。比如TO_NUMBER是一个词，但TO_NUMBER('非数字')才能算一个需要验证的问题实例。我把清单做成了表格，迁移时对照检查：

这个表不是我拍脑袋编的，每一行都是经过双跑验证确认过的差异点。你可以拿它作为起点，然后根据自己业务 SQL 的实际情况往里补充。补充的依据不是"我觉得这里有风险"，而是把生产环境的所有 SQL 采集上来，做一轮静态扫描，把命中了这些关键词的 SQL 全部拉出来，逐个设计边界用例。

6.2 双跑回归：让两个数据库跑同一组 SQL

双跑回归的玩法很简单：准备一套覆盖各类问题词的 SQL 测试集，在 Oracle 和金仓各执行一遍，然后对比结果集、返回行数、执行报错信息。关键点在于"测试集要包含边界用例"，比如空值、空字符串、超长字符串、负数、零、极大极小值、日期边界。

我自己的测试集有三类脚本：

第一类是语法兼容检查脚本，专门跑 Oracle 方言语法，比如ROWNUM、CONNECT BY、START WITH、DECODE、NVL、SYSDATE，目标是看能不能过编译。

第二类是行为对比脚本，跑同一组 SQL，把结果输出成文件，用 diff 工具做全量比对。这一步最能暴露"不报错但结果不对"的静默差异。

第三类是数据校验脚本，针对具体业务表，从 Oracle 抽一批代表性数据迁移到金仓，然后做行数对比、字段级全量对比、抽样业务规则对比。数据校验我用的是EXCEPT集合运算：

-- 全量数据对比：找出两边不一致的记录 SELECT * FROM oracle_migrated_sample EXCEPT SELECT * FROM kingbase_target_sample;

如果EXCEPT返回空集，说明两份数据完全一致；如果返回了记录，就能看到具体是哪一行、哪些字段存在差异，再反推是迁移工具的问题还是类型映射的问题。

6.3 迁移预检查工具与人工审查的分工

金仓官方有配套的迁移评估工具，能扫描 Oracle 的 SQL 脚本和存储过程代码，给出兼容性评估报告，标注不兼容对象。这个工具值得用，但不要完全依赖它。我在实践中的分工是这样的：

• 工具负责"广度"：把全量对象过一遍，快速定位语法层面的不兼容问题；
• 人负责"深度"：对工具判定为"兼容"但涉及函数行为、隐式转换、边界值的 SQL，做人工审查和边界用例验证。

人工审查最耗时间，也最考验经验。我的做法是找业务系统里"数据变化最频繁、查询条件最复杂"的那几张核心表，把它们的 SQL 拿出来逐条审。这个动作虽然慢，却是整个迁移验证里价值密度最高的部分。

6.4 自动化回归脚本的落地骨架

如果项目周期长、业务 SQL 量大，建议把双跑回归做成自动化的。我当时用 shell 脚本 + SQL 文件的方式搭了一个轻型框架，骨架大概长这样：

#!/bin/bash # 双跑回归脚本骨架 # 用法：sh regress.sh oracle.sql SQL_FILE=$1 ORACLE_OUT="oracle_$(basename $SQL_FILE).out" KINGBASE_OUT="kingbase_$(basename $SQL_FILE).out" # 1. 在 Oracle 上执行 sqlplus -s "user/pass@oracle_db" <<EOF SET ECHO OFF SET FEEDBACK OFF @$SQL_FILE SPOOL $ORACLE_OUT SPOOL OFF EXIT; EOF # 2. 在金仓上执行 ksql -h host -p 54321 -U user -d dbname <<EOF \set ON_ERROR_STOP on \o $KINGBASE_OUT \i $SQL_FILE \o EOF # 3. 结果对比 diff $ORACLE_OUT $KINGBASE_OUT if [ $? -eq 0 ]; then echo "PASS: $SQL_FILE" else echo "FAIL: $SQL_FILE" fi

这个骨架把一个"测试 SQL 文件对两边执行，再 diff 结果"的过程自动化了。你可以把几十个问题词的测试用例拆成一个个独立的 SQL 文件，跑完一轮直接得到通过/失败清单。再往上一层，可以接 CI 系统，每次数据库补丁升级后自动跑一轮回归，确保兼容性没被破坏。

7. 一次存储过程迁移的完整排查链路

前面讲了这么多理论，最后我说一个真实的排查过程。当时迁移一个订单结算的存储过程，从 Oracle 到金仓，编译能过，但跑出来的结算金额始终和 Oracle 不一致，差在小数点后两位。这个问题的排查链路代表了我在这个项目里处理"问题词"的完整思路。

先交代背景：存储过程逻辑不复杂，从一个明细表汇总出结算金额，再按金额区间套不同的费率计算。核心 SQL 是这样的：

v_amount := ROUND(v_sum * v_rate, 2);

第一轮排查：我先怀疑是ROUND函数行为不一致，单独跑遍ROUND(1.005, 2)这种经典边界用例，两个库结果一样。排除。

第二轮排查：怀疑是v_sum本身精度有问题，也就是明细表的金额字段类型映射在迁移中丢失了精度。查表结构发现，明细表的amount字段在 Oracle 是NUMBER(14,4)，迁移后金仓成了NUMERIC(14,4)，精度没丢。排除。

第三轮排查：把中间变量打印出来，在存储过程里加了一行临时输出，分别看 Oracle 和金仓跑出来的v_sum和v_rate。这一下就暴露了问题——Oracle 的v_sum是 799.9999999999，金仓的v_sum是 800.0000000000。明细数据完全一样，为什么聚合后差了一点点？

根源是明细表里有一条金额为 99.99 的记录，数据库中实际存储的是 99.9900，但在某个旧业务逻辑里插入时用了字符串转数值的方式，Oracle 把'99.9900'转成了 99.99 浮点近似值；而金仓迁移后同样数据被转成了精确的 99.9900。累加 8 条这样的数据后，Oracle 的浮点累计误差是 -0.0000000001，金仓因为内部实现不同，误差方向相反。

这个问题的解决方式不是改 SQL 逻辑，而是把存储过程中的汇总源表字段定义为NUMERIC(14,4)，并且把插入历史数据的TO_NUMBER调用统一改成带FORMAT的显式转换，确保两边拿到的原始值完全一致，再去对比汇总结果。在排查出根因之前，这个问题整整耗了我两天，原因就是一开始只盯着函数行为，忽略了"数据在数据库内部的数值表示方式"这个底层变量。

这个案例给我的启示是：很多兼容性问题根本不是语法层面的，而是数据在迁移过程中被改变了语义。所以做问题词拆解时，一定要把"数据双跑校验"放在和"SQL 兼容性校验"同等重要的位置。甚至可以说，数据一致性验证是问题词验证的最后一道防线，前面语法检查做得再好，数据语义变了，业务结果照样错。

回头看我这次金仓迁移的整个过程，最值钱的经验就是"先列问题词，再做双跑验证，最后才动数据迁移"这个顺序。很多人一上来就急着导数据、改代码，结果被各种隐性差异反复折腾，工期严重超支。如果你现在也卡在 Oracle 迁金仓的某一个具体问题上，建议先停下来，把问题整理成一个"问题词 + 边界场景 + 验证SQL"的组合条目，然后拿到两个库上分别跑一遍。大多数你以为的"兼容性 Bug"，最后都会落回某一类语义差异上——而这类差异，是可以通过系统性的验证提前兜住的。