企业官网建设流程全解析

简介：面向数据库管理员、数据运维工程师及信息化团队，DSG Realsync管理维护手册系统讲解基于日志级的实时同步复制技术。内容涵盖日志抓取、分析、交易合成、交易传输与数据装载的完整原理，逐一说明首次全同步、复制关系维护、DML/DDL操作复制支持，并给出常见不支持操作的处理建议。手册同时附有各复制端口功能一览表、软件部署结构说明、发起全同步并启动复制流程，以及源端/目标端目录和重点文件配置讲解，方便管理员日常巡检、性能调优和故障排查。资源共包含1个doc文档，大小350KB，结构清晰、可直接按章节查阅，覆盖从部署到排错的完整运维链路。目前已有121人学习下载，适合正在使用或评估迪思杰Realsync同步工具的技术人员快速掌握同步复制机制的落地要点。

1. Realsync 数据库同步复制工具，为什么说维护重点不在同步算法

Realsync 是迪思杰（DSG）的数据库同步复制工具，核心思路是在源端读取 Oracle Redo Log，分析出完整交易后以 XF1 格式发送到目标端装载。和直接传归档日志、目标端做 recover 的方案相比，它传的是分析后的交易，数据量小，目标端数据库可以保持打开状态。真正需要运维人员上心的不是同步算法本身，而是端口分配、日志分析间隔、DDL 过滤规则和队列积压这几个维护点。这份管理维护手册适合两类人看：一类是刚接手 Oracle 到 Oracle 实时同步的 DBA，需要快速理解链路里每个进程在干什么；另一类是已经在跑 Realsync、但遇到增量延迟或目标端数据不一致时不知道怎么定位的运维工程师。整套内容的组织顺序是同步原理、链路拆分、部署目录、日常命令，最后是两个容易漏掉的细节。

2. 复制链路拆分：日志抓取、交易合成与 XF1 装载

2.1 日志抓取：SCN 轮询与 Online Log Cache

Realsync 在源端的 Agent 并不会持续盯着日志文件，而是定期查询 Oracle 系统视图中的当前 SCN 号，判断有没有新交易产生。SCN 变了才去读取对应 Redo Log 组和日志位置，抓取的日志先落到 Online Log Cache，再交给下一步分析。这样设计的直接好处是避免频繁读取日志文件带来的 I/O 开销，对生产库影响比较小。手册给出的设计目标是每秒能分析约 10MB 日志量，运维调优时可以以这个数值为基准推算同步延迟。

维护时如果要确认日志抓取是否正常，可以对照查看数据库日志状态：

SELECT CURRENT_SCN, STATUS FROM V$DATABASE; SELECT GROUP#, SEQUENCE#, STATUS, BYTES / 1024 AS SIZE_MB FROM V$LOG ORDER BY GROUP#;

第一句检查当前 SCN 和数据库状态，第二句查看日志组序号、状态和大小。V$LOG 中如果长时间只有一两个 ACTIVE 且没有归档行为，说明日志切换或归档可能出了问题，Realsync 日志抓取会跟着延迟。日常巡检时把这两条 SQL 的输出和源端 Agent 日志里的 SCN 做对比，能快速判断是数据库侧没产生日志，还是 Agent 没抓到日志。

2.2 交易合成：为什么以 Transaction 为单位

Redo Log 中一个交易的多条 SQL 并不是连续存放的，多个交易相互穿插，而且日志里同时包含已提交、未提交、回滚三类内容。Realsync 的交易合成模块会先按交易序号把 SQL 归组，然后只把已提交的交易送去传输。未提交的交易暂存在本地缓存，等后续日志中看到该交易提交后再发送；回滚的交易直接丢弃，不进入传输环节。

这个设计对目标端非常重要。如果按单条 SQL 为单位传输，目标端会反复处于中间状态，一旦传输中断，很难判断哪些数据是有效的。以交易为单位传输后，目标端收到的每个包都是一个完整提交的事务，装载失败时可以直接定位到整个交易并做重放处理。

生产环境中常见的一个误区，是看到源端日志里有大量未提交事务就以为同步滞后。其实只要这些交易没有提交，Realsync 不传输是正常行为。真正该关注的是已提交交易从出现在日志到送达目标端的时间差。

2.3 XF1 格式与 ROWID Mapping 装载

XF1 是 DSG 的专有数据格式，用来表达 SQL 指令，优势在于可以直接转换成 Oracle 内部数据表达格式，不需要经过完整的 SQL 层解析。Oracle 提供了 User、SQL、Transformation、I/O 四层接口，普通 JDBC 或 SQL*Plus 装载走 User 层，而 XF1 装载尽量下沉到 I/O 层，省掉 parse、plan 带来的开销。

