我最近看 GBase 8c 迁移资料时，一个感觉越来越明显：Oracle 迁移最难的部分，通常不是"数据怎么导"，而是"业务对象和 SQL 行为迁过去以后还能不能按原来的预期跑"。
GBase 8c 在设计上本来就考虑了异构迁移场景，支持 Oracle、PostgreSQL、MySQL、Teradata 等多种兼容模式；其中 Oracle 兼容场景对应的是 A 模式，而且这个兼容模式是在建库时确定的，后面不能直接通过 SQL 再改。A 模式下还有两个很关键的行为差异：空字符串会按 NULL 处理，DATE 会替换为 TIMESTAMP(0) WITHOUT TIME ZONE。这两个点如果前面没想清楚，后面业务测试时很容易踩坑。
从落地角度看，我更倾向把 GBase 8c 的 Oracle 迁移拆成四层来看：
先确认库级兼容模式，再做对象和数据类型适配，再看业务 SQL 和过程逻辑，最后才进入数据迁移、同步和割接。
官方社区的 Oracle 迁移方案也基本是按这个思路展开：迁移准备、评估、对象迁移、数据迁移、业务 SQL 迁移、实时同步、校验、割接和后续运维，是一整套链路，不是单一的数据搬运动作。
一、先别急着建表，第一步应该先把兼容模式定死
这个点我个人比较在意。
因为很多迁移项目一开始最容易犯的错，就是目标库建好了，后面才发现兼容模式不对，然后对象、函数、数据类型和业务 SQL 的适配成本一下子全上来了。
GBase 8c 的库级兼容参数是 DBCOMPATIBILITY，A 表示兼容 Oracle，B 表示兼容 MySQL，C 表示兼容 Teradata，PG 表示兼容 PostgreSQL。社区说明里写得很清楚：这个参数只能在建库时确定，后期不能直接改。 对 Oracle 迁移来说，目标库通常就应该是 A 模式。
一个更贴近现场的建库方式通常是这样：
CREATE DATABASE core_oracle_mig
WITH ENCODING = 'UTF8'
DBCOMPATIBILITY = 'A'
OWNER mig_owner;
这里真正需要提前确认的，不只是"是不是 A 模式"，还包括下面这两件事：
| 检查项 | GBase 8c A 模式表现 | 迁移时要注意什么 |
|---|---|---|
| 空字符串 | 视为 NULL |
应用里如果依赖 '' 和 NULL 区分，要重点回归 |
DATE 类型 |
会替换为 TIMESTAMP(0) WITHOUT TIME ZONE |
时间精度、显示格式、比较逻辑要复核 |
这两个点看起来像小细节，但真正落到业务里，影响并不小。尤其是表单类系统、老 ERP、审批系统一类应用，很多逻辑会把空字符串当成"已填写但为空"，把 NULL 当成"未赋值"。一旦语义合并，条件判断和唯一性判断都可能受影响。
二、对象迁移里最先要看的，不是表有多少张，而是用了哪些 Oracle 特性
我自己理解下来，Oracle 迁移适配真正麻烦的，不是普通表、普通索引和普通视图，而是那些"平时感觉很正常，真迁移时才发现平台差异很大"的对象和语法习惯。
GBase 8c 的 Oracle 迁移方案里，把迁移评估放得很前，迁移工具也支持评估报告、对象迁移、规则转换、错误明细查看和二次修正，这说明官方本身就不把迁移看成"直接导完就结束"的动作。
真正落到现场，我一般会先把源库对象按风险拆成三档：
| 风险级别 | 常见对象/特性 | 我更常见的处理方式 |
|---|---|---|
| 低 | 普通表、主键、普通索引、基础视图 | 工具迁移 + 核对结构 |
| 中 | 序列、同义词、触发器、函数、过程 | 逐项验证语义 |
| 高 | 包、复杂动态 SQL、依赖空串语义的逻辑、特殊内置函数 | 手工改造 + 业务回归 |
这个分法的意义在于，团队不会把精力平均撒在所有对象上。
真正该优先啃的，通常是中高风险对象，而不是普通表结构。
三、数据类型别只做"语法映射"，更要看业务语义是不是还能对上
社区兼容说明里已经给出了 Oracle 兼容场景下的一些典型写法，比如 A 模式下支持 NUMBER、VARCHAR2、Oracle 风格的建表和索引语法。也就是说，从"能不能建出来"这个角度看，GBase 8c 对 Oracle 友好度并不低。
但从实际迁移角度看，我更关注的是语义对齐，而不是"DDL 能执行通过"。
比如下面这种表定义，在 A 模式里语法上通常比较顺：
CREATE TABLE cust_order (
order_id NUMBER PRIMARY KEY,
customer_no VARCHAR2(32) NOT NULL,
order_amt NUMBER(18,2),
order_date DATE,
remark VARCHAR2(200)
);
看起来很顺，但真正上线前，我更会重点看这几类列：
1）DATE / TIMESTAMP
前面提到过，A 模式下 DATE 会替换为 TIMESTAMP(0) WITHOUT TIME ZONE。
这意味着如果应用里有大量日期截断、日期比较、字符串格式化输出，就要把测试重点放在时间精度和比较逻辑上。
2）VARCHAR2 和空串逻辑
如果 Oracle 侧原本就接受空字符串按 NULL 语义处理，那迁到 A 模式通常更顺；
但如果应用层、接口层或者中间层做了自定义空串判断，迁移后还是要回归。
3）NUMBER(p,s)
这个一般问题不大，但真正要复核的是上下游程序是不是把它强绑定成某种 Java、C# 或脚本语言类型。
很多迁移问题不是数据库内核不兼容，而是 ORM 和应用 DTO 精度没对齐。
我最近整理下来觉得，类型映射更适合按这个思路验：
| 检查维度 | 只看 DDL 是否成功 | 更稳妥的做法 |
|---|---|---|
| 字段类型 | 能建表就算过 | 还要看插入、比较、排序、格式化 |
| 时间列 | 能存就算过 | 还要核对精度、默认值、日期函数 |
| 字符列 | 能查就算过 | 还要核对空串、长度、字符集行为 |
| 数值列 | 能转就算过 | 还要核对精度、四舍五入、应用绑定类型 |
四、真正容易出问题的，通常不是 DDL，而是业务 SQL 的行为差异
Oracle 迁移到 GBase 8c，业务 SQL 适配往往比对象结构更耗时间。
官方迁移方案里专门把"业务 SQL 迁移流程"单拎出来，而且强调可以通过业务采集和分析，统计 SQL、数据量、宽表、性能指标，再给出更优的迁移方案。这其实已经说明，SQL 兼容不能只靠人工拍脑袋。
我自己在看这类迁移时，通常会先盯下面几类 SQL：
1）依赖 Oracle 特殊语义的 SQL
比如和空字符串、日期隐式转换、某些内置函数写法强绑定的语句。
2）大量嵌在应用代码里的动态 SQL
这类 SQL 最大的问题不是语法复杂，而是"数据库里找不全"。
只迁对象不采集业务 SQL，后面最容易漏。
3）分页、排序、聚合、函数调用较重的语句
这类 SQL 语法可能能过，但行为和性能不一定完全等价。
社区资料提到，GBase 8c 提供完善 SQL 支持和丰富函数库，并且 Oracle 迁移方案里会结合业务采集工具分析实时 SQL、采样业务数据和性能指标。这个组合我觉得很关键，因为它把"兼容"从静态 DDL 提升到了动态业务行为层。
一个更稳妥的改造方式，通常不是直接全量替换，而是先把高频 SQL 拉出来做分层：
| SQL 类型 | 风险 | 我更建议怎么处理 |
|---|---|---|
| 简单 CRUD | 低 | 自动迁移后抽样验证 |
| 复杂 JOIN/聚合 | 中 | 回归结果集和执行行为 |
| 过程/函数驱动 SQL | 高 | 单独专项验证 |
| 应用拼接动态 SQL | 高 | 通过采集工具补全 |
五、序列、自增和默认值这些"看起来不难"的点，反而很容易漏
很多项目在 Oracle 里都习惯用序列配合触发器或应用取号逻辑。
GBase 8c 社区兼容示例里也展示了序列相关能力，比如 CREATE SEQUENCE、nextval(...)、ALTER COLUMN SET DEFAULT nextval(...) 这些模式是支持的。虽然示例更多是 PG 兼容场景，但它说明 GBase 8c 本身在序列机制上是有成熟能力的。
真正落地时，我更建议把取号逻辑单独列成一张清单去排查：
- 是应用自己查序列；
- 还是触发器补主键；
- 还是中间件生成；
- 还是数据库默认值负责。
比如迁到 GBase 8c 后，更适合统一成默认值方式的场景，可以写成：
CREATE SEQUENCE seq_order_id START WITH 1000001 INCREMENT BY 1 CACHE 100;
ALTER TABLE cust_order
ALTER COLUMN order_id SET DEFAULT nextval('seq_order_id');
这个点的关键不是语法，而是别让同一套系统里出现多种取号方式混用 。
不然迁移后最容易出现的不是 SQL 报错，而是主键冲突、号段跳变、批量写入不一致。
六、迁移实施里我更认可"评估---演练---同步---割接"这条线，不太认可直接一把切
GBase 8c 的 Oracle 迁移方案里，流程讲得比较完整：
先做源库环境分析和迁移评估，再做方案设计和测试，再进入迁移实施、监控、性能调优和割接，期间还支持对象迁移、数据迁移、数据同步和数据校验。社区文章也提到会使用 CDC、Streaming 和日志解析去感知变化，降低割接窗口压力。
从实际场景看，我自己更倾向于下面这种节奏：
1）先评估，不先承诺"几天迁完"
评估的重点不是数据量有多大，而是：
- 对象复杂度；
- SQL 改造量；
- 兼容模式是否选对；
- 实时同步窗口是否可行；
- 业务停机容忍度。
2）先演练，不先正式割接
演练至少要覆盖：
- 对象迁移成功率；
- 数据校验；
- 高风险 SQL 回归；
- 增量同步链路；
- 回退方案。
3）正式迁移时把"全量 + 增量 + 校验"串起来
这一步不是只看全量数据能不能导完，而是看正式割接时差异能不能收敛。
如果用一句更直白的话说：
Oracle 迁移到 GBase 8c，真正稳的做法不是"一次搬完"，而是"先把静态对象和全量数据搬过去，再用增量把时间差追平"。
七、字符集和兼容行为别放到最后看，不然后面问题会特别碎
虽然这次主题是 Oracle 迁移，但兼容说明和其他迁移实践里都反复提到，字符集、长度语义、兼容模式下的类型行为，都会直接影响迁移结果。比如 PG 模式和其他模式在 CHAR/VARCHAR 的计数单位上就有差异；兼容性说明也强调，不同模式下数据类型和函数支持是有区别的。
这个信息给我的启发其实很直接：
迁移前千万别把"兼容"理解成所有行为自动完全一致。
所以我一般会把下面这些项拉到迁移前期就确认：
| 检查项 | 为什么要前置 |
|---|---|
| 兼容模式 | 建库后很难回头 |
| 字符集/长度语义 | 容易影响字符串截断、排序、展示 |
空串与 NULL |
容易影响业务条件判断 |
| 日期类型与默认值 | 容易影响时间比较和展示 |
| 高风险函数/过程 | 容易影响核心业务链路 |
这类问题如果放到数据已经迁完、联调都开始之后才看，改起来会特别碎。
八、我更常用的一套 Oracle 迁移到 GBase 8c 的检查顺序
如果把前面的内容收成一套更容易落地的顺序，我一般会这样做：
第一步：先确认目标库就是 A 模式
这一步最基础，但也最不能错。DBCOMPATIBILITY='A' 只能建库时定。
第二步：做迁移评估，不只看表数量
重点看对象复杂度、函数过程、动态 SQL、序列和触发器、应用依赖行为。
第三步：先迁对象，再看高风险改造清单
普通对象自动化迁，复杂对象和高风险 SQL 单独改。
第四步：抓业务 SQL，而不是只看数据库对象
很多真实问题都在应用层拼接 SQL 里。官方也建议通过业务采集工具分析 SQL 和性能指标。
第五步：做全量 + 增量同步 + 校验演练
不要直接把第一次正式迁移当演练。
第六步：割接前重点回归这几类行为
- 空串与
NULL - 日期和时间精度
- 序列/主键生成
- 复杂过程和函数
- 高频业务 SQL 返回结果是否一致。
九、我更认可的一种结论：Oracle 迁移做得顺不顺，关键不在"导数速度"，而在"兼容边界有没有提前看透"
我自己理解下来，GBase 8c 在 Oracle 迁移这件事上，基础能力是够用的：
有 A 模式兼容，有类型和 SQL 支持，有迁移评估、对象迁移、数据迁移、实时同步、校验和割接链路。单看这些能力，很多项目确实能把"搬过去"这件事做成。
真正决定项目后面顺不顺的，往往还是下面这些更具体的东西：
- 建库时兼容模式有没有选对；
- 空串和时间类型语义有没有提前验；
- 高风险对象和业务 SQL 有没有被完整识别；
- 迁移是不是走了演练和增量追平，而不是一次性硬切；
- 应用是不是只做了"能连上库"的验证，而没做行为一致性验证。
从实际项目看，越是核心系统，越不能把迁移理解成"数据导入项目"。
它更像一次数据库平台切换下的兼容改造工程。
前面把兼容边界看透了，后面上线会轻很多；前面只盯导数和割接时间，后面通常会在 SQL、对象行为和业务回归上把时间补回来。
参考资料
1\] 南大通用GBase 8c迁移指南之Oracle篇 https://www.gbase.cn/community/post/5710 \[2\] 【解决方案】从Oracle迁移至南大通用GBase 8c https://www.gbase.cn/community/post/3746 \[3\] GBase 8c 兼容模式使用说明 https://www.gbase.cn/community/post/4011 \[4\] GBase 8c兼容性说明 https://www.gbase.cn/community/post/4047