各位，我是老张。

去年有个运营商客户找我做迁移评估。系统是自智网络平台的智能中枢，跑在 Oracle 19c RAC 上。每天 3 亿多次 SQL 交互，实时数据吞吐 125G。这个量级没人敢拍脑袋切库。

选型会上三家厂商都说自己兼容 Oracle。客户反问了一句：怎么证明。会议室安静了。

后来这套系统真迁成了。靠的不是谁嗓门大，是一套能跑出证据的验证方案。

## 为什么「SQL 跑通了」不等于「兼容了」

很多团队的兼容性验证，是拿几十条示例 SQL 跑一遍，不报错就算过关。这个做法有盲区：报错是最容易发现的差异，真正麻烦的那批根本不报错。

举个我碰到的例子。Oracle 的分区表允许分区字段为空，只要存在 maxvalue 分区，值就能插进去。目标库也允许分区列为空，但需要 Default 分区。这个差异不会让建表报错，它会在某天插入数据时才冒出来。

存储过程的 IN 参数也一样。Oracle 里 IN 模式只能传入使用，程序体内不能重新赋值。KES 里可以赋值。要是你依赖 Oracle 这个限制做过逻辑判断，行为就对不上了。

Object type 的方法连续调用同理。方法1.方法2.方法3 这种写法目标库不支持，得拆成中间变量一步步来。这类差异静态扫描不一定扫得出来，因为它语法上没错。

说白了，兼容性差异分两种。一种报错，跑一遍就能发现。一种不报错，安静地藏在返回结果或者边界场景里。后者才是迁移项目真正的成本来源。

## 兼容 Oracle 到底要验证什么？分四层看

我把验证拆成四层。前三层能用工具覆盖，第四层只能靠真实负载。

|验证层级|验证什么|主要手段|覆盖能力|
|:-:|:-:|:-:|:-:|
|**语法层**|SQL 与 PL/SQL 语法能否直接解析执行|对象扫描、负载采集|能发现解析报错，发现不了语义差异|
|**语义层**|同一句 SQL 的结果是否一致|参数对照实验、结果比对|能发现空串/NULL、精度、隐式转换差异|
|**行为层**|边界场景与异常路径是否对齐|边界用例设计、触发器与并发测试|能发现事务粒度、锁、异常传播差异|
|**性能层**|迁移前后响应时间与资源消耗|真实负载回放|只能靠生产负载，压测脚本替代不了|

