简介SQL Server 2000 数据库同步与复制配置讲解文档面向需要在多个 SQL Server 2000 实例间保持一致数据库结构的 DBA、运维与开发人员。文档围绕发布-订阅复制机制先梳理六项准备创建同名 Windows 用户、设置共享快照目录、调整 SQLSERVERAGENT 启动账户、启用 SQL Server 和 Windows 混合身份验证、互注册对方服务器、为纯 IP 环境配置服务器别名再说明配置分发服务器、创建事务发布或合并发布、添加订阅服务器的流程并标出快照权限、distributor_admin 密码、发布表需带主键等易错点。压缩包内为单个 PDF 文件约 114KB步骤清晰、可对照逐步实施。已有 855 人学习。1. 为什么 SQL Server 2000 数据库同步是一件绕不开的工作sqlserver 2000 数据库同步说白了就是把一台老库里的表持续搬进另一台 SQL Server 2000既要不丢数据又不能在搬运时把正在跑业务的源表锁死。这个场景在今天的生产环境里依然真实存在MES、计量、财务这类老系统被业务一直养着配套应用只认 SQL Server 2000可报表库、容灾库、测试库又都指着同一份数据这就是数据库同步问题的起点。它适合三类人接手维护老系统的新人给老库做容灾或迁移的 DBA以及需要在两个 2000 实例之间做读写分离的架构师。这里真正要解决的不是“换成新数据库”的规划问题而是把同步链路做成可靠、可验证、出了故障能在半小时内恢复的工程。2. SQL Server 2000 同步路线先按实时性、冲突、成本做完选型2.1 事务复制是原生方案里唯一接近实时的选项事务复制Transactional Replication是 SQL Server 2000 原生同步方案里能力最强的一种。它的工作模型是发布服务器上有一个 Log Reader 进程持续扫描事务日志把发布表中被标记为复制的变更解析成命令写入分发数据库Distribution订阅服务器再从分发服务器拉取这些命令在目标库上重放。整个过程对业务系统透明应用层完全感知不到同步存在。这种方案适合两种典型场景。一是生产库和报表库之间做近实时只读副本延迟通常在秒级到十几秒。二是作为灾备的数据层补充在日志传送尚不可用或不想恢复整个库时事务复制能保证主库的增量在目标端持续落库。实际部署里需要注意发布表必须有主键。主键不只是建索引用的后续 UPDATE 和 DELETE 都要靠它在订阅端定位行。没有主键的表在 2000 的发布向导里根本加不进去强行用 sp_addarticle 也会报错。还要明确一个边界事务复制默认是单向的主库写、订阅库只读。如果想双向同步得用合并复制Merge Replication但 2000 的合并复制在冲突检测和优先级配置上非常繁琐生产库一旦并发写冲突处理代价远超省下的那一台机器成本。我对事务复制的定位是默认第一选择只有当目标端版本差太多、或者连分发服务器权限都拿不到时才退到第 4 章的 DTS 路线。2.2 DTS 与链接服务器适合按批同步而不是实时事件DTSData Transformation Services是 SQL Server 2000 时代的官方数据搬运工具在 2005 里被 SSIS 取代。DTS 包可以定义数据源、目标、转换规则和任务流可以手动跑也能由 SQL Agent 作业定时触发。相比事务复制DTS 不解析事务日志它是一段时间内对源库做查询拉取对源库的压力是突发的适合离线批量同步。另一个配合组件是链接服务器Linked Server。它让一条 T-SQL 能直接跨实例访问对象典型写法是 SELECT * FROM [SYNC_TARGET].[erp].dbo.orders把远程表当本地表一样读。DTS 包里的“执行 SQL 任务”配合链接服务器写同步逻辑是老库之间最灵活的增量同步姿势。DTS 链接服务器的短板很明确没有自动断点、没有命令冲突检测、跨实例写操作还要依赖 MSDTC。网络一抖动批处理跑到一半失败下次再跑就可能重复 UPDATE 或漏掉一批数据。所以我会在目标表上建联合主键同步脚本里用“先 UPDATE 后 INSERT 目标表不存在才插入”的写法把幂等性先兜住。这套脚本放在第 4 章可以直接抄作业。2.3 日志传送整个库的一致副本不是表的同步日志传送Log Shipping在 SQL Server 2000 企业版里提供。原理是定期备份主库的事务日志文件传输到目标服务器目标服务器按顺序恢复RESTORE WITH NORECOVERY 或 STANDBY。它同步的粒度是“整个数据库”而不是某几张表目标实例最终得到的是一个完整、处于恢复状态的一致性副本。日志传送的实时性取决于日志备份间隔常见做法是五分钟到十五分钟做一次日志备份。目标库在 STANDBY 模式下可以只读查询但不能写。它适合需要完整库做报表、或者做容灾演练的团队但没法单独同步两张表——附带整个库意味着日志文件越来越多恢复链越拉越长中间任何一份日志文件损坏就得重启整条链。选型时经常有人纠结一个库里十张表业务上只关心其中两张表的变化却想配日志传送。这是典型的方案错配。表级同步用事务复制库级容灾用日志传送别混着用。如果连企业版都没有日志传送直接不用考虑。2.4 选型对照延迟、冲突、初始化、版本要求方案同步粒度延迟目标端可写初始化方式版本要求事务复制表级秒级到十几秒不可写单向快照或备份发布端需标准版DTS链接服务器自定义 SQL分钟级到小时级可以自行编写所有版本日志传送整个库分钟级只读全备日志链仅企业版备份还原整个库小时级可读可写全备差异所有版本补充一个经验市面上各种数据库同步软件/数据库同步工具看上去安装快、配置简单但对 SQL Server 2000 这种老实例驱动和兼容性往往比原生方案更折腾。同步工具大多按 2005 以后的机制设计对 2000 的 SQLOLEDB 连接方式、timestamp 列行为、隐式事务处理都可能水土不服。原生方案能跑通的我一般不动工具因为工具的坑比原生知识点更难在搜索引擎里找到答案。3. 用事务复制跑通两个 SQL Server 2000 库配置命令与参数3.1 同步前检查版本权限、网络连通、目标库准备配置发布之前先确认两端环境是健康的。在源库和目标库各执行一次SELECT VERSION AS ver, SERVERPROPERTY(Edition) AS edition, SERVERPROPERTY(IsClustered) AS is_cluster逻辑说明这条语句分别返回版本号、版本类型企业版/标准版、是否集群实例。SQL Server 2000 的标准版可以当发布服务器做事务复制但日志传送必须企业版这一步先确认版本能省掉后续不少弯路。参数说明SERVERPROPERTY(Edition) 返回的字符串要能区分标准版和企业版如果显示 Developer 或 Evaluation 也要意识到功能限制。网络连通性上SQL Server 2000 默认实例监听 1433 端口命名实例依赖 SQL Browser 服务。命令行验证方式就是 telnet 目标 IP 1433看能否连上端口。这一步容易被忽略但偏偏是复制作业最常翻车的点SQL Agent 服务没启动。Log Reader 进程和分发进程都由 SQL Agent 拉起SQL Agent 一停复制就卡在“未启动”状态数据完全不动。所以配置前我习惯先看一遍服务管理器里的 SQL Agent 状态。版本补丁方面源和目标如果都跑 SQL Server 2000尽量都装到 Service Pack 4。2000 早期版本的复制有大量和日志读取相关的 bug很多在 SP4 里才修掉裸奔版本配复制就是给自己挖坑。3.2 配置分发与发布sp_adddistributiondb 别用默认保留期分发服务器可以和发布服务器放在同一台机器上。在源库执行下面的命令exec sp_adddistributor distributor Nsource01, password N exec sp_adddistributiondb database Ndistribution, data_folder ND:\MSSQL\Data, log_folder ND:\MSSQL\Log, max_distretention 96, history_retention 48逻辑说明第一句把当前实例配置成分发服务器第二句创建分发数据库所有等待分发的复制命令都会先写进这里。参数说明里最值得关注的是 max_distretention它的单位是小时控制已分发命令在分发库里保留多久常见默认值是 72 小时。我改成 96 是给周末停机留一点余量——一旦订阅端离线超过这个窗口订阅就过期后面第 5 章会专门讲到这个坑。data_folder 和 log_folder 指向分发数据库的数据和日志目录要确认磁盘空间足够复制积压时这里涨得很快。然后创建发布exec sp_addpublication publication Npub_erp, repl_freq Ncontinuous, status Nactive, sync_method Nconcurrent, retention 0, immediate_sync Nfalse exec sp_addarticle publication Npub_erp, article Norders, source_object Norders, destination_object Norders, type Nlogbased逻辑说明sp_addpublication 定义发布属性sp_addarticle 把源库里的 orders 表加为发布项。参数说明repl_freq 用 continuous 表示持续从日志采集变更sync_method 用 concurrent 表示生成初始快照时尽量不长时间锁表这是 2000 里对在线业务最友好的方式typelogbased 明确这是一张事务复制类型的表。发布表必须有主键没有主键 sp_addarticle 会直接报错先在源表上补主键再回来加文章。3.3 创建订阅并初始化快照concurrent 模式避免锁表创建订阅最可靠的方式是在企业管理器里跑创建订阅向导向导最后一步可以选择生成 SQL 脚本。这里给一段最简化的命令行写法方便理解底层动作exec sp_addsubscription publication Npub_erp, subscriber Ndb02, destination_db Nerp_report, sync_type Nautomatic, subscription_type Npush exec sp_addpushsubscription_agent publication Npub_erp, subscriber Ndb02, subscriber_db Nerp_report, subscriber_login Nsa, subscriber_password NYourPwd, frequency_type 0x10逻辑说明sp_addsubscription 在订阅库注册订阅sp_addpushsubscription_agent 创建负责推送的调度进程。参数说明sync_typeautomatic 表示订阅创建后自动生成并应用初始快照subscription_typepush 表示推订阅分发服务器主动把数据推给订阅端frequency_type0x10 在 2000 里表示连续运行。我一般选推订阅而不是拉订阅因为分发进程跑在分发服务器上账号密码统一收口排查问题时只需要盯一台机器。订阅服务器上不要预建同名表。快照会自动建表建索引预建的表如果结构不完全一致快照应用阶段会报对象已存在或列不匹配。如果因为某种原因必须预建表那就要保证结构、主键名、索引全部一致这是一条性价比很低的路径。提示事务复制初始化期间源库业务不能停。concurrent 快照生成完后Log Reader 会把快照生成期间产生的事务变更补送给订阅端所以订阅端数据完整一致的时间点要等增量追平不是快照应用完就立刻一致。3.4 确认同步状态从 sysprocesses 和分发历史表看复制配完之后第一件事是确认快照真的应用完、增量已经追平。在分发服务器上执行SELECT spid, program_name, status, last_batch FROM master.dbo.sysprocesses WHERE program_name LIKE %Replication%逻辑说明这条 SQL 能列出所有属于复制系统的后台进程。参数说明program_name 里带 Replication 字样的就是 Log Reader 或分发进程status 如果是 sleeping 或 runnable 都算正常last_batch 显示最后一批命令执行时间。如果 last_batch 停留在几小时前说明复制卡了不要犹豫马上进下一步查分发历史。再查分发数据库的历史记录SELECT TOP 20 [time], [comments], [error_id] FROM distribution.dbo.MSdistribution_history ORDER BY [time] DESC正常时 error_id 为 0comments 里能看到类似成功投递的记录。error_id 非 0 就要看具体错误码常见的是订阅过期或者网络超时。快照是否应用完成直接去订阅库看SELECT COUNT(*) FROM erp_report.dbo.orders如果表已经建出来、行数和源库逐步接近说明快照和增量追赶都正常。刚配完复制时订阅端有一点延迟是正常的Log Reader 需要把快照时间点到当前时刻的日志命令积压全部补上先等几分钟观察 last_batch 往前走不要一看到延迟就重启服务。复制这种老黑匣子最忌乱动动之前先看状态。4. 用链接服务器 DTS 做增量同步没有复制权限时的后备方案4.1 建立链接服务器SQLOLEDB 与 MSDASQL 的坑拿不到分发服务器权限、或者目标端是 2005 以上版本的异构场景链接服务器是常用后备。在源库执行exec sp_addlinkedserver server NSYNC_TARGET, srvproduct NSqlServer2000, provider NSQLOLEDB, datasrc N192.168.1.20 exec sp_addlinkedsrvlogin rmtsrvname NSYNC_TARGET, useself NFalse, rmtuser Nsa, rmtpassword NYourPwd逻辑说明第一段注册远程服务器第二段配置本地登录到远程服务器的账号映射。参数说明provider 必须写 SQLOLEDB这是 2000 自带的 OLEDB 提供程序。如果把 provider 留空2000 可能走系统默认的 MSDASQL也就是把 OLEDB 转成 ODBC性能和错误提示都会变得不可控。datasrc 填目标服务器的 IP 或机器名命名实例可以填 IP\实例名但要确保 SQL Browser 服务和 UDP 1434 端口是通的。建完连接先用最轻的查询验证连通性SELECT TOP 1 name FROM [SYNC_TARGET].erp.dbo.sysobjects能返回对象名链接服务器就通了。如果报“OLE DB 提供程序 SQLOLEDB 无法启动分布式事务”这是 MSDTC 没就绪。跨实例写操作依赖分布式事务协调器需要在控制面板的组件服务里把 Distributed Transaction Coordinator 设为自动启动并允许入站和出站网络事务。排查 MSDTC 是这条路线里最常见的体力活但确认一次后面就顺了。注意链接服务器能读不意味着能写。跨实例 UPDATE/INSERT 会强制启用分布式事务MSDTC 服务一旦停止要么同步任务失败要么数据写一半两边不一致。正式跑批之前先手动执行一条跨实例 INSERT 验证整个事务链。4.2 用时间戳列做增量同步UPDATE 后 INSERT 的两步脚本业务表有更新时间列时可以在存储过程或 DTS 的 SQL 任务里写增量同步脚本BEGIN TRAN UPDATE t SET t.status s.status, t.modtime s.modtime FROM [SYNC_TARGET].erp.dbo.orders t JOIN erp.dbo.orders s ON t.order_id s.order_id WHERE s.modtime last_sync_time INSERT INTO [SYNC_TARGET].erp.dbo.orders (order_id, status, modtime) SELECT s.order_id, s.status, s.modtime FROM erp.dbo.orders s WHERE s.modtime last_sync_time AND NOT EXISTS ( SELECT 1 FROM [SYNC_TARGET].erp.dbo.orders t WHERE t.order_id s.order_id ) COMMIT逻辑说明第一步把两边都有、但源库更新过的行刷到目标表第二步把源库有、目标表没有的行插进去。UPDATE 语句里 FROM...JOIN 的写法是 SQL Server 2000 支持的扩展语法配合链接服务器可以跨实例更新。参数说明last_sync_time 不是“当前时间减去多少分钟”而是上一次同步完成时刻。实际操作时我会建一张 sync_log 表记录每次同步的结束时间下次同步开始时把上次结束时间取出来作为 last_sync_time这样即使断点续跑也能增量补齐。目标表务必有主键或唯一索引否则 UPDATE 会变成全表定位远程表扫描会慢到你想砸键盘。同步频率不建议低于一分钟一次因为每次跑批都有事务日志开销15 分钟一次是兼顾延迟和开销的常用起点。4.3 把 DTS 包挂到 SQL Agent 作业上dtsrun 命令与调度参数如果同步逻辑已经在 DTS 包里用 dtsrun 命令行运行包再挂到 SQL Agent 作业上做定时调度。dtsrun 的标准命令如下dtsrun /S source01 /U sa /P YourPwd /N MySync /M逻辑说明/S 指定 DTS 包所在服务器/U 和 /P 是登录服务器的账号/N 指定包名/M 表示使用包的保护密码而不是命令行明文。参数说明如果包内部的任务使用链接服务器访问远端库那 dtsrun 触发的是同一个分布式事务链MSDTC 仍然是前提。创建 SQL Agent 作业调度这条命令exec msdb.dbo.sp_add_job job_name NSyncOrdersJob, enabled 1 exec msdb.dbo.sp_add_jobstep job_name NSyncOrdersJob, step_name NRunDts, subsystem NCmdExec, command Ndtsrun /S source01 /U sa /P YourPwd /N MySync /M exec msdb.dbo.sp_add_jobschedule job_name NSyncOrdersJob, name NEvery15Min, freq_type 4, freq_interval 1, freq_subday_type 4, freq_subday_interval 15逻辑说明先建作业再建命令行步骤最后配置每 15 分钟执行一次的调度计划。参数说明subsystemCmdExec 表示步骤调用操作系统命令而不是 T-SQLfreq_type4 表示每天类型的计划freq_interval1 表示每天都执行freq_subday_type4 表示按分钟间隔freq_subday_interval15 表示 15 分钟跑一次。这里最容易踩的坑是权限CmdExec 步骤运行时用的是 SQL Agent 服务账号这个账号必须对源库和链接服务器都有访问权限否则作业里报的错跟你手动跑 dtsrun 的报错完全不一样。4.4 没有更新时间列时的兜底触发器与整表比对不是每张表都有 modtime。没有增量字段时我一般在这两个方案里选一是给源表加一张增量日志表在源表上挂 UPDATE 和 INSERT 触发器把主键、操作时间、操作类型写进日志表。同步作业只读日志表再用主键回源表取当前值。代价是源表每次更新多一次触发器的写开销但这在 2000 上是可以接受的。触发器建议用 NOT FOR REPLICATION 选项避免在复制链路里再触发连锁动作。二是整表主键差集比对。数据量小时可以用链接服务器直接把两边主键拉出来做差SELECT s.order_id FROM erp.dbo.orders s LEFT JOIN [SYNC_TARGET].erp.dbo.orders t ON s.order_id t.order_id WHERE t.order_id IS NULL UNION ALL SELECT t.order_id FROM [SYNC_TARGET].erp.dbo.orders t LEFT JOIN erp.dbo.orders s ON s.order_id t.order_id WHERE s.order_id IS NULL逻辑说明第一段查源库有而目标库没有的 ID第二段查目标库有而源库没有的 ID两边合并就是全部需要补齐和需要删除的行。参数说明这个写法只在表不大的时候可用超过百万行就会把整表主键在网络上全传一遍。实际使用时我会加时间条件分页比如按 order_date 分段每次比较一个月的量。把整表比对当默认方案在老机器上会把性能拖到不可收拾。5. 老库同步的翻车现场五个排查点与血泪参数5.1 快照初始化期间发布库被锁死现象配置好发布订阅启动初始快照后业务系统在源库的写操作大面积阻塞页面超时并发高的表直接卡死。原因默认快照方式是用 bcp 生成数据bcp 在 SQL Server 2000 上默认给表加共享锁大表生成快照期间业务写事务进不来。业务表数据量越大锁表窗口越长。解决把发布属性里的同步方式改成并发快照也就是 sp_addpublication 的 sync_methodconcurrent。并发模式下快照进程不再长期持有表级锁快照期间产生的新变更由 Log Reader 进程补送到订阅端。这个模式的代价是初始化完成后订阅端要等增量补齐才能视为一致。如果业务表大到连并发快照都扛不住另一个可行路径是先从备份还原订阅库再把复制初始化方式设为“从备份”这是 2000 复制支持的一种初始化方式但要求两端 schema 完全一致。我个人的习惯还是错峰选业务低谷期生成快照同时把分发保留期先调大比硬上复杂配置更省心。5.2 订阅离线超过保留期分发进程罢工现象订阅服务器故障停机四天恢复后复制一直提示订阅已过期。日志读取正常但数据就是不往订阅端走手动启动订阅进程也被拒绝。原因分发库的 max_distretention 常见默认值是 72 小时。订阅端超过这个时间没有来拉取命令分发服务器就判定订阅失效历史命令直接标记为过期。解决已经过期的订阅不要试图把积压命令磨回来重新初始化订阅是唯一可靠的恢复路径。在复制监视器里对右侧订阅右键选择重新初始化订阅或者重建订阅并把 sync_type 设成 automatic。预防办法是配置分发库时把 max_distretention 调到 168一周给停机维护留够窗口。这个坑的教训是复制配好后分发保留期要在第一时间按业务允许的最大停机时长去设置默认值只适合从不出故障的理想环境。5.3 两边排序规则不一致导致同步中文乱码现象同步过去的中文全部显示成问号或者一条带中文等值条件的查询在源库正常在目标库查不到数据。原因源库和目标库的排序规则Collation不一致。源库是 Chinese_PRC_CI_AS目标库是 SQL_Latin1_General_CP1_CI_AS字符存储和比较方式完全不同中文自然乱套。解决统一目标库排序规则。新建库时显式指定CREATE DATABASE erp_report COLLATE Chinese_PRC_CI_AS逻辑说明这条命令在建库阶段把排序规则固定为简体中文、不区分大小写。参数说明Chinese_PRC_CI_AS 里的 CI 表示 case-insensitiveAS 表示 accent-sensitive这是中文环境最常见的组合。已经存在的库要确认规则可以用这条查询SELECT name, collation FROM master.dbo.sysdatabases结果里如果源和目标不一致最稳妥的做法是重建目标库并重新灌数据不要在列级别 COLLATE 上做修补那样会让索引失效后续性能问题更麻烦。已经有乱码数据的表清掉重灌比逐行修补快得多。5.4 DTS 批量更新把事务日志撑爆现象用 DTS 跑一张几百万行的表源库的 LDF 文件在十几分钟内暴涨最终磁盘塞满数据库进入可疑或只读状态。原因DTS 的数据转换任务默认把整个步骤包裹在一个大事务里或者包属性里勾选了“每个任务作为一个事务”。几百万行的批量写入持有一个超长事务日志文件无法截断只能一直膨胀。解决两条出路。一是改用 bcp 分批导入导出bcp 自带批大小参数bcp source01.erp.dbo.orders out orders.bcp -S source01 -U sa -P YourPwd -c -b 10000-b 10000 表示每批 10000 行提交一次导入时同样加 -b 参数。使用 -c 字符格式适合普通业务表如果有大字段或二进制类型就用 -n 原生格式但 -n 只适用于两端都是 SQL Server 的场景。中文环境要加 -C 936 指定代码页否则导入端又是一轮乱码。二是把 SQL 任务里的搬运脚本改成循环分页每次只处理一万行并在循环体内显式 checkpoint。DTS 包里有关事务提交的设置优先选“按批提交”不要选“一个任务一个事务”。5.5 复制进程空转状态 running 但数据不走现象复制监视器里订阅状态一直显示运行中但查订阅表行数半天不变Log Reader 进程的 CPU 占用却不低。原因大概率是分发命令积压。可能是订阅端有长时间阻塞锁分发进程发了命令但订阅端提交不了也可能是快照还在应用早期增量命令一直在排队。解决先看分发积压。用 Windows 性能监视器加“SQL Server: Replication Distribution”计数器看 Dist: Delivered Commands/sec 和 Undelivered Commands 两个值。Undelivered 一直涨而 Delivered 为 0问题在订阅端去订阅服务器执行 sp_who2 看阻塞链头通常能找到持有锁的会话。如果两边都正常但没有吞吐就在分发服务器上查 sysprocesses 找到对应的复制进程KILL 掉让它自动重启。需要强调的是KILL 前必须确认 program_name 里带 Replication 字样否则误杀掉业务连接就是新的事故。这条经验基本算复制运维里最常用的“后悔药”但别把它当成日常手段频繁 KILL 说明根因还没找到。6. 收尾前最后一道工序行数与主键差集校验顺带说 DataX 的边界6.1 用行数与主键差集做一致性校验同步链路调完我每次都会随手跑一遍一致性验证。最原始但有效的是行数和累计值校验SELECT source AS side, COUNT_BIG(*) AS rows_cnt, SUM(CAST(order_id AS bigint)) AS chk_sum FROM erp.dbo.orders UNION ALL SELECT target, COUNT_BIG(*), SUM(CAST(order_id AS bigint)) FROM erp_report.dbo.orders逻辑说明两个 side 分别统计源库和目标库的行数、ID 累加值。参数说明SUM(CAST(order_id AS bigint)) 是把 ID 转成 bigint 后累加能挡掉 99% 的漏行和重行问题。这个校验不是密码学级的但它能快速暴露行数不一致、主键漂移、重复数据这三大类故障。字段级比对我会抽几个数值型字段再各做一组 SUM敏感字段则抽比例比对不做全量网络传输因为 2000 老机器的网络带宽经不起全量字段逐行比对。6.2 增量同步的兜底习惯夜间定时校验差异表如果两套库主键差集有差异用第 4.4 节那段 LEFT JOIN 脚本把差异主键写进一张专用的 diff 表。我的习惯是给每个事务复制发布对加一个夜间作业运行这段差集逻辑第二天早上只需要查 diff 表有没有新记录就能判断一夜之间同步链路是否健康。这个方法让我从“两台 2000 到底一样不一样”的黑匣子状态里解脱出来也省去了每天手动跑校验的重复劳动。最后提醒一句 DataX 的边界如果这个 SQL Server 2000 库还要作为源端持续被新平台抽取DataX 这类数据库同步工具确实能做多个实例的增量同步但 2000 的驱动非常老JDBC/ODBC 的版本匹配、日期时间类型、numeric 精度都需要单独做一轮测试。生产账务数据我更信任原生事务复制的保底能力不拿数据库同步工具去赌增量准确性。希望这个老库同步方案的选型思路和排查经验帮到你。本文还有配套的精品资源点击获取
SQL Server 2000数据库同步实战：事务复制、DTS与日志传送选型排查指南
简介SQL Server 2000 数据库同步与复制配置讲解文档面向需要在多个 SQL Server 2000 实例间保持一致数据库结构的 DBA、运维与开发人员。文档围绕发布-订阅复制机制先梳理六项准备创建同名 Windows 用户、设置共享快照目录、调整 SQLSERVERAGENT 启动账户、启用 SQL Server 和 Windows 混合身份验证、互注册对方服务器、为纯 IP 环境配置服务器别名再说明配置分发服务器、创建事务发布或合并发布、添加订阅服务器的流程并标出快照权限、distributor_admin 密码、发布表需带主键等易错点。压缩包内为单个 PDF 文件约 114KB步骤清晰、可对照逐步实施。已有 855 人学习。1. 为什么 SQL Server 2000 数据库同步是一件绕不开的工作sqlserver 2000 数据库同步说白了就是把一台老库里的表持续搬进另一台 SQL Server 2000既要不丢数据又不能在搬运时把正在跑业务的源表锁死。这个场景在今天的生产环境里依然真实存在MES、计量、财务这类老系统被业务一直养着配套应用只认 SQL Server 2000可报表库、容灾库、测试库又都指着同一份数据这就是数据库同步问题的起点。它适合三类人接手维护老系统的新人给老库做容灾或迁移的 DBA以及需要在两个 2000 实例之间做读写分离的架构师。这里真正要解决的不是“换成新数据库”的规划问题而是把同步链路做成可靠、可验证、出了故障能在半小时内恢复的工程。2. SQL Server 2000 同步路线先按实时性、冲突、成本做完选型2.1 事务复制是原生方案里唯一接近实时的选项事务复制Transactional Replication是 SQL Server 2000 原生同步方案里能力最强的一种。它的工作模型是发布服务器上有一个 Log Reader 进程持续扫描事务日志把发布表中被标记为复制的变更解析成命令写入分发数据库Distribution订阅服务器再从分发服务器拉取这些命令在目标库上重放。整个过程对业务系统透明应用层完全感知不到同步存在。这种方案适合两种典型场景。一是生产库和报表库之间做近实时只读副本延迟通常在秒级到十几秒。二是作为灾备的数据层补充在日志传送尚不可用或不想恢复整个库时事务复制能保证主库的增量在目标端持续落库。实际部署里需要注意发布表必须有主键。主键不只是建索引用的后续 UPDATE 和 DELETE 都要靠它在订阅端定位行。没有主键的表在 2000 的发布向导里根本加不进去强行用 sp_addarticle 也会报错。还要明确一个边界事务复制默认是单向的主库写、订阅库只读。如果想双向同步得用合并复制Merge Replication但 2000 的合并复制在冲突检测和优先级配置上非常繁琐生产库一旦并发写冲突处理代价远超省下的那一台机器成本。我对事务复制的定位是默认第一选择只有当目标端版本差太多、或者连分发服务器权限都拿不到时才退到第 4 章的 DTS 路线。2.2 DTS 与链接服务器适合按批同步而不是实时事件DTSData Transformation Services是 SQL Server 2000 时代的官方数据搬运工具在 2005 里被 SSIS 取代。DTS 包可以定义数据源、目标、转换规则和任务流可以手动跑也能由 SQL Agent 作业定时触发。相比事务复制DTS 不解析事务日志它是一段时间内对源库做查询拉取对源库的压力是突发的适合离线批量同步。另一个配合组件是链接服务器Linked Server。它让一条 T-SQL 能直接跨实例访问对象典型写法是 SELECT * FROM [SYNC_TARGET].[erp].dbo.orders把远程表当本地表一样读。DTS 包里的“执行 SQL 任务”配合链接服务器写同步逻辑是老库之间最灵活的增量同步姿势。DTS 链接服务器的短板很明确没有自动断点、没有命令冲突检测、跨实例写操作还要依赖 MSDTC。网络一抖动批处理跑到一半失败下次再跑就可能重复 UPDATE 或漏掉一批数据。所以我会在目标表上建联合主键同步脚本里用“先 UPDATE 后 INSERT 目标表不存在才插入”的写法把幂等性先兜住。这套脚本放在第 4 章可以直接抄作业。2.3 日志传送整个库的一致副本不是表的同步日志传送Log Shipping在 SQL Server 2000 企业版里提供。原理是定期备份主库的事务日志文件传输到目标服务器目标服务器按顺序恢复RESTORE WITH NORECOVERY 或 STANDBY。它同步的粒度是“整个数据库”而不是某几张表目标实例最终得到的是一个完整、处于恢复状态的一致性副本。日志传送的实时性取决于日志备份间隔常见做法是五分钟到十五分钟做一次日志备份。目标库在 STANDBY 模式下可以只读查询但不能写。它适合需要完整库做报表、或者做容灾演练的团队但没法单独同步两张表——附带整个库意味着日志文件越来越多恢复链越拉越长中间任何一份日志文件损坏就得重启整条链。选型时经常有人纠结一个库里十张表业务上只关心其中两张表的变化却想配日志传送。这是典型的方案错配。表级同步用事务复制库级容灾用日志传送别混着用。如果连企业版都没有日志传送直接不用考虑。2.4 选型对照延迟、冲突、初始化、版本要求方案同步粒度延迟目标端可写初始化方式版本要求事务复制表级秒级到十几秒不可写单向快照或备份发布端需标准版DTS链接服务器自定义 SQL分钟级到小时级可以自行编写所有版本日志传送整个库分钟级只读全备日志链仅企业版备份还原整个库小时级可读可写全备差异所有版本补充一个经验市面上各种数据库同步软件/数据库同步工具看上去安装快、配置简单但对 SQL Server 2000 这种老实例驱动和兼容性往往比原生方案更折腾。同步工具大多按 2005 以后的机制设计对 2000 的 SQLOLEDB 连接方式、timestamp 列行为、隐式事务处理都可能水土不服。原生方案能跑通的我一般不动工具因为工具的坑比原生知识点更难在搜索引擎里找到答案。3. 用事务复制跑通两个 SQL Server 2000 库配置命令与参数3.1 同步前检查版本权限、网络连通、目标库准备配置发布之前先确认两端环境是健康的。在源库和目标库各执行一次SELECT VERSION AS ver, SERVERPROPERTY(Edition) AS edition, SERVERPROPERTY(IsClustered) AS is_cluster逻辑说明这条语句分别返回版本号、版本类型企业版/标准版、是否集群实例。SQL Server 2000 的标准版可以当发布服务器做事务复制但日志传送必须企业版这一步先确认版本能省掉后续不少弯路。参数说明SERVERPROPERTY(Edition) 返回的字符串要能区分标准版和企业版如果显示 Developer 或 Evaluation 也要意识到功能限制。网络连通性上SQL Server 2000 默认实例监听 1433 端口命名实例依赖 SQL Browser 服务。命令行验证方式就是 telnet 目标 IP 1433看能否连上端口。这一步容易被忽略但偏偏是复制作业最常翻车的点SQL Agent 服务没启动。Log Reader 进程和分发进程都由 SQL Agent 拉起SQL Agent 一停复制就卡在“未启动”状态数据完全不动。所以配置前我习惯先看一遍服务管理器里的 SQL Agent 状态。版本补丁方面源和目标如果都跑 SQL Server 2000尽量都装到 Service Pack 4。2000 早期版本的复制有大量和日志读取相关的 bug很多在 SP4 里才修掉裸奔版本配复制就是给自己挖坑。3.2 配置分发与发布sp_adddistributiondb 别用默认保留期分发服务器可以和发布服务器放在同一台机器上。在源库执行下面的命令exec sp_adddistributor distributor Nsource01, password N exec sp_adddistributiondb database Ndistribution, data_folder ND:\MSSQL\Data, log_folder ND:\MSSQL\Log, max_distretention 96, history_retention 48逻辑说明第一句把当前实例配置成分发服务器第二句创建分发数据库所有等待分发的复制命令都会先写进这里。参数说明里最值得关注的是 max_distretention它的单位是小时控制已分发命令在分发库里保留多久常见默认值是 72 小时。我改成 96 是给周末停机留一点余量——一旦订阅端离线超过这个窗口订阅就过期后面第 5 章会专门讲到这个坑。data_folder 和 log_folder 指向分发数据库的数据和日志目录要确认磁盘空间足够复制积压时这里涨得很快。然后创建发布exec sp_addpublication publication Npub_erp, repl_freq Ncontinuous, status Nactive, sync_method Nconcurrent, retention 0, immediate_sync Nfalse exec sp_addarticle publication Npub_erp, article Norders, source_object Norders, destination_object Norders, type Nlogbased逻辑说明sp_addpublication 定义发布属性sp_addarticle 把源库里的 orders 表加为发布项。参数说明repl_freq 用 continuous 表示持续从日志采集变更sync_method 用 concurrent 表示生成初始快照时尽量不长时间锁表这是 2000 里对在线业务最友好的方式typelogbased 明确这是一张事务复制类型的表。发布表必须有主键没有主键 sp_addarticle 会直接报错先在源表上补主键再回来加文章。3.3 创建订阅并初始化快照concurrent 模式避免锁表创建订阅最可靠的方式是在企业管理器里跑创建订阅向导向导最后一步可以选择生成 SQL 脚本。这里给一段最简化的命令行写法方便理解底层动作exec sp_addsubscription publication Npub_erp, subscriber Ndb02, destination_db Nerp_report, sync_type Nautomatic, subscription_type Npush exec sp_addpushsubscription_agent publication Npub_erp, subscriber Ndb02, subscriber_db Nerp_report, subscriber_login Nsa, subscriber_password NYourPwd, frequency_type 0x10逻辑说明sp_addsubscription 在订阅库注册订阅sp_addpushsubscription_agent 创建负责推送的调度进程。参数说明sync_typeautomatic 表示订阅创建后自动生成并应用初始快照subscription_typepush 表示推订阅分发服务器主动把数据推给订阅端frequency_type0x10 在 2000 里表示连续运行。我一般选推订阅而不是拉订阅因为分发进程跑在分发服务器上账号密码统一收口排查问题时只需要盯一台机器。订阅服务器上不要预建同名表。快照会自动建表建索引预建的表如果结构不完全一致快照应用阶段会报对象已存在或列不匹配。如果因为某种原因必须预建表那就要保证结构、主键名、索引全部一致这是一条性价比很低的路径。提示事务复制初始化期间源库业务不能停。concurrent 快照生成完后Log Reader 会把快照生成期间产生的事务变更补送给订阅端所以订阅端数据完整一致的时间点要等增量追平不是快照应用完就立刻一致。3.4 确认同步状态从 sysprocesses 和分发历史表看复制配完之后第一件事是确认快照真的应用完、增量已经追平。在分发服务器上执行SELECT spid, program_name, status, last_batch FROM master.dbo.sysprocesses WHERE program_name LIKE %Replication%逻辑说明这条 SQL 能列出所有属于复制系统的后台进程。参数说明program_name 里带 Replication 字样的就是 Log Reader 或分发进程status 如果是 sleeping 或 runnable 都算正常last_batch 显示最后一批命令执行时间。如果 last_batch 停留在几小时前说明复制卡了不要犹豫马上进下一步查分发历史。再查分发数据库的历史记录SELECT TOP 20 [time], [comments], [error_id] FROM distribution.dbo.MSdistribution_history ORDER BY [time] DESC正常时 error_id 为 0comments 里能看到类似成功投递的记录。error_id 非 0 就要看具体错误码常见的是订阅过期或者网络超时。快照是否应用完成直接去订阅库看SELECT COUNT(*) FROM erp_report.dbo.orders如果表已经建出来、行数和源库逐步接近说明快照和增量追赶都正常。刚配完复制时订阅端有一点延迟是正常的Log Reader 需要把快照时间点到当前时刻的日志命令积压全部补上先等几分钟观察 last_batch 往前走不要一看到延迟就重启服务。复制这种老黑匣子最忌乱动动之前先看状态。4. 用链接服务器 DTS 做增量同步没有复制权限时的后备方案4.1 建立链接服务器SQLOLEDB 与 MSDASQL 的坑拿不到分发服务器权限、或者目标端是 2005 以上版本的异构场景链接服务器是常用后备。在源库执行exec sp_addlinkedserver server NSYNC_TARGET, srvproduct NSqlServer2000, provider NSQLOLEDB, datasrc N192.168.1.20 exec sp_addlinkedsrvlogin rmtsrvname NSYNC_TARGET, useself NFalse, rmtuser Nsa, rmtpassword NYourPwd逻辑说明第一段注册远程服务器第二段配置本地登录到远程服务器的账号映射。参数说明provider 必须写 SQLOLEDB这是 2000 自带的 OLEDB 提供程序。如果把 provider 留空2000 可能走系统默认的 MSDASQL也就是把 OLEDB 转成 ODBC性能和错误提示都会变得不可控。datasrc 填目标服务器的 IP 或机器名命名实例可以填 IP\实例名但要确保 SQL Browser 服务和 UDP 1434 端口是通的。建完连接先用最轻的查询验证连通性SELECT TOP 1 name FROM [SYNC_TARGET].erp.dbo.sysobjects能返回对象名链接服务器就通了。如果报“OLE DB 提供程序 SQLOLEDB 无法启动分布式事务”这是 MSDTC 没就绪。跨实例写操作依赖分布式事务协调器需要在控制面板的组件服务里把 Distributed Transaction Coordinator 设为自动启动并允许入站和出站网络事务。排查 MSDTC 是这条路线里最常见的体力活但确认一次后面就顺了。注意链接服务器能读不意味着能写。跨实例 UPDATE/INSERT 会强制启用分布式事务MSDTC 服务一旦停止要么同步任务失败要么数据写一半两边不一致。正式跑批之前先手动执行一条跨实例 INSERT 验证整个事务链。4.2 用时间戳列做增量同步UPDATE 后 INSERT 的两步脚本业务表有更新时间列时可以在存储过程或 DTS 的 SQL 任务里写增量同步脚本BEGIN TRAN UPDATE t SET t.status s.status, t.modtime s.modtime FROM [SYNC_TARGET].erp.dbo.orders t JOIN erp.dbo.orders s ON t.order_id s.order_id WHERE s.modtime last_sync_time INSERT INTO [SYNC_TARGET].erp.dbo.orders (order_id, status, modtime) SELECT s.order_id, s.status, s.modtime FROM erp.dbo.orders s WHERE s.modtime last_sync_time AND NOT EXISTS ( SELECT 1 FROM [SYNC_TARGET].erp.dbo.orders t WHERE t.order_id s.order_id ) COMMIT逻辑说明第一步把两边都有、但源库更新过的行刷到目标表第二步把源库有、目标表没有的行插进去。UPDATE 语句里 FROM...JOIN 的写法是 SQL Server 2000 支持的扩展语法配合链接服务器可以跨实例更新。参数说明last_sync_time 不是“当前时间减去多少分钟”而是上一次同步完成时刻。实际操作时我会建一张 sync_log 表记录每次同步的结束时间下次同步开始时把上次结束时间取出来作为 last_sync_time这样即使断点续跑也能增量补齐。目标表务必有主键或唯一索引否则 UPDATE 会变成全表定位远程表扫描会慢到你想砸键盘。同步频率不建议低于一分钟一次因为每次跑批都有事务日志开销15 分钟一次是兼顾延迟和开销的常用起点。4.3 把 DTS 包挂到 SQL Agent 作业上dtsrun 命令与调度参数如果同步逻辑已经在 DTS 包里用 dtsrun 命令行运行包再挂到 SQL Agent 作业上做定时调度。dtsrun 的标准命令如下dtsrun /S source01 /U sa /P YourPwd /N MySync /M逻辑说明/S 指定 DTS 包所在服务器/U 和 /P 是登录服务器的账号/N 指定包名/M 表示使用包的保护密码而不是命令行明文。参数说明如果包内部的任务使用链接服务器访问远端库那 dtsrun 触发的是同一个分布式事务链MSDTC 仍然是前提。创建 SQL Agent 作业调度这条命令exec msdb.dbo.sp_add_job job_name NSyncOrdersJob, enabled 1 exec msdb.dbo.sp_add_jobstep job_name NSyncOrdersJob, step_name NRunDts, subsystem NCmdExec, command Ndtsrun /S source01 /U sa /P YourPwd /N MySync /M exec msdb.dbo.sp_add_jobschedule job_name NSyncOrdersJob, name NEvery15Min, freq_type 4, freq_interval 1, freq_subday_type 4, freq_subday_interval 15逻辑说明先建作业再建命令行步骤最后配置每 15 分钟执行一次的调度计划。参数说明subsystemCmdExec 表示步骤调用操作系统命令而不是 T-SQLfreq_type4 表示每天类型的计划freq_interval1 表示每天都执行freq_subday_type4 表示按分钟间隔freq_subday_interval15 表示 15 分钟跑一次。这里最容易踩的坑是权限CmdExec 步骤运行时用的是 SQL Agent 服务账号这个账号必须对源库和链接服务器都有访问权限否则作业里报的错跟你手动跑 dtsrun 的报错完全不一样。4.4 没有更新时间列时的兜底触发器与整表比对不是每张表都有 modtime。没有增量字段时我一般在这两个方案里选一是给源表加一张增量日志表在源表上挂 UPDATE 和 INSERT 触发器把主键、操作时间、操作类型写进日志表。同步作业只读日志表再用主键回源表取当前值。代价是源表每次更新多一次触发器的写开销但这在 2000 上是可以接受的。触发器建议用 NOT FOR REPLICATION 选项避免在复制链路里再触发连锁动作。二是整表主键差集比对。数据量小时可以用链接服务器直接把两边主键拉出来做差SELECT s.order_id FROM erp.dbo.orders s LEFT JOIN [SYNC_TARGET].erp.dbo.orders t ON s.order_id t.order_id WHERE t.order_id IS NULL UNION ALL SELECT t.order_id FROM [SYNC_TARGET].erp.dbo.orders t LEFT JOIN erp.dbo.orders s ON s.order_id t.order_id WHERE s.order_id IS NULL逻辑说明第一段查源库有而目标库没有的 ID第二段查目标库有而源库没有的 ID两边合并就是全部需要补齐和需要删除的行。参数说明这个写法只在表不大的时候可用超过百万行就会把整表主键在网络上全传一遍。实际使用时我会加时间条件分页比如按 order_date 分段每次比较一个月的量。把整表比对当默认方案在老机器上会把性能拖到不可收拾。5. 老库同步的翻车现场五个排查点与血泪参数5.1 快照初始化期间发布库被锁死现象配置好发布订阅启动初始快照后业务系统在源库的写操作大面积阻塞页面超时并发高的表直接卡死。原因默认快照方式是用 bcp 生成数据bcp 在 SQL Server 2000 上默认给表加共享锁大表生成快照期间业务写事务进不来。业务表数据量越大锁表窗口越长。解决把发布属性里的同步方式改成并发快照也就是 sp_addpublication 的 sync_methodconcurrent。并发模式下快照进程不再长期持有表级锁快照期间产生的新变更由 Log Reader 进程补送到订阅端。这个模式的代价是初始化完成后订阅端要等增量补齐才能视为一致。如果业务表大到连并发快照都扛不住另一个可行路径是先从备份还原订阅库再把复制初始化方式设为“从备份”这是 2000 复制支持的一种初始化方式但要求两端 schema 完全一致。我个人的习惯还是错峰选业务低谷期生成快照同时把分发保留期先调大比硬上复杂配置更省心。5.2 订阅离线超过保留期分发进程罢工现象订阅服务器故障停机四天恢复后复制一直提示订阅已过期。日志读取正常但数据就是不往订阅端走手动启动订阅进程也被拒绝。原因分发库的 max_distretention 常见默认值是 72 小时。订阅端超过这个时间没有来拉取命令分发服务器就判定订阅失效历史命令直接标记为过期。解决已经过期的订阅不要试图把积压命令磨回来重新初始化订阅是唯一可靠的恢复路径。在复制监视器里对右侧订阅右键选择重新初始化订阅或者重建订阅并把 sync_type 设成 automatic。预防办法是配置分发库时把 max_distretention 调到 168一周给停机维护留够窗口。这个坑的教训是复制配好后分发保留期要在第一时间按业务允许的最大停机时长去设置默认值只适合从不出故障的理想环境。5.3 两边排序规则不一致导致同步中文乱码现象同步过去的中文全部显示成问号或者一条带中文等值条件的查询在源库正常在目标库查不到数据。原因源库和目标库的排序规则Collation不一致。源库是 Chinese_PRC_CI_AS目标库是 SQL_Latin1_General_CP1_CI_AS字符存储和比较方式完全不同中文自然乱套。解决统一目标库排序规则。新建库时显式指定CREATE DATABASE erp_report COLLATE Chinese_PRC_CI_AS逻辑说明这条命令在建库阶段把排序规则固定为简体中文、不区分大小写。参数说明Chinese_PRC_CI_AS 里的 CI 表示 case-insensitiveAS 表示 accent-sensitive这是中文环境最常见的组合。已经存在的库要确认规则可以用这条查询SELECT name, collation FROM master.dbo.sysdatabases结果里如果源和目标不一致最稳妥的做法是重建目标库并重新灌数据不要在列级别 COLLATE 上做修补那样会让索引失效后续性能问题更麻烦。已经有乱码数据的表清掉重灌比逐行修补快得多。5.4 DTS 批量更新把事务日志撑爆现象用 DTS 跑一张几百万行的表源库的 LDF 文件在十几分钟内暴涨最终磁盘塞满数据库进入可疑或只读状态。原因DTS 的数据转换任务默认把整个步骤包裹在一个大事务里或者包属性里勾选了“每个任务作为一个事务”。几百万行的批量写入持有一个超长事务日志文件无法截断只能一直膨胀。解决两条出路。一是改用 bcp 分批导入导出bcp 自带批大小参数bcp source01.erp.dbo.orders out orders.bcp -S source01 -U sa -P YourPwd -c -b 10000-b 10000 表示每批 10000 行提交一次导入时同样加 -b 参数。使用 -c 字符格式适合普通业务表如果有大字段或二进制类型就用 -n 原生格式但 -n 只适用于两端都是 SQL Server 的场景。中文环境要加 -C 936 指定代码页否则导入端又是一轮乱码。二是把 SQL 任务里的搬运脚本改成循环分页每次只处理一万行并在循环体内显式 checkpoint。DTS 包里有关事务提交的设置优先选“按批提交”不要选“一个任务一个事务”。5.5 复制进程空转状态 running 但数据不走现象复制监视器里订阅状态一直显示运行中但查订阅表行数半天不变Log Reader 进程的 CPU 占用却不低。原因大概率是分发命令积压。可能是订阅端有长时间阻塞锁分发进程发了命令但订阅端提交不了也可能是快照还在应用早期增量命令一直在排队。解决先看分发积压。用 Windows 性能监视器加“SQL Server: Replication Distribution”计数器看 Dist: Delivered Commands/sec 和 Undelivered Commands 两个值。Undelivered 一直涨而 Delivered 为 0问题在订阅端去订阅服务器执行 sp_who2 看阻塞链头通常能找到持有锁的会话。如果两边都正常但没有吞吐就在分发服务器上查 sysprocesses 找到对应的复制进程KILL 掉让它自动重启。需要强调的是KILL 前必须确认 program_name 里带 Replication 字样否则误杀掉业务连接就是新的事故。这条经验基本算复制运维里最常用的“后悔药”但别把它当成日常手段频繁 KILL 说明根因还没找到。6. 收尾前最后一道工序行数与主键差集校验顺带说 DataX 的边界6.1 用行数与主键差集做一致性校验同步链路调完我每次都会随手跑一遍一致性验证。最原始但有效的是行数和累计值校验SELECT source AS side, COUNT_BIG(*) AS rows_cnt, SUM(CAST(order_id AS bigint)) AS chk_sum FROM erp.dbo.orders UNION ALL SELECT target, COUNT_BIG(*), SUM(CAST(order_id AS bigint)) FROM erp_report.dbo.orders逻辑说明两个 side 分别统计源库和目标库的行数、ID 累加值。参数说明SUM(CAST(order_id AS bigint)) 是把 ID 转成 bigint 后累加能挡掉 99% 的漏行和重行问题。这个校验不是密码学级的但它能快速暴露行数不一致、主键漂移、重复数据这三大类故障。字段级比对我会抽几个数值型字段再各做一组 SUM敏感字段则抽比例比对不做全量网络传输因为 2000 老机器的网络带宽经不起全量字段逐行比对。6.2 增量同步的兜底习惯夜间定时校验差异表如果两套库主键差集有差异用第 4.4 节那段 LEFT JOIN 脚本把差异主键写进一张专用的 diff 表。我的习惯是给每个事务复制发布对加一个夜间作业运行这段差集逻辑第二天早上只需要查 diff 表有没有新记录就能判断一夜之间同步链路是否健康。这个方法让我从“两台 2000 到底一样不一样”的黑匣子状态里解脱出来也省去了每天手动跑校验的重复劳动。最后提醒一句 DataX 的边界如果这个 SQL Server 2000 库还要作为源端持续被新平台抽取DataX 这类数据库同步工具确实能做多个实例的增量同步但 2000 的驱动非常老JDBC/ODBC 的版本匹配、日期时间类型、numeric 精度都需要单独做一轮测试。生产账务数据我更信任原生事务复制的保底能力不拿数据库同步工具去赌增量准确性。希望这个老库同步方案的选型思路和排查经验帮到你。本文还有配套的精品资源点击获取
