简介这是一份由迪思杰北京数码技术有限公司发布的《DSG RealSync复制系统安装配置手册》PDF文档面向从事数据库同步、容灾备份与数据复制工作的开发运维人员。手册系统讲解RealSync复制系统的完整部署与配置流程涵盖源端/目标端安装准备、创建系统用户与目录、安装软件与启动Agent、配置启动脚本、查看进程日志以及注册主机和数据库信息、验证配置、设置映射关系并启动复制等关键环节可帮助读者规避常见配置错误提升跨服务器数据同步的可靠性与排错效率。资源仅含1个PDF文件压缩包大小约1.19MB内容紧凑、目录结构清晰适合作为现场实施时的操作参考。目前已有62人学习使用对于需要快速掌握DSG RealSync复制系统安装配置的工程师而言是一份具备实战指导价值的官方技术资料。1. 用 DataGuard 做不了的事RealSync 复制系统为什么值得装Oracle 环境里做数据同步很多人第一反应是搭 DataGuard。但 DG 只能做整库物理备库一旦遇到只同步这几张表目标端还要做数据加工源端和目标端版本跨代这类需求物理复制就捉襟见肘。DSG RealSync 复制系统走的是日志解析逻辑复制路线在源端读取在线日志和归档日志解析成逻辑变更后发送到目标端由目标端多路装载进程并行写入同时还能挂一个独立的校验进程做数据比对。这份安装配置手册把整个过程拆成了源端 Agent、目标端 Agent、vman 注册配置、日志排查、数据校验五块下面按这个链路逐层拆开把命令、参数和踩坑点都摊开讲。2. 源端安装配置从赋权、建视图到 start_vagentd 脚本改造2.1 建库用户与最小权限复制账号别直接给 dba手册第一步就是在源端创建一个专门的复制账号默认是 dsg/dsg然后按下面这条语句赋权grant select any table to dsg; grant lock any table to dsg; grant select any dictionary to dsg; grant alter system to dsg; grant connect, resource to dsg; grant exp_full_database to dsg; grant imp_full_database to dsg;这里值得多说一句。很多人在做这类复制工具时图省事直接给源端账号一个 dba 角色这在生产库上是高风险操作。RealSync 需要解析数据字典里的表结构、列信息、约束定义所以必须有select any dictionary复制过程中要保证源表数据不被并发 DML 破坏逻辑一致性所以要有lock any table能力alter system是为了触发日志切换或归档操作让捕获进程能更快拿到新的 redo。exp_full_database和imp_full_database也不是白给的首次部署做全量初始化或增量前的老数据补齐时这两个权限能让你直接在源端导出、在目标端导入不用再单独找 DBA 要额外授权。赋予这些权限后建议顺手验证一下用 dsg 用户登录数据库执行select count(*) from dba_tables;能查出数据才说明select any dictionary生效。否则后面 vman 注册数据库时往往会在读取表结构那一步卡住。2.2 DBPS_XKCCLE 与 DBPS_XKCCCP 视图为什么只有源端要建在 Oracle 9i 时代RealSync 需要依赖两个内部视图来定位日志解析的起点和检查点信息。手册里给出的创建语句是这样的connect / as sysdba; create or replace view DBPS_XKCCLE as select * from sys.x$kccle; create or replace view DBPS_XKCCCP as select * from sys.x$kcccp;x$kccle是控制文件 enqueue 相关的内部表x$kcccp是检查点进度相关的内部表。RealSync 在启动捕获时要通过读取控制文件和检查点信息来确定当前该从哪个日志序号开始解析而不是盲目从头扫。这两个视图本质上是把 Oracle 内部 X$ 结构表包了一层可读的视图让 realsync 进程能以普通权限访问而不需要直接碰 sys 对象。注意一点这两个视图只在源端创建目标端不需要。原因很直接——目标端只负责接收和装载解析后的变更数据不干解析日志这件事。有些人在目标端也顺手建了不影响运行但属于多余操作反而占用数据字典空间。如果数据库是 10g 及以上版本一般不需要手工建视图RealSync 会通过其他接口读取此类信息但在手册对应的 9i 场景下这两条 SQL 是安装前必做的准备工作。2.3 setup.sh 交互参数与端口规划源端安装通过拷贝 realsync.tar 解压后执行./setup.sh完成安装过程中会连续询问几个参数下面把每个参数的含义和用途整理成一个表提示项示例值说明setup Directory/realsync软件安装根目录默认当前目录Agent Type1-Source1 表示源端2 表示目标端Source Dbpsd port50001源端数据捕获服务端口Source Vagentd port50002源端 Agent 通信端口Archive log interval12 (小时)日志归档间隔业务越繁忙建议值越小Install elib and biny安装运行库和可执行程序端口规划上有个容易犯的错以为 50001 和 50002 是 vman 的控制端口。实际上 RealSync 的管理控制台 vman 默认连的是 50000Agent 之间通信走 50002捕获服务走 50001另外 vagentd 内部还会监听 6601 这类固定端口。做防火墙策略时要把这几种端口一起放开不能只放一个。归档间隔这个参数如果源端业务变更频繁12 小时很容易让日志文件膨胀到几百 MBvi打开都费劲我一般会让它指到小时级比如 4~6代价是归档文件会多一些但排查问题时反而更好用。2.4 启动脚本改造环境变量、进程启停与缓存清理安装完成后/realsync/scripts下会生成 start_vagentd、stop_vagentd、clean_vagentd、check 四个脚本但默认脚本里的 Oracle 环境变量是占位值必须按下单台数据库实际路径改。改造后的启动脚本核心段长这样export ORACLE_SIDORCL export ORACLE_HOME/oracle/app/oracle/product/9.2.0 export ORACLE_BASE/oracle/app/oracle export LD_LIBRARY_PATH/usr/lib:/usr/ccs/lib:$ORACLE_HOME/lib:$ORACLE_HOME/lib32 export DBPS_HOME/realsync cd $DBPS_HOME export XLDR_HOME$DBPS_HOME/rmp export VCFS_HOME$DBPS_HOME/vcfsa $DBPS_HOME/bin/vagentd 50002 $DBPS_HOME/log/log.vagentd 21 $DBPS_HOME/bin/sender -tseq 1 $DBPS_HOME/log/log.sender 21 export VCFS_HOME$DBPS_HOME/vcfsd $DBPS_HOME/bin/dbpsd 50001 $DBPS_HOME/log/dbpsd_log 21 $DBPS_HOME/bin/arch_vagentd_zk $DBPS_HOME/log/log.vagentd \ $DBPS_HOME/log/archivelog/vagentd_archlog 14400 启动脚本里三个进程的分工是vagentd是源端 Agent 主进程负责监听、调度和通信dbpsd是数据捕获服务真正去读日志、解析日志的就是它sender负责把捕获到的变更数据封装后发送给目标端。后面那个arch_vagentd_zk是日志归档辅助进程按 14400 秒4 小时把旧的 vagentd 日志归档一次避免单个日志文件无限增长。LD_LIBRARY_PATH这里有个常见坑Oracle 的 lib 和 lib32 目录必须都放进去否则 vagentd 启动时会报找不到libclntsh.so这类错误。这是因为 RealSync 的二进制程序编译链接时使用的是 32 位 Oracle 客户端库而数据库本身可能是 64 位。如果启动脚本里只写$ORACLE_HOME/lib不写 lib32在部分平台下进程能起但一执行数据库操作就 core dump。停止脚本的核心逻辑是按端口号精确匹配进程并 killDBPS_PORT50001 pidps -elf|grep dbpsd|grep $DBPS_PORT|grep -v grep|awk {print $4} if [ ! -z $pid ]; then for id in $pid; do kill -9 $id; done fi AGN_PORT50002 pidps -elf|grep vagentd|grep $AGN_PORT|grep -v grep|awk {print $4} if [ ! -z $pid ]; then for id in $pid; do kill -9 $id; done fi这段脚本的关键在于grep $AGN_PORT这个过滤条件它保证了你只会杀掉指定端口上的 vagentd不会误伤同机其他实例的 Agent。如果你在一台服务器上同时跑两套复制链路这个过滤条件就是隔离的第一道保障。清除缓存脚本clean_vagentd会清理/realsync/rmp和/realsync/vcfsa下的临时文件每次重启 Agent 前先执行一次可以避免上次异常退出留下的脏数据干扰本次启动。提示修改 start_vagentd 时确保 oracle 系统用户对 /realsync 目录有读写权限否则即使 root 手动启动成功也会在写缓存文件时失败。3. 目标端安装配置多路 loader 装载与 verify 校验进程3.1 目标端与源端的权限差异目标端的准备工作和源端有一个显著不同不需要创建DBPS_XKCCLE和DBPS_XKCCCP视图。原因前面讲过目标端不做日志解析自然用不到控制文件和检查点定位。权限方面手册给的是grant connect, resource, dba, exp_full_database, imp_full_database to dsg;这里直接给了 dba因为目标端要建表、建索引、写数据、跑校验权限面比源端宽是合理的。但要注意这意味着 dsg 账号在目标库上拥有极高的权限必须限定这个账号只能用于 RealSync 复制链路不能借给别人做日常查询。同时目标端的 realsync 安装目录也要独立挂载不要和源端共用同一个物理路径否则两边进程写同一个 cache 目录会互相踩。3.2 loader 并行装载qno 与 -s/-r 参数目标端安装过程最后一步会询问 the number of parallel loader process: 1-10这个参数直接决定目标端能开多少个装载线程。安装完成后start_vagentd脚本里会按你填的数字生成对应的 loader 启动行默认 10 路的效果类似下面这样$DBPS_HOME/bin/loader -s -qno 0 1 $DBPS_HOME/log/log.s0 21 $DBPS_HOME/bin/loader -s -qno 1 1 $DBPS_HOME/log/log.s1 21 $DBPS_HOME/bin/loader -s -qno 2 1 $DBPS_HOME/log/log.s2 21 $DBPS_HOME/bin/loader -s -qno 3 1 $DBPS_HOME/log/log.s3 21 $DBPS_HOME/bin/loader -s -qno 9 1 $DBPS_HOME/log/log.s9 21 $DBPS_HOME/bin/loader -r -qno 0 1 $DBPS_HOME/log/log.vagentd 21 参数含义-s启动一个装载子进程slave loader负责把队列数据写入目标库-r启动接收进程receiver负责从源端接收数据并分发到各个队列-qno N指定队列编号从 0 开始最大到 9末尾的1线程模式标志固定为 1这套设计解决的核心问题是单线程装载变成瓶颈。源端抓取和生产变更的速度可能非常快如果目标端只有一个进程在写库延迟会越堆越高。10 个-s子进程各自独立连接数据库、独立提交事务-r进程只是把收到的数据按某种规则分发到不同队列整体吞吐量能得到数量级提升。但并行度不是越大越好10 路装载意味着目标库同时最多开 10 个并发写会话如果目标库硬件本身不行或表上有大量触发器和约束反而可能拖垮数据库。这里要记住另一个细节写完 loader 启动行后目标端stop_vagentd脚本里也要有对应清理逻辑否则 loader 进程残留在后台下次启动会报端口或队列冲突。检查脚本check里会列出将要运行的进程启动后第一件事就是跑一遍 check确认 loader 的进程数和你预期一致。3.3 校验进程start_verify 与符号链接RealSync 的目标端还可以单独启动一个校验 Agent用来做源端和目标端的数据比对。手册里校验进程的启动脚本是 start_verifyexport DBPS_HOME/realsync export XLDR_HOME$DBPS_HOME/rmp/verify export VCFS_HOME$DBPS_HOME/vcfsa/verify $DBPS_HOME/bin/vagentd.verify -l -onlycheck 50012 $DBPS_HOME/log/verify_log 21 $DBPS_HOME/bin/arch_verify_dt $DBPS_HOME/log/verify_log \ $DBPS_HOME/log/archivelog/verify_archlog 43200 50012 是默认的校验服务端口与主复制链路的 50002 隔离互不干扰。-l和-onlycheck组合起来是只做校验、不做装载的模式避免校验进程误写目标表。启动校验前clean_vagentd 脚本里会重建/realsync/rmp/verify和/realsync/vcfsa/verify目录同时需要建立符号链接ln -s /realsync/rmp/imp_dbsaleinst1 /realsync/zk/rmp/verify ln -s /realsync/rmp/cfg.xf1t.struct /realsync/zk/rmp/verify这两条软链把实际的结构化文件目录映射到校验进程可识别的路径下。如果漏了这一步校验进程启动后会在日志里报类似verify dir not found的错误但 vagentd 主进程不受影响因为它是独立进程所以这种问题经常被忽视实际跑数据比对时就一直没结果。提示clean_vagentd 会清空 rmp 和 vcfsa 下的缓存如果先启动主复制再启动校验务必检查 verify 软链是否还在避免清理操作把链接间接破坏掉。4. vman 控制台注册主机、数据库与映射关系4.1 vman 登录与菜单结构两端 Agent 都启动后配置复制关系的入口是 vman 控制台。它不在 Web 界面里操作而是走命令行交互cd /realsync/bin ./vman vman connect :50000 dbps user root/dbps SYNC:/ menu第一行是连接管理服务50000 是控制端口不是 Agent 通信端口。默认管理账号是 root/dbps这个账号密码在安装日志里有记录如果改过就用自己的。连上后输入menu会进入功能菜单手册里展示的菜单项包括 System、Scheduler、Version Management、Backup、Physical Restore、Logical Restore Recovery、Job Management、Change Management 等。实际配置复制关系主要用 System 和 Job Management 两块System 管主机和数据库注册Job Management 管复制任务。注意 vman 的交互式提示符在不同层级会变从vman到dbps再到SYNC:/每个层级能用的命令不一样。很多人第一次用的时候在SYNC:/下敲connect会报错因为这个命令只在vman层有效。4.2 注册主机与数据库进入 System 子菜单后先注册主机再注册数据库。手册里给出的交互路径是SYNC:/ menu 1 (System) 2 (Host)注册主机时需要填写主机名、IP 地址、操作系统类型、Agent 端口源端写 50002。主机注册完再进 System 下的 Database 菜单登记数据库实例信息数据库类型Oracle、版本、SID、连接串、对应的复制账号dsg/dsg。这一步是把哪台机器、哪个实例、用什么账号连接这三个信息绑定在一起。注册完别急着往下走手册里专门有一步验证配置是否正确。在 vman 中有 list 命令可以列出已注册的主机和数据库并查看状态是否为 online。我一般会做两件事一是在目标数据库服务器上用 dsg 账号手动sqlplus连一次确认网络通、账号通、权限够二是在源端执行lsnrctl status确认监听正常。这两步能筛掉 80% 的配置错误来源尤其是主机名解析问题——很多局域网环境里/etc/hosts没有配全vman 里填了完整主机名Agent 之间靠主机名互相访问就超时。4.3 映射关系与启动复制的顺序映射关系是复制任务的核心配置指定源端哪个 schema 的哪些表复制到目标端哪个 schema 的哪张表。操作路径在 Job Management 下新建一个复制任务选择源数据库、目标数据库然后添加映射规则。这里最关键的步骤是先做全量初始化再启动增量复制。常见的初始化做法有三种一是源端 exp 导出目标端 imp 导入二是通过数据库 dblink 直接create table as select三是如果目标端已经存在相同结构和数据跳过初始化直接做增量。前两种方式适合首次搭建链路第三种方式适合目标端本来就是从源端恢复出来的备库场景。映射关系设置后启动复制并不是立刻开始抓日志而是先做一次全量同步再进入增量抓取状态。手册里首次同步后的工作指的就是观察全量同步是否完成、增量是否开始追、追平后延迟是否保持在合理范围。判定标准很简单在源端对某张被复制的表执行一条 update几秒钟后去目标端按主键查这条记录能看到更新后的值就说明链路通了。如果迟迟不更新优先查目标端 loader 日志而不是源端抓取日志多数情况是装载端堵住了。5. 日志视角排查复制故障抓取、发送、装载三段链路5.1 源端确认抓取与发送在跑源端日志目录在/realsync/log需要重点看三个文件log.vagentd、log.dbpsd、log.sender。cd /realsync/log tail -f log.vagentd tail -f log.dbpsd tail -f log.senderlog.vagentd 正常启动时会输出类似DBPS agent running on hostname (Listening any:6601)和DBIInit multi-threaded mode的信息说明 Agent 主进程起来了。log.dbpsd 里出现Data Capture services started和PSM services started这两行说明捕获服务正常。log.sender 则是判断数据有没有在往外发如果这个文件长时间没有任何输出说明源端没有捕获到新的变更先检查源库有没有产生 redo再看 log.dbpsd 是否处于等待状态。有一种常见情况源端业务低峰期 sender 日志完全不增长这不算故障因为根本没有新变更要发。真正的报警信号是 log.vagentd 里出现IPC_KEY相关报错或者在明确有业务写入的情况下目标端就是收不到数据。这时候用ps -ef | grep sender看 sender 进程在不在如果进程在但日志不动重启一下 sender 往往能恢复。5.2 目标端确认接收与装载在跑目标端日志文件更多因为每个 loader 子进程都有自己的日志文件cd /realsync/log tail -f log.vagentd tail -f log.s0 tail -f log.s5log.vagentd 里同时包含接收进程的输出如果源端 sender 发数据过来了这里能看到接收条数的增长。log.s0 到 log.s9 分别对应 10 个装载子进程哪个队列在忙、哪个队列空闲从日志时间戳就能判断出来。校验进程的日志在 verify_log跑比对任务时这个文件会输出比对进度和差异记录。判断装载是否堵住有个很实用的方法连续执行两次ls -l /realsync/log/log.s0看文件大小如果间隔五分钟文件大小纹丝不动说明这个队列没有新任务进来。再用ps -elf | grep loader看 loader 进程的 CPU 使用率如果 CPU 一直是 0% 而日志里有写入报错那就要查目标库的锁、表空间和归档空间是否够用。5.3 高发故障与处理下面这个表整理了部署和运行中高频出现的几类问题现象可能原因处理方法vagentd 启动失败日志报 IPC_KEY 冲突上次进程未完全退出或同机多实例共用 key先停干净所有 realsync 进程再执行 clean_vagentd 后重启源端 Agent 起来但捕获不到新数据视图 DBPS_XKCCLE 缺失或 sys 用户权限不对用 sys 用户重新执行建视图 SQL确认无报错目标端 loader 日志大量报错但主链路正常目标表结构不一致或约束冲突核对源表和目标表的列、类型、主键定义网络层丢包导致发送超时防火墙只放了 50001/50002没放 6601/6600检查两端通信端口范围保证 Agent 内部端口也通复制延迟持续拉大且 loader CPU 占满目标库写入慢或并行装载度配置过高降低 loader 并行数观察目标库负载曲线处理排障时有个原则先在源端确认有没有抓到再在目标端确认有没有收到最后才看为什么装不进去。大多数延迟问题都出在目标端装载而不是源端抓取因为源端通常只读日志性能压力远小于目标端写库。6. 数据比对与单表全同步的实操套路6.1 手工比对按主键分批做校验值对比RealSync 的 verify 进程能做自动比对但手工写 SQL 做快速一致性检查仍然是最灵活的方式。常见的做法是分别计算源表和目标表每个主键批次的行数及校验值把结果汇总后做差集-- 源端计算每 10000 行一个批次的校验值 select floor(rownum / 10000) batch_id, count(*) row_cnt, sum(ora_hash(col1 || | || col2)) hash_sum from source_table group by floor(rownum / 10000); -- 目标端执行同样逻辑然后两边的 batch_id 做 full outer join 对比ora_hash是 Oracle 自带哈希函数把关键列拼起来求哈希值能快速识别哪一批数据有差异定位到批次后再缩小范围到具体主键。如果你的数据库版本支持DBMS_COMPARISON也可以直接用这个包它能把比对逻辑封装得更好但手工 SQL 方式不依赖任何额外包在跨版本场景下更通用。6.2 单表全同步推荐流程手册里提到如何进行单表全同步但没有展开细节实际运维中这类需求经常出现某张表漏了几条数据或者映射规则改了需要重新同步。我会按下面这个顺序操作在目标端按源端表结构创建一张空表结构、主键、索引完全一致在源端用 exp/expdp 导出这张表的数据再在目标端导入在 vman 中为这张表建立映射关系指定从当前日志位置开始增量追平启动复制后观察源端 sender 日志确认该表变更已经发送用上一节的批次校验 SQL 对比源端和目标端确认行数和校验值一致第一步里完全一致四个字很关键我曾经因为目标端少了普通索引导致装载时全表扫描延迟从秒级变成分钟级排查了很久才发现是索引缺失。第三步尤其注意一定要在全量导出导入完成后再建立映射如果先建映射再导数据增量日志里会记录导出期间产生的 DML导入完成后这些变更再播放一遍就会产生主键冲突。整个流程跑通后我会把校验 SQL 固化成一个巡检脚本每周对核心复制表跑一次行数和校验值对比结果有差异就自动报警。复制链路不是配完不管的主动做数据一致性巡检比单纯看进程存活状态可靠得多。本文还有配套的精品资源点击获取