![01-verify-layers.png](https://developer.qcloudimg.com/http-save/yehe-12565093/6005fa496bfc08017849d43540cfccc2.png)
前三层不用多解释，要说的是第四层。同一条 SQL 在 Oracle 上跑得很快，换个库可能慢十倍。原因可能是执行计划变了，也可能是统计信息不准。你拿几个基准脚本测不出来，因为脚本不是真实业务的访问模式。

那个运营商项目做的就是第四层。24 小时完整负载抓下来，放进 1:1 环境重放，再逐条比对结果和耗时。

## 兼容 Oracle 的负载验证：捕获、转换、回放三步

这套动作由 KReplay 承担。链路分三步：Oracle 侧捕获、中间做负载转换、目标端回放。

### 第一步：在 Oracle 侧捕获负载

捕获用的是 Oracle 原生接口 `DBMS_WORKLOAD_CAPTURE`，不需要在源库装额外组件。

```
-- 创建捕获目录
create or replace directory db_replay_capture_dir as '/home/oracle/db_replay_capture';

-- 只捕获指定用户的请求，避免把系统负载也抓进来
exec dbms_workload_capture.ADD_FILTER('FILTER_KDTS','USER','KDTS_RAT');

-- 多 PDB 容器环境需要限定 PDB
exec dbms_workload_capture.ADD_FILTER('FILTER_PDB','PDB_NAME','PDB');
```
```
BEGIN
  DBMS_WORKLOAD_CAPTURE.start_capture(
    name     => 'test_capture_1',
    dir      => 'DB_REPLAY_CAPTURE_DIR',
    duration => NULL          -- NULL 表示手动停止，不设时长上限
  );
END;
/

BEGIN DBMS_WORKLOAD_CAPTURE.finish_capture; END;
/

-- 查看捕获结果与 SCN 区间
select DBMS_WORKLOAD_CAPTURE.get_capture_info('DB_REPLAY_CAPTURE_DIR') FROM dual;
select start_scn, end_scn from dba_workload_captures where id = 1;
```
`default_action` 这个参数值得单独说。它决定过滤器的方向。INCLUDE 时默认捕获所有请求，过滤器起排除作用。EXCLUDE 时默认不捕获，过滤器起包含作用。方向搞反，抓回来的负载要么少一大半，要么把无关会话全带上。

环境上还有两个坑。Oracle 10g R2 要先跑 `@$ORACLE_HOME/rdbms/admin/wrrenbl.sql` 才能启用捕获。RAC 环境建议把捕获目录放到共享文件系统上。捕获产物是 `wcr_fcapture.wmd`、`wcr_scapture.wmd` 和 capfiles 下的 `wcr_*.rec` 文件。

### 第二步：转换成目标端能读的格式

Oracle 抓下来的是 wmd 格式，目标端认的是另一种，中间用 OracleDecode 转换。转换靠几个参数控制：

|参数|作用|默认值|
|:-:|:-:|:-:|
|`raw.parser.source-file`|待解析文件的读取地址，配总目录可递归处理|—|
|`raw.parser.parallel-count`|并行处理线程数|需大于 0|
|`raw.parser.nls-format`|时间转换格式|`yyyy-MM-dd HH:mm:ss.SSS`|
|`raw.cut.output.file.size`|生成文件切割阈值|`1G`|
|`raw.parser.index-storage`|合并文件索引存储位置|`sqlite`|
|`raw.delete.decode.file`|是否删除中间文件|`false`|

`parallel-count` 最值得调。负载文件动辄几个 G，单线程解析会拖很久。转换完成产出 `KingBase_wcr_<时间戳>_1.rec`，这就是回放的输入。

### 第三步：在目标端回放

KES 侧要先把 `dbms_database_replay` 加进 `shared_preload_libraries`，再创建扩展。注意扩展要在 kingbase 库下装。

```
create extension sys_kwr;
create extension dbms_database_replay;
```
```
-- 1. 处理捕获文件
exec dbms_workload_replay.process_capture('/home/mydb/dbreplay_dir');

-- 2. 查看解析统计：SQL 记录数、会话数、耗时最长的会话
select show_process_capture_statistics();

-- 3. 初始化回放
exec dbms_workload_replay.initialize_replay('replay1','/home/mydb/dbreplay_dir');

-- 4. 把捕获时的连接映射到测试环境
select replay_id, conn_id, capture_conn from dbms_database_replay.workload_connection_map;
exec dbms_workload_replay.remap_connection(conn_id, 'localhost', 54321, 'kingbase');

-- 5. 检查有没有没映射上的连接
select * from dbms_database_replay.workload_connection_map
 where replay_port is NULL and replay_dbname is NULL;

-- 6. 设置时间缩放并回放
exec dbms_workload_replay.prepare_replay('TIME', 100, 100);
exec dbms_workload_replay.start_replay();
```
第 4 步的连接映射最容易卡住。捕获时是生产库的 IP 和端口，回放时是测试环境的。不映射就会有一批会话直接失败。

第 6 步 `prepare_replay` 的后两个参数是时间缩放。官方文档给的换算很直白：加压 2 倍就把数值设成 50%，减压 2 倍设成 200%。这两个值方向相反，加压是把时间间隔压短，所以数值要调小。

那个运营商项目先减压再加压。TIME 200,200 看平稳性，TIME 50,50 看极限。顺序有讲究：先让系统在有裕量时暴露功能差异，再压到极限看性能拐点。

并发连接数由 `dbms_database_replay.concurrent_conn_num` 控制，可设 1 到 100000，默认上限 32768。回放前记得跑 `vacuum` 和 `analyze` 更新统计信息，否则执行计划会跑偏。
![02-kreplay-flow.png](https://developer.qcloudimg.com/http-save/yehe-12565093/2dc95953c0b54b2f906506e1f4163992.png)

## 回放报告里到底该看什么？

回放跑完，真正的活儿才开始。

```
select dbms_workload_replay.get_replay_info('/home/mydb/dbreplay_dir');
select * from DBA_WORKLOAD_REPLAYS;
select dbms_workload_replay.report(1,'HTML');
select dbms_workload_replay.report(1,'TEXT');

-- 顺带把 KWR 和 KSH 报告也导出来
select perf.kwr_report_to_file(1,2,'html','/home/mydb/kwr_1_2.html');
select perf.ksh_report_to_file_by_snapshots(1,2,'/home/mydb/ksh_1_2.html','html');
```
指标不少，先看三个就够定位方向。DB Time 看数据库的繁忙程度。它明显高于源库，就说明同样的活儿在新库上更费时间。这时先查执行计划和参数配置。

Average Active Sessions 是有活动连接的会话数量。和 DB Time 放一起读，能分清是负载变重了，还是单条 SQL 变慢了。

User Calls 越高负载越大。回放环境下它比捕获环境高，先去查连接映射。

这三个定完方向，再下钻到 TOP 事件、TOP SQL、TOP Session 三个榜单。TOP SQL 里排前面的，就是你要逐条比对执行计划和结果集的清单。

差异分三类，处理方式完全不同。数据对不上，这是正确性问题，必须修。错误码不一样属于兼容性问题，改 SQL 或者改配置参数。时延超标多数是性能问题，靠调优能解决。

这里说句实在话：官方文档里没有「差异率低于多少算通过」的统一阈值。这个数得结合你自己的业务容忍度定。支付类系统可能要求零数据不一致，报表类可以放宽。谁拿一个通用百分比告诉你「过了」，你得追问出处。

## 兼容 Oracle 的语义差异，怎么用参数验证？

语义层的差异难点在于不报错。我的做法是变成可复现的对照实验：改一个参数，跑同一句 SQL，比两次结果。

```
-- 例一：number 类型输出的末尾零
select 1.00::number;              -- 默认输出 1.00
set ignore_zero_number = true;
select 1.00::number;              -- 输出 1
```
`ignore_zero_number` 决定数值的输出形态。要是应用层依赖字符串格式做等值比较，这个差异会造成判断错误。

```
-- 例二：等号比较 NULL 的行为
set transform_null_equals = on;
select * from t where col = NULL;   -- 相当于 col IS NULL
```
Oracle 里 `col = NULL` 永远返回空，很多老代码靠这个特性规避空值分支。迁到新库如果这个参数没配，同一句 SQL 会返回一批额外数据。

```
-- 例三：LIKE 的转义符行为
set escape = off;
set escape = on;                  -- 表现与 Oracle 基本一致
```
还有两个和空串、参数默认值相关。`ora_input_emptystr_isnull` 控制空串是否按 NULL 处理。`comp_v7_program_para_def` 打开后，可以给 OUT 参数指定默认值。官方文档写得很清楚，这两个默认都是关的。

这类参数，官方《版本和平台兼容性》一章里成规模的有二十多项。每项都给了类型、默认值和说明。但默认值不等于正确值。每开一个参数，都应该有一次对照实验结果撑着。

应用侧也别忘。JDBC 驱动、连接串参数、SQL 分页写法，改动量不大，漏一处就是上线后的报错来源。

## 兼容 Oracle 的边界：官方承认哪些特性要改写

这部分材料出自官方迁移文档，官方自己列的不兼容清单。

PL/SQL 侧，官方明确列出的不兼容只有两条。一是 package 里 Oracle 允许存在同名同参数的存储过程和函数，KES 不支持，需要改名。二是 Object type 的方法连续调用不支持，要拆成中间变量分步调用。

触发器迁移会碰到两类高频报错。视图上的触发器不能有转换表，报 42809。多个事件的触发器不能指定转换表，报 0A000。两类都可以改写为触发器函数解决，要点是把 `INSERTING`、`UPDATING`、`DELETING` 换成对 `TG_OP` 的判断。

命名上还有一处。Oracle 允许同一个 schema 下索引与表同名，目标库不允许。迁移工具遇到同名会直接报错。另外 raw 类型默认不支持，目标端要装对应的数据类型插件。

数据类型映射倒不用太担心。官方清单里 28 种 Oracle 数据类型全部标注兼容，`NUMBER` 映射为 `numeric` 且保留 38 位有效数字。内置包支持 26 项，`DBMS_OUTPUT`、`DBMS_LOB`、`DBMS_SCHEDULER`、`UTL_FILE` 这些运维常用的都在。系统视图侧有 131 个兼容视图，`ALL_TABLES`、`DBA_USERS`、`V$SESSION` 这些 DBA 日常要查的都能直接用。

说白了，官方承认的边界有限，但有限不等于没有。判断一个迁移方案靠不靠谱，就看他敢不敢把边界清单摆出来。

## 一次真实的验证结论长什么样

最后给两个结论，都来自公开的项目实践。

一个是运营商自智网络系统。源端 Oracle 19c RAC，目标端 RAC 双节点集群，每天 3 亿多次 SQL 交互。验证走的是标准四步：捕获 24 小时完整负载，搭 1:1 测试环境。减压和加压各跑一轮回放，再靠 KWR、KSH 和回放报告定位问题。最终识别出 12 类兼容性问题和 21 处性能调优突破点。

另一个是某三甲医院的临床数据中心。替换对象是 Oracle 11g，数据量超 2TB，忙时 3 万 TPM 以上。他们的验证方法有个巧思。用 DataGuard 备库做完全量迁移，当准生产测试数据集用。再在真实数据上跑关键业务场景。

结论写得挺坦率。5 个主要场景里，KES 在 2 个上比 Oracle 更好，3 个略差。全部 5 个场景的 SQL 处理耗时都小于或接近 100 毫秒。

我把这个结论放出来，是因为它比「性能全面提升」有用得多。迁移决策要的恰恰是这些：哪些场景会退步，退多少，能不能接受。

顺带说个工程细节。这个项目双轨并行阶段，大型事务按每 400 条 SQL 一组做了拆分。高峰期超 3 万 TPM 压力下，同步延迟少于 1 秒，内存消耗小于 2GB。事务拆分经常被跳过，但它是保证迁移窗口可控的关键动作。

## 兼容 Oracle 的验证清单

**第一步：盘点与静态评估**

- 统计源库对象：表、分区表、视图、序列、触发器、存储过程、包、自定义类型、同义词

- 生成对象画像，标出含 LOB 的表和大表

- 用 KDMS 做一轮自动化评估，拿到不兼容对象清单

**第二步：搭建可验证的测试环境**

- 按实际迁移方案搭 1:1 环境，不要用缩水配置

- 目标是复制生产数据集，用备库形成准生产数据是个省事的办法

- 记录测试环境与生产环境的参数差异

**第三步：执行验证**

- 静态层：对象创建与编译是否通过

- 语义层：改一个兼容参数，跑同一句 SQL，比对结果

- 行为层：设计边界用例，覆盖异常路径、事务粒度、触发器执行顺序

- 性能层：捕获生产负载并回放，减压和加压各跑一轮

**第四步：判定与修正**

- 数据不一致归为正确性问题，必修

- 错误码差异归为兼容性问题，改 SQL 或改参数

- 时延超标归为性能问题，优先调优

- 每开一个兼容参数，留一份对照实验结果

最后一条是我自己踩出来的。我照着一份网上流传的兼容参数清单全开了，跑完测试全绿。上线后报表数据对不上，查了两天才发现。其中一个参数改变了数值的输出格式，而应用层拿字符串在比。参数要一个一个开，每开一个测一轮。这句话后来写进了我们所有迁移项目的检查项。

## 总结

兼容 Oracle 这件事，验证比承诺重要。验证要分语法、语义、行为、性能四层。前三层靠工具能覆盖大半，性能层没有捷径，只能靠真实负载回放。语义差异可以做参数对照实验，做成能复现的用例。官方承认的不兼容边界有限，但能穷举。

回到开头那个问题，怎么证明兼容。答案是拿生产负载在新库上重放一遍，再逐条比对差异。这套方法需要的工具链，KES 这边是齐的。KDMS 做静态评估和语法转换，存量搬迁交给 KDTS。增量同步和双轨并行靠 Kingbase FlySync（金仓异构数据同步软件）。KReplay 管负载捕获与回放，KWR 和 KSH 出性能报告。

具体到兼容能力，KES 的清单是能逐条核的。28 种 Oracle 数据类型全部兼容，26 项内置包支持，131 个兼容视图，`NUMBER` 精度保留 38 位有效数字。这些数在官方文档里都能一条条查到。加上 Oracle 兼容模式在安装时就能选定。整套验证动作都有现成的参数和命令可用。

迁移最贵的一笔从来不是数据库授权费，是应用改造和验证的人力。验证做得越早越像真的，后面返工的概率就越低。小系统也一样，抓一天负载回放一轮的成本，比上线后回滚一天低得多。

各位在迁移项目里踩过哪些「跑通了但跑不对」的坑？欢迎在评论区聊聊。

我是底层玩家老张。咱不聊概念，只聊源码和压测跑出来的东西。

去年有个运营商客户找我做迁移评估。系统是自智网络平台的智能中枢，跑在 Oracle 19c RAC 上。每天 3 亿多次 SQL 交互，实时数据吞吐 125G。这个量级没人敢拍脑袋切库。

兼容Oracle怎么验证？从生产负载捕获到回放报告，一套可落地的评估方案

不谈兼容性有几层，只讲怎么测。从 Oracle 侧负载捕获、OracleDecode 转换到国产数据库侧回放与报告解读，附完整命令、时间缩放语义、语义参数对照实验法，及改写边界清单。

数据库

架构设计

运维

兼容Oracle迁移需四层验证：语法、语义、行为、性能。语义差异可用参数对照实验复现，性能靠真实负载回放（KReplay）。官方不兼容清单有限，含Package同名冲突、Object type连调。运营商项目经24小时负载回放识别12类兼容问题。回放报告重点看DBTime、AAS、UserCalls，差异分数据、错误码、时延三类处理。

数据同步

数据中心

并发测试

文件系统

代码解释

容器

腾讯云BI特惠9.9元起！


2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

兼容Oracle迁移需四层验证：语法、语义、行为、性能。语义差异可用参数对照实验复现，性能靠真实负载回放（KReplay）。官方不兼容清单有限，含Package同名冲突、Object type连调。运营商项目经24小时负载回放识别12类兼容问题。回放报告重点看DBTime、AAS、UserCalls，差异分数据、错误码...

兼容Oracle怎么验证？从生产负载捕获到回放报告，一套可落地的评估方案-腾讯云开发者社区-腾讯云

兼容Oracle怎么验证？从生产负载捕获到回放报告，一套可落地的评估方案

兼容Oracle怎么验证？从生产负载捕获到回放报告，一套可落地的评估方案

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