简介：迪思杰RealSync部署手册面向数据库运维人员与系统集成工程师，聚焦Oracle环境下数据复制软件的安装与配置，帮助读者在源端与目标端完成RealSync的完整部署。手册以doc文档形式呈现，压缩包内共1个文件，大小约129KB，内容按源端、目标端及系统参数设置三大模块组织，涵盖创建操作系统用户与数据库用户、创建数据库视图、登陆系统主机、安装RealSync软件、启动Agent与Dbpsd等关键步骤，并给出注册主机和数据库信息、配置同步内容、发起首次同步的操作指引。目录层级清晰，步骤编号明确，便于按序查阅与落地实施。目前已有128人学习下载，适合需要快速掌握RealSync复制软件部署流程、对照排查安装配置问题的技术人员参考使用。
1. 迪思杰 RealSync 部署手册：从零搭起一套异构数据库实时同步链路
第一次接触迪思杰 RealSync 的人，多半是被一个具体需求推着来的：生产库是 Oracle，报表库想换成 MySQL 或者达梦，业务不能停，数据延迟还得压到秒级。这时候翻到一份《迪思杰 RealSync 部署手册.doc》，标题看着简单，真正落地时才发现里面藏着源端抽取、目标端装载、网络链路、字符集、DDL 同步一大堆细节。RealSync 是迪思杰（DSG）做异构数据库实时复制的一套工具，核心思路是在源库侧捕获增量日志，经过解析、转换后投递到目标库，实现准实时的数据同步。它适合的场景很明确：跨数据库类型、跨操作系统、要求低延迟且不能大改现有业务系统的数据集成项目。这篇笔记不照搬手册目录，而是按一线部署顺序，把环境准备、参数配置、启动验证和踩坑排查讲清楚，让新手能照着走，熟手能对参数边界心里有数。
2. 部署前必须想清楚的选型与环境账
2.1 RealSync 到底解决哪类同步问题
先把定位说清楚，不然后面参数全是玄学。RealSync 属于基于日志的增量复制工具，和基于触发器、基于时间戳轮询的方案比，它对源库性能影响小，延迟低，能拿到变更的完整前后镜像。和同类的 Oracle GoldenGate、阿里 DTS 比，它的差异点在于对国产数据库和异构组合的支持更贴国内项目实际，比如 Oracle 到达梦、Oracle 到 MySQL、DB2 到 Oracle 这类组合。选它之前先确认三件事：源库是否开启了归档或补充日志、目标库的写入权限是否给全、网络是否允许源端和目标端之间稳定通信。这三条任何一条不满足，后面部署都会卡住。
常见做法是先做一次全量初始化，再用增量追平。全量阶段用导出导入或者工具自带初始化，增量阶段靠日志捕获。很多人一上来就配增量，结果目标库是空的，同步跑起来全是 update 找不到记录，这就是顺序错了。
2.2 源端与目标端的硬性检查清单
部署前把下面这张表逐项过一遍，比事后排错省事得多。
| 检查项 | 源端要求 | 目标端要求 |
|---|---|---|
| 数据库版本 | 确认在 RealSync 支持矩阵内 | 同样确认支持矩阵 |
| 日志模式 | Oracle 需归档+补充日志 | 无特殊要求 |
| 账号权限 | 读取日志、查询字典视图 | 建表、增删改、DDL 权限 |
| 字符集 | 记录源库字符集 | 目标库字符集需兼容或可转换 |
| 网络 | 到目标端端口可达 | 到源端端口可达 |
| 磁盘 | 日志保留空间充足 | 数据文件空间按增量预估 |
补充日志这条最容易翻车。Oracle 默认只记录部分列，RealSync 要拿到完整行镜像，必须开ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;，对关键表还要加ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS。不开的话，同步过去的 update 只有主键没有其他列，目标端数据就是错的。
2.3 安装包与依赖的落地准备
拿到安装介质后，先确认操作系统位数、glibc 版本、JDK 版本。RealSync 服务端一般跑在 Linux 上，管理控制台可能是 Java 客户端。部署顺序通常是：先装服务端，再配源端和目标端的连接信息，最后在控制台里建同步任务。安装目录别放系统盘，日志增长比想象中快。依赖方面，确认libaio、unzip这些基础包在，Oracle 客户端或对应数据库驱动要提前装好，否则连不上库。
提示：安装前把源库和目标库的时区、NTP 对齐，时间不一致会让延迟统计和日志定位出现偏差。
3. 一步步把 RealSync 服务端和同步任务跑起来
3.1 服务端安装与初始化
假设安装包解压到/opt/dsg/realsync，用专用账号运行，不要用 root 直接跑服务。下面是一段典型的初始化命令流程。
# 创建专用用户和目录 useradd -m dsguser mkdir -p /opt/dsg/realsync chown -R dsguser:dsguser /opt/dsg # 解压安装包 su - dsguser cd /opt/dsg unzip RealSync_Server_x.x.x.zip -d /opt/dsg/realsync # 执行安装脚本，按提示指定安装路径和端口 cd /opt/dsg/realsync ./install.sh安装脚本会问安装路径、管理端口、日志路径。管理端口默认常见是 8xxx 段，冲突就换。安装完成后会生成服务启动脚本，一般在bin目录下。逻辑说明：专用用户是为了权限隔离，避免服务进程拿到过高系统权限；单独目录是为了后续升级和日志清理方便。参数上，日志路径建议单独挂盘，保留天数按增量量估算，别用默认的 7 天，生产环境往往要留 30 天以上做回溯。
3.2 配置源端和目标端连接
服务端起来后，进管理控制台配置数据库连接。源端要填主机、端口、实例名、账号密码，还要指定日志读取方式。目标端填连接信息即可。配置时注意账号密码里如果有特殊字符，在配置文件里要转义，否则解析失败。
# 启动服务端 cd /opt/dsg/realsync/bin ./start.sh # 查看服务状态和端口监听 netstat -tlnp | grep 8xxx tail -f ../log/realsync.log启动后先看日志有没有报连接失败、驱动缺失。常见报错是ORA-01031: insufficient privileges，说明源端账号权限不够，补上SELECT ANY DICTIONARY、SELECT ANY TRANSACTION这类权限。目标端如果报字符集不匹配，要么改目标库字符集，要么在任务里配转换规则。
3.3 建同步任务的参数怎么设
建任务时几个关键参数决定同步行为。同步类型选全量+增量；冲突处理策略选覆盖或忽略，按业务定；批量提交大小影响性能和延迟，一般 500 到 2000 行一批；DDL 同步开关看目标端能不能接受结构变更，生产上建议先关，手动评审后再开。
-- 源端 Oracle 开启补充日志，这是增量同步的前提 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS; -- 确认补充日志状态 SELECT supplemental_log_data_min, supplemental_log_data_all FROM v$database;逻辑说明：第一条开启最小补充日志，第二条对全列记录镜像。查询返回 YES 才算生效。参数上，ALL COLUMNS会增加日志量，磁盘要留够。如果只对部分表同步，可以只对这些表加补充日志，减少开销。
3.4 启动同步并做第一轮验证
任务建好后先别急着上生产，拿一张测试表验证。在源端插入、更新、删除各一条，看目标端是否在秒级内一致。
# 源端执行 INSERT INTO test_sync(id, name) VALUES (1, 'a'); UPDATE test_sync SET name = 'b' WHERE id = 1; DELETE FROM test_sync WHERE id = 1; # 目标端查询确认 SELECT * FROM test_sync WHERE id = 1;验证顺序是：先看任务状态是否 running，再看延迟指标，最后比对数据。延迟指标在控制台能看到，如果一直增长说明追不上，要调批量大小或检查网络。数据比对建议用行数和校验和，别只看几条记录。第一轮验证通过后再逐步加表，别一次性全库上。
4. 部署中最容易翻车的几个点
4.1 补充日志没开全导致 update 丢列
现象：目标端 update 后只有主键变了，其他列还是旧值。原因：源端只开了最小补充日志，日志里没有完整行镜像。解决：对相关表执行ALTER TABLE xxx ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;，然后重启同步任务重新初始化。这个坑血泪经验最多，很多人以为是工具 bug，其实是日志没配全。
4.2 字符集不一致导致中文乱码
现象：目标端中文变成问号或乱码。原因：源端和目标端字符集不同，且没配转换。解决：先确认两边字符集，SELECT * FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET';，能统一就统一，不能统一就在任务里配字符集映射。注意 UTF8 和 AL32UTF8 不是一回事，别混。
4.3 大事务导致延迟飙升
现象：源端跑了一个百万行的事务，目标端延迟从秒级涨到几十分钟。原因：RealSync 按事务提交才投递，大事务要等提交后才开始传。解决：业务上拆大事务，或者调大批量提交参数，同时确认网络带宽够。这个没有银弹，只能从业务侧配合。
4.4 目标端主键冲突导致任务中断
现象：任务报 duplicate key，然后停了。原因：全量初始化时目标端已有数据，或者增量重放顺序问题。解决：初始化前清空目标表，或者配冲突策略为覆盖。任务中断后要看日志定位到具体表，处理完再重启，别直接忽略。
4.5 网络抖动导致连接断开不自动重连
现象：任务状态变成 disconnected，数据不再同步。原因：网络不稳定，或者防火墙断了长连接。解决：配心跳和自动重连参数，防火墙放行长连接。生产环境建议源端和目标端之间走专线或稳定内网，别跨公网。
5. 把同步链路做稳的几个进阶习惯
部署跑通只是开始，真正难的是长期稳定。我一般会做三件事。第一，建监控，盯延迟、任务状态、日志错误关键字，延迟超过阈值就告警。第二，定期做数据比对，不用全库，抽核心表按行数和校验和比，发现漂移早处理。第三，保留后悔药，源端归档日志别删太早，目标端定期备份，出问题能回溯。
验证同步是否真正可靠，可以做一个反向校验脚本，定期在源端和目标端跑同样的聚合查询，比对结果。
-- 源端和目标端分别执行，比对结果 SELECT COUNT(*) AS cnt, SUM(amount) AS total FROM orders WHERE create_time > SYSDATE - 1;两边结果一致才算同步正常。参数上，比对频率按业务敏感度定，核心表可以每小时一次，非核心每天一次。这个习惯能帮你提前发现很多隐性不一致，比等业务报障强。
最后一个技巧是版本升级和补丁。RealSync 不同版本对数据库版本支持不一样，升级前先在测试环境验证，别直接在生产上打补丁。升级前备份配置文件和任务定义，出问题能快速回滚。我自己就吃过没备份配置的亏，重配任务花了大半天。希望帮到你。
本文还有配套的精品资源，点击获取
