摘要：背景：最近一段时间，有一个发布订阅在晚上总是报延时，由于晚上在copy备份占用带宽，而且晚上没有人使用订阅上的数据，所以也一直没有去看，最近有时间，上去看了下，发现诸多问题，服务器是12GB内存16CPU.排查步骤及解决办法：1.查看到当前大量的PAGEIOLATCH_SH等待信息，执行的是分发的读程进命令SQL-sp_MSget_repl_commands，怀疑IO/内存有压力，理论上分发库不大，应该可以全部缓存在内存中：2.于是查看分发库大小，发现有22GB，再查看表msrepl_commands数据量，居然有4000W，16GB大小：3.需要再排查一下是发布到分发和分发到订阅是哪个出现了 阅读全文

摘要：考虑这样的场景，现在每天要同步更新的数据，为了记录哪些数据发生过变更，需要对表添加一个rowversion列来标识被更新过。恰好这个表比较大，而且有发布订阅。由于该字段对于订阅表来讲，无实际意义，而且添加一个有默认值的不可为空的8字节字段，会产生数据空间分配，或许带来大量的页拆分，对IO压力会加大，所以考虑将此表的发布项暂时改为不支持架构复制，等添加完该字段后，再将其改为支持架构复制。下面来做这个测试：1.下面是一个正常的事务发布，将DB_1中的T_1发布到DB_2的T_1表中。2.修改发布项DBrepTEST关于架构复制的选项，设置为不支持DECLARE @publication AS sy 阅读全文