SQL Server 2012大数据表合并复制故障及多复制配置咨询

首先给你明确答案：完全可以在同一数据库中配置多个合并复制发布。你可以为原有的35张表单独创建一个发布，新增的大表则创建另一个独立发布，各自对应专属的订阅。不过要注意几个关键细节：

• 绝对不要让同一张表被多个发布重复包含，否则会触发复制逻辑冲突，导致同步异常
• 每个发布都会对应独立的代理作业（快照代理、合并代理），要根据服务器CPU、内存资源情况，合理调整并发运行的代理数量，避免资源耗尽
• 可以给不同发布设置差异化的调度周期，比如大表的复制任务可以避开业务高峰时段执行，减少对在线业务的影响

接下来针对你提到的100万条级大表导致复制中断的问题，分享几个经过生产环境验证的优化方案：

一、优化快照初始化环节 #

• 预生成快照文件：对于大表，不要依赖快照代理实时生成海量数据快照。可以提前手动生成快照文件并拷贝到订阅服务器，或者在创建发布时通过sp_addmergepublication指定@pre_snapshot_script，提前完成基础数据准备，大幅缩短初始化时间
• 使用分区快照：如果大表可以按业务维度（比如地区、时间范围）做水平筛选，为每个分区创建独立快照，订阅端仅同步自身需要的数据分区，能直接把快照大小和传输量降到几分之一
• 关闭LOB字段压缩：如果表包含VARCHAR(MAX)、VARBINARY(MAX)这类大对象字段，默认的压缩处理可能反而拖慢传输速度，可在发布属性中关闭大对象压缩选项

二、调整复制代理参数 #

• 增大批处理大小：修改合并代理的-BatchSize参数（默认值1000），比如调整到10000或更高，减少网络交互次数，提升大批次数据的同步效率
• 延长超时时间：大表同步需要更长的执行窗口，把合并代理的-LoginTimeout和-QueryTimeout参数适当调大，避免因超时而触发中断
• 限制并发线程数：如果服务器资源有限，设置合并代理的-MaxConcurrentThreads参数，防止代理占用过多CPU、内存，影响业务系统的正常运行

三、减少同步数据量 #

• 行级筛选：如果业务允许，对大表使用参数化行筛选（比如按订阅服务器所属地区、业务单元ID筛选），只同步订阅端实际需要的数据，从根源上降低同步压力
• 裁剪冗余列：只复制业务必需的字段，去掉不需要的冗余列，减少单条记录的数据体积
• 启用增量快照：在发布属性中开启增量快照功能，当表结构变更或新增数据时，仅生成增量部分的快照，而非全量快照，大幅减少快照生成和传输的开销

四、定期维护与监控 #

• 清理复制元数据：定期运行sp_mergemetadataretentioncleanup存储过程，清理过期的复制元数据，避免MSmerge_genhistory这类系统表过度膨胀，影响复制性能
• 实时监控代理状态：通过SQL Server代理的作业历史记录、复制监视器，实时查看同步进度和错误日志，一旦发现中断前兆（比如同步速度骤降）及时介入处理
• 重建大表索引：大表在同步过程中容易产生大量索引碎片，定期重建或重组索引，能提升复制时的查询、写入效率

五、优化冲突处理逻辑 #

• 预设冲突解决规则：提前为大表定义冲突解决优先级（比如按服务器权重、最后修改时间），避免因冲突无法自动解决导致同步中断
• 业务层面减少冲突：尽量让不同订阅端操作不同的数据分区，从业务流程上降低冲突发生的概率

内容的提问来源于stack exchange，提问作者prashant