作者：任仲禹，爱可生数据库专家，OBCE 认证专家，擅长故障分析和性能优化。
爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。
本文约 3000 字，预计阅读需要 10 分钟。
1. 前言
国内某客户，其主要业务系统运行在 IBM DB2 、Microsoft SQL Server 等数据库上。在国产化数据库适配过程中， OceanBase 分布式数据库[1] 因其高效性能成为承载其核心业务系统优选之一。
过往异构数据库到 OceanBase 的数据迁移主要由 OceanBase 官方自研的 OMS[2] 迁移工具去实施，但目前官方 OMS 工具还不支持迁移 SQL Server 数据库。由此，2025 年爱可生[3] 基于 OMS 4.2 版本源码自研的 Action OMS 迁移工具 支持了 SQL Server 该品类数据库，填补了 OceanBase 迁移生态这一空白。
什么是 Action OMS？
Action OMS 基于 OMS 本身的优秀能力，并依托于爱可生公司在数据库及周边工具的多年开发经验、对数据迁移/同步过程的深刻理解与运维经验，推出的定制化版本。
Action OMS 由 OceanBase 向爱可生进行了全部代码授权，可对 OMS 问题进行源码解释并修复，同时可以接受定制化开发的 OMS 版本。
下面，我们将介绍 Action OMS 的产品特性和 SQL Server 业务数据库的迁移实践与经验分享。
1.1 Action OMS 功能介绍
除了 兼容官方 OMS 4.2 版本所有功能，Action OMS 还具备如下特性：
-
数据迁移
支持 SQL Server 数据库 2008/2012/2014/2016/2017/2019 企业版本迁移到 OceanBase 数据库。
-
数据订阅
支持 SQL Server 、DB2 等数据库的实时数据订阅，实时捕获和订阅数据库的变更事件，适用于数据分析、审计、报表查询等多种业务场景。 实现上，除了源端的表结构的业务字段外，Action OMS 会新增数据订阅功能所需的列，自动在目标端创建，用于存储原始的变更记录。
例如：源库表中存在一条主键 ID = 1 的行，删除后。该【删除操作】将被 Action OMS 捕获到 OceanBase 中，存储为【一条 ID = 1，但标识列 __dts_operation = 1 的行】。
1.2 迁移涉及组件版本
本文业务系统迁移时涉及的软件版本如下：
-
Microsoft SQL Server 2016 (RTM) – 13.0.1601.5 (X64) -
Enterprise Edition (64-bit) on Windows Server 2019 Standard 6.3
-
-
OceanBase V4.2.5 BP5 -
Kylin-Server-V10-4.19.90-89 x86_64
-
-
Action OMS 4.25.09.0
2. 源端 SQL Server 准备
2.1 准备源端迁移用户
先检查源端 SQL Server 数据库工程提供的用户名是否具备 Action OMS 所需迁移权限。
SQL Server 数据库的迁移用户需要具备 sysadmin、db_owner 权限。
# 登录到 SQL Server 数据库中执行
select is_srvrolemember('sysadmin'),is_member('db_owner');
预期返回值：1 和 1。
若权限不满足，可以参考如下命令创建并授予。
# 切换到 Master 数据库中，创建登录名，并设置密码
USE master;
CREATE LOGIN [renzy] WITH PASSWORD = 'Password!123',
DEFAULT_DATABASE = [master],
CHECK_EXPIRATION = OFF,
CHECK_POLICY = OFF ;
# 将登录名加入 sysadmin 服务器角色
ALTER SERVER ROLE [sysadmin] ADD MEMBER [renzy];
# 切换到待迁移业务库如 subscribe 中，创建数据库用户（如 renzy），并关联到登录名（如 renzy）
USE subscribe;
CREATE USER [renzy] FOR LOGIN [renzy] WITH DEFAULT_SCHEMA = [dbo];
# 将数据库用户 renzy 加入目标数据库的 db_owner 角色
ALTER ROLE [db_owner] ADD MEMBER [renzy];
2.2 确认 SQL Server Agent 服务已开启
查看 SQL Server Agent 服务运行状态，确保处于 Running 状态。
# 切换到待迁移业务数据库执行 exec master.dbo.xp_servicecontrol N'QUERYSTATE',N'SQLSERVERAGENT';
预期返回值 “Running.”。
2.3 确认数据库 CDC 已开启
对于 SQL Server 数据库的迁移、订阅，Action OMS 依赖于 SQL Server 自带的 CDC（Change Data Capture） 变更捕获功能。
对启用了 CDC 的表执行 INSERT、UPDATE、DELETE 操作时，CDC 会自动将变更记录的副本以及相关元数据（如操作类型、时间）捕获到特定的“变更表”（如 cdc.fn_cdc_get_all_changes_<capture_instance>）中。
select NAME,recovery_model_desc,is_cdc_enabled from sys.databases;
预期返回 recovery_model_desc 为 FULL，is_cdc_enabled 为 1。
若未开启，可参考如下命令进行开启。
# 切换到待迁移业务数据库下执行 EXEC sys.sp_cdc_enable_db;
2.4 确认业务表 CDC 已开启
数据库与业务表的 CDC 是独立的，需要单独确认待迁移的业务表是否开启了 CDC 功能。
# 切换到待迁移的数据库中执行， ## 未开启的表 select NAME,TYPE,TYPE_DESC,is_tracked_by_cdc from sys.tables WHERE is_tracked_by_cdc = 0 AND SCHEMA_ID=1 ORDER BY NAME; ## 已开启的表 select NAME,TYPE,TYPE_DESC,is_tracked_by_cdc from sys.tables WHERE is_tracked_by_cdc = 1 AND SCHEMA_ID=1 ORDER BY NAME;
预期返回值 is_tracked_by_cdc 为 1。
2.5 确认业务表存在主键
目前 Action OMS 仅支持数据迁移与订阅【具有主键或非空唯一索引】的表。需要在迁移前，与业务侧沟通需迁移的业务表是否包含主键或非空唯一索引。
# 切换到待迁移数据库执行，主键表和无主键表数量检查示例 SELECT TABLE_SCHEMA,PRIMARY_KEY,COUNT(*) FROM ( SELECT SCHEMA_NAME(T.SCHEMA_ID) AS TABLE_SCHEMA, CASE WHEN K.NAME IS NOT NULL THEN 'HAS_PRIMARY_KEY' ELSE 'NO_PRIMARY_KEY' END AS PRIMARY_KEY FROM SYS.TABLES T LEFT JOIN SYS.key_constraints K ON T.object_id = K.parent_object_id AND K.type ='PK' WHERE T.TYPE='U' AND T.SCHEMA_ID = 1 ) A GROUP BY TABLE_SCHEMA,PRIMARY_KEY;
注意：Action OMS 会自动过滤无主键或非空唯一索引的表，不会显示在迁移对象中。
无主键表详细列表查询示例。
SELECT SCHEMA_NAME(T.SCHEMA_ID) AS TABLE_SCHEMA,T.NAME FROM SYS.TABLES T where T.schema_id =1 AND T.name not like AND T.object_id NOT IN ( SELECT K.PARENT_OBJECT_ID FROM SYS.key_constraints K WHERE K.type ='PK' ) ORDER BY T.NAME;
3. 配置迁移与订阅链路
Action OMS 的安装部署不赘述，参考 OB 官网 OMS 4.2 安装手册[4] 即可。
3.1 添加 SQL Server 数据源
Action OMS 工具部署完成后，可以添加源端 SQL Server 的数据源。
注意：每个数据源仅能添加一个 SQL Server 的 DataBase。
测试连接成功后，确定即可。
3.2 添加 OceanBase 数据源
以添加 OceanBase（MySQL 模式）数据源如下。
3.3 配置迁移链路
在 Action OMS 数据迁移模块中，新建-数据迁移链路。
注意：目前 Action OMS 暂不支持同步 DDL 。
注意：源端 SQL Server 默认 Schema 名为 dbo【固定的】，在目标端 OceanBase 中建议【重命名】为具备业务标识的数据库名称。
链路的参数配置根据实际环境设定即可，建议【不允许索引后置】。
预检查完毕后，启动项目即可。
数据迁移链路正常输出如下所示。
3.4 全量校验数据
Action OMS 对于 SQL Server 数据库的迁移链路与其他数据库一样，支持全量校验等功能，可自行进行全量校验或正向切换。
注意：因为源端生产业务在持续变更，全量迁移过程中可能会有不一致的表，可以选择再次校验、或校验不一致的表。
3.5 配置订阅链路
在 Action OMS 数据订阅模块中，新建-数据订阅链路。
目前仅支持到数据库的订阅同步方式。
数据订阅功能当前支持结构创建、增量订阅的功能，不会对源端业务表历史存量数据进行【全量迁移】，所以若业务侧需要迁移完整的业务表数据到 OceanBase 中，还需要配合前文的数据迁移链路实现。
注意：目前暂不支持同步 DDL。
选择订阅对象时，可以自定义业务表后缀名【默认 _DTS_CT 】，以跟数据迁移的同名业务表做区分。
设置订阅选项。
注意：订阅选项中，增量同步的【起始位点】必须在源端 SQL Server 中业务表开启 CDC 功能之后，且 CDC 数据未被清理。
预检查通过后，启动项目即可。
数据订阅链路正常输出如下所示。
3.6 订阅数据检查
对于数据订阅功能，链路正常运行时，可以检查业务表的表结构与增量数据是否符合业务预期。
在 OceanBase（MySQL 模式）中可以看到业务表会比源端多 4 个字段，用作记录变更标识、事务提交时间等记录。
检查 OceanBase 中业务数据，可以跟 SQL Server 中【cdc.dbo_业务表名】进行主键或其他字段对比。
4. 适配 SQL Server 的注意事项
在数据迁移或订阅、适配 SQL Server 到 OceanBase（MySQL 模式）数据库时，因为涉及异构数据库应用，有较多的 SQL 语义差异需要特别注意，例举部分如下文所示。
4.1 SQL Server 中 timestamp 的语义问题
SQL Server 中 timestamp 的定义和 OceanBase（MySQL 模式）的 timestamp 定义完全不一样。
SQL Server 的 timestamp（现推荐用 rowversion）与 MySQL 的 timestamp 虽然名称相同，但本质是完全不同的两种类型。
目前 Action OMS 针对该 CASE 的解决方式是在【结构迁移】时默认转为 binary(8)，而不是语义完全不同的 OceanBase timestamp。
4.2 SQL Server 中的 bit 的语义问题
某些业务表在 SQL Server 中是 BIT 数据类型，同步到 OceanBase（MySQL 模式）后也是 BIT 数据类型，但是 SQL Server 与 OceanBase 的语义完有差异，前者是布尔值（0 或 1），后者是二进制数据类型。
-
数据同步后，两边存储的值通过不同工具查询会有不一样的效果。 -
通过如 JDBC 等应用侧获取时，SQL Server 与 OceanBase（MySQL 模式）可以正常返回。 -
但是对于命令行工具如 mysql、obclient 等，查询 OceanBase（MySQL 模式） 时，需要对 BIT 类型字段通过 bin()函数才能返回正确结果。
select bin(BIT_COLUMN) from table_name;
5. 总结
本文通过在某企业 SQL Server 迁移至 OceanBase 的用户实践案例，介绍了 Action OMS 迁移工具相关特性。如支持 SQL Server 2008 – 2019 企业版迁移到 OceanBase 数据库、支持 SQL Server、DB2 等数据库实时数据订阅等特色功能。
同时，详细介绍了 SQL Server 迁移到 OceanBase 过程中需要的准备工作、配置步骤、注意事项等；验证了通过 Action OMS 工具可以实现准实时、低延迟的数据订阅功能，可以为业务系统的分析报表、统计与审计类工作带来极大便利，也为其它行业的 SQL Server 业务数据库的国产化迁移改造工作提供一些经验与参考。
[2] OMS: https://www.oceanbase.com/product/oms
[3] 爱可生: https://www.actionsky.com/
[4] 部署 OMS: https://www.oceanbase.com/docs/enterprise-oms-doc-cn-1000000000613367