# 不止是换库：Oracle到金仓KES企业级关系数据库全流程迁移复盘

**迁移窗口4小时、2TB核心数据、2800个对象——这是某保险公司交出的“停机迁移”答卷**。更大的背景是：**原系统基于Oracle 11g运行超过8年，业务部门只接受“功能不变、性能不降、代码不改”的硬约束**。

金仓KES给出的答案不是“更快的数据库”，而是一套**从评估工具、迁移工具到同步工具的全链路工程化方案**。本文结合多个已完成项目，拆解这套流程中的关键节点与隐性门槛。

## 一、迁移起点不是数据，是兼容度

**“能不能迁”比“怎么迁”更值得花时间**。金仓KDMS（数据迁移评估系统）是正式迁移前的必选项。其工作模式是：**直连Oracle源库或上传SQL脚本，自动扫描表、视图、存储过程、触发器、包等对象，输出不兼容项清单与改造建议**。

某头部保险公司5个核心系统合计10TB数据，KDMS扫描结果显示：**语法兼容度超过98%，需人工干预的PL/SQL不兼容项仅占1.3%**。这份报告让项目组敢于承诺“应用侧修改不足百行”。

**典型不兼容语法示例**（KDMS自动检测并转换）：

```sql

-- Oracle原写法（DBMS_XPLAN）

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR);

-- KES兼容写法（系统内置替换函数）

SELECT * FROM KINGBASE_DISPLAY_CURSOR();

```

**评估阶段的产出不是“能不能做”，而是“哪里要改、改多少行、谁改”**。这是后续所有资源投入的依据。

## 二、环境准备：同名策略与大小写敏感

迁移准备工作中有两个“不遵守必返工”的铁律。

**第一，同名用户、同名数据库、同名模式必须三位一体**。若Oracle源库用户名为`scott`，数据库为`ORCL`，模式为`scott`，则KingbaseES端必须创建同名用户`scott`、同名数据库`ORCL`（属主`scott`）、同名模式`scott`（属主`scott`）。**任何错位都会导致后续对象归属异常，ArcGIS或ODBC连接时报“表或视图不存在”**。

**第二，大小写敏感必须显式关闭**。Oracle默认大小写不敏感，KingbaseES默认敏感。通过初始化参数解决：

```bash

./initdb -D /data -U SYSTEM --case-insensitive

```

**未配置此参数，应用程序中`SELECT * FROM EMP`与`SELECT * FROM emp`会被识别为不同对象，引发大量404错误**。

## 三、数据迁移：KDTS的两种打开方式

KDTS（Kingbase Data Transformation Service）是迁移阶段的核心工具，支持Oracle 9i至19c全系列。**两种形态覆盖不同场景**：

**BS模式（Web界面）**：54523端口打开，向导式配置。适用于手工操作、对象粒度精细控制。步骤为：新建数据源（Oracle源端+KES目标端）→ 选择模式（Schema）→ 勾选迁移对象（表/视图/序列/函数/存储过程）→ 配置参数→ 执行。

**SHELL模式（命令行）**：适用于自动化调度与批量任务。配置文件`datasource-oracle.yml`中填写两端连接信息，`startup.sh`拉起。

**生产级参数调优建议**（某政务系统2.8TB迁移验证）：

```yaml

# KDTS 核心配置节选

batch_write_size: 1000          # 单批写入行数，默认100可提升至1000

source_cursor_fetch: 100        # 源库游标读取记录数

lob_prefetch_size: 4000        # LOB字段预读字节

parallel_max_servers: 64       # 并行线程数（需匹配CPU核数）

<"u7.p5k3.org.cn"><"t9.p5k3.org.cn"><"i2.p5k3.org.cn">

```

**大表拆分机制**：KDTS支持按行数或大小设定拆分阈值，将单张亿级表拆分为多个子任务并行迁移，**某运营商40TB迁移项目中，此机制将全量迁移窗口压缩至5小时以内**。

## 四、在线迁移与双轨并行：业务不中断的代价

对于7×24小时业务，离线迁移不可接受。此时需引入**KFS（Kingbase FusionSync）异构数据同步工具**。

**技术原理**：KFS通过LogMiner解析Oracle Redo日志，实时捕获DML/DDL变更，转换为KES兼容SQL并下发至目标库。

**双轨并行架构**（汕头市中心医院CDR迁移案例）：

1. **存量迁移**：KDTS全量历史数据灌入KES

2. **增量同步**：KFS实时同步Oracle→KES，延迟控制在毫秒级

3. **灰度切流**：前端业务逐个模块从Oracle切换至KES，**每个模块仅需5分钟业务暂停**

4. **回退预案**：若新系统异常，5分钟内切回Oracle，业务无感知

**该方案已通过三甲医院生产环境验证，高峰期3万TPM压力下同步延迟<1秒，内存消耗<2GB**。

## 五、应用适配的三道关卡

**第一关：驱动与连接串**  

JDBC/ODBC连接串从Oracle格式改为KES格式，**端口从1521改为54321，驱动类从`oracle.jdbc.OracleDriver`换为`com.kingbase8.Driver`**。绝大多数应用只需修改配置文件。

**第二关：日期格式陷阱**  

Oracle默认`DD-MON-YY`，KES默认`ISO,MDY`。某项目因源库存在`0099-09-30`历史数据，迁移工具输出`99-09-30`被KES解析为月份99，直接报错`date/time field value out of range`。

**强制统一格式**：

```sql

-- 在kingbase.conf中添加

datestyle = 'ISO,YMD'

-- 或会话级执行

SET datestyle TO 'ISO, YMD';

```

**第三关：ROWID兼容**  

Oracle `ROWID`伪列在KES中通过`OID`伪列替代。需启用参数：

```sql

<"o5.p5k3.org.cn"><"l1.p5k3.org.cn"><"c8.p5k3.org.cn">

SET default_with_oids = on;

```

**此配置必须在建表前完成，否则已创建的表无OID字段**。

## 六、迁移完成后的三件事

**第一，迁移报告与日志归档**。KDTS迁移结果页提供“成功数/失败数/略过数”统计，**失败任务可点击查看详细Error日志**。此记录应作为交付物存档。

**第二，性能基线复测**。某银行迁移后TPC-C测试显示：**KES V9在KXData-S一体机上达到145万tpmC，高于Oracle 19c的123万tpmC**。但这不是必然，需根据实际业务场景重新压测。

**第三，参数固化**。迁移阶段为提升吞吐量开启的`full_page_writes=off`、`wal_buffers=256MB`等参数，**上线前应按生产规范重新评估**。

**从评估到上线，Oracle→KES的全流程已被拆解为可复用的标准化作业程序**。真正的门槛从来不是“技术能不能”，而是“流程敢不敢”——而流程的信心，正来自这套工具链在银行、政务、医疗、运营商领域每年近2000套系统的实弹验证。