另一个关键点是 ROWID Mapping。Update 和 Delete 在没有主键的情况下定位记录很慢，Realsync 在首次全同步或首批 insert 时建立源端 rowid 到目标端 rowid 的映射表，装载时直接按目标端 rowid 定位写入位置，避免在大量并发 DML 中反复扫描索引。每条记录的映射关系是在该记录执行 insert、sql loader 或首次批量同步时建立起来的。

这也是实际项目中 Realsync 目标端负载通常远低于源端的原因。维护人员要留意的不是装载 SQL 优化，而是映射表是否完整。全同步后如果源端出现大量 nologging 操作，映射关系可能没有建立起来，后续更新会定位失败，这类问题往往只能重新全同步恢复。

3. 部署目录与端口配置：源端和目标端的对应关系

3.1 源端安装目录里该盯哪些文件

Realsync 源端目录结构并不复杂，常见安装路径是 /oracle/realsync，各子目录职责如下：

$REALSYNC_HOME/ ├── config/ # 复制对象、DDL过滤、日志分析间隔等配置 ├── scripts/ # 全同步与启停脚本，如 full_sync_ds.sh、start_dsg.sh ├── bin/ # Agent 可执行程序，涉及日志抓取与发送 ├── log/ # 运行日志，排障时优先查看 └── rmp/ # XF1 队列缓存，判断是否积压看这里

config 目录是维护重点，复制关系、过滤规则都在这里修改。scripts 目录里维护脚本的执行用户和权限要保持一致，常见做法是统一用 oracle 系统用户执行。log 目录日志文件增长很快，磁盘写满会直接拖住 Agent。rmp 目录是交易数据暂存区域，日常说的 XF1 积压就体现在这里。下文命令里$REALSYNC_HOME指 RealSync 的安装根目录，实际环境中通常是 /oracle/realsync 或 /dsg/realsync。

3.2 目标端安装目录与源端的差别

目标端目录比源端少一个 config 目录，接收和装载程序在 bin 下，scripts 里主要是 full_sync_dt.sh、start_dsg_dt.sh 这类配套脚本。目标端 log 中重点是装载日志，rmp 目录同样用于队列缓存。

两端 rmp 目录要区分看待：源端 rmp 积压说明日志分析或传输慢，目标端 rmp 积压说明装载能力不足或目标库存在锁等待。

3.3 端口分配与防火墙放通

Realsync 两端进程通过固定端口通信。源端 dbpsd 监听管理控制连接，目标端 vagentd 接收传输进程发来的交易包。典型端口对应关系如下：

本地复制和远程复制通常会各分配一套端口，项目里见过 60000/60001 与 50000/50001 并存的情况。配置变更后检查监听是否生效：

netstat -tlnp | grep -E "60000|60001"

输出里能看到 dbpsd 或 vagentd 进程监听对应端口即正常。防火墙策略要单独放通这两个端口，不要简单关闭系统防火墙了事。另外端口不要和生产数据库监听端口混在一起，避免网络管理员误判，也不要让其他进程占用这些端口。

4. 日常维护命令：进程检查、日志监控、队列积压与重新全同步

4.1 进程检查与正常启停

Realsync 的日常检查通常从进程和队列两个维度入手。源端进程与目标端进程分别负责不同阶段，检查命令：

ps -ef | grep -E "dbpsd|vagentd|sender|loader" | grep -v grep

输出里应能看到源端 dbpsd、sender 以及目标端 vagentd、loader 对应进程。grep sender 时要注意区分同名操作系统进程，建议先执行ps -ef | grep realsync看完整路径，再做精确匹配。若某一边进程反复重启或不稳定，先看 log 目录下对应日志，不要直接 kill 后重启，否则可能丢掉未完成队列。

常规启动和停止顺序有讲究。停止时先停源端再停目标端，避免目标端还在收数据源端已经不在；启动时反过来，先启源端抓取日志，再启目标端等待接收。常见做法是通过 scripts 下脚本执行，例如启动源端执行 start_dsg.sh，启动目标端执行 start_dsg_dt.sh：

# 启动源端 Agent /oracle/realsync/scripts/start_dsg.sh # 启动目标端 Agent /oracle/realsync/scripts/start_dsg_dt.sh

提示：执行脚本前确认当前用户是 oracle，且脚本有执行权限。用 root 执行会有目录权限问题，进程起不来还容易留下半启动状态。

4.2 日志监控：分析日志和装载日志分开看

源端日志重点看日志分析是否跟上生产写入速度，目标端日志重点看装载失败。查看最新日志文件：

cd $REALSYNC_HOME/log ls -lt *.log | head tail -f $(ls -t *.log | head -1)

第一行列出按修改时间倒序的日志文件，第二行跟踪最新文件的末尾。看到持续有内容输出说明进程在工作；长时间没有新输出要检查进程是否假死。排查错误时用关键字过滤：

grep -iE "error|ora-|fail" $REALSYNC_HOME/log/*.log | tail -50

ORA- 后面的编号就是 Oracle 错误码，比如 ORA-01403 表示记录未找到，通常和 ROWID Mapping 失效有关；ORA-00001 表示主键冲突，常见于目标表已有数据时重复装载。目标端装载日志里出现约束类错误时，先确认是不是做过重复初始化，不要急着清队列。

4.3 队列积压：xf1 文件数量怎么看

交易数据以 XF1 格式暂存在 rmp 目录中等待发送或装载。检查积压最直接的方法是统计 rmp 目录文件数量与增长趋势：

ls $REALSYNC_HOME/rmp/*.xf1 2>/dev/null | wc -l find $REALSYNC_HOME/rmp -name "*.xf1" -mmin +10 | wc -l

第一行统计当前未处理文件总数，第二行统计超过 10 分钟仍未处理的文件数。如果总数持续增长，说明产生速度大于消费速度；如果存在大量超过 10 分钟的文件，基本可以断定某一段链路卡住了。定位思路是：源端 rmp 积压看 sender 进程是否正常、网络是否通畅；目标端 rmp 积压则查看目标库的锁等待、装载进程是否存在死循环。

4.4 重新全同步：四步脚本流程

当目标端数据不一致、发生大量 nologging 操作导致增量丢失，或者复制关系大范围调整时，需要重新发起全同步。Realsync 手册中的标准流程是四步：

# 1. 停止并清空源端 realsync 程序 /oracle/realsync/scripts/full_sync_ds.sh # 2. 停止并清空目标端 realsync 程序 /oracle/realsync/scripts/full_sync_dt.sh # 3. 重新启动源端 realsync 程序 /oracle/realsync/scripts/start_dsg.sh # 4. 重新启动目标端 realsync 程序 /oracle/realsync/scripts/start_dsg_dt.sh

顺序不能颠倒：先清源端再清目标端，避免源端还在推数据而目标端队列被清空导致数据缺口。启动是源端在前、目标端在后，全同步开始后源端先把当前数据全量装载到目标端，这个阶段目标端 rmp 和装载日志都会有明显活动。

确认全同步结束并进入实时同步阶段，可以看两个信号：目标端日志中不再出现全量装载条目；源端 rmp 目录文件数量下降并保持稳定，且源端日志中的 SCN 持续推进。若全同步后目标端仍有大量错误，检查是否清空不彻底，需要重新执行两个清空脚本再走一遍流程。

5. 两个容易被忽略的运维技巧：DDL 过滤与分析间隔调整

5.1 过滤破坏性 DDL：三级别配置

同步环境里最怕的不是 DML 量大，而是误操作把 drop table、truncate table 也复制到目标端。Realsync 支持 database、user、table 三个级别的 DDL 过滤，分别控制不同范围。database 级可过滤 role、user、dblink、profile 这类对象操作；user 级可配置某个 schema 下所有 drop table 等破坏性操作不同步；table 级则针对指定的重要表，避免核心表被 truncate 影响。

配置位置在源端 config 目录的过滤列表中，维护时修改后需要重启源端 Agent 生效。验证过滤是否生效，最安全的做法是在测试库上执行一条被过滤的 DDL，比如对一张测试表执行 truncate，然后检查目标端对应表是否还在。目标端表未受影响说明规则已加载。注意过滤规则只影响后续 DDL，已经到达目标端的交易不会被追回。

5.2 调整日志分析间隔：先观察再修改

日志分析间隔决定了 Agent 多久检查一次 SCN。间隔太短，源端 CPU 消耗增大；间隔太长，同步延迟变高。这项参数没有固定最优值，与生产库日志产生量、Agent 所在主机性能都有关系。我一般会这样调：先用默认间隔运行一两天，记录源端 Agent 的 CPU 占用率和 rmp 目录的积压情况。如果 CPU 占用不高但同步延迟明显，就把间隔调小一档；如果 CPU 已经偏高且 rmp 文件还在增加，问题通常出在分析性能或传输链路上，继续调小间隔只会让情况更糟。

修改间隔同样在 config 目录中完成，调整后重启源端进程，观察日志中 SCN 推进与日志分析耗时的变化。验证方法可以直接对比源端 Redo Log 产生时间和目标端装载完成时间之间的差值。注意不要为了追求低延迟把间隔调到极小，Realsync 作为日志级复制工具，保留一个合理的批处理窗口反而能提升整体吞吐。

本文还有配套的精品资源，点击获取