我有一个运行良好的合并复制一年（系统已经活动了几年，但由于其他一些问题，我在一年前重新创建了复制）。
一切仍在工作，但是当有人（重新）初始化订阅（下载新的订阅数据库）时，需要更长的时间并且会出现一些锁。订阅者是带有 sql server compact 的 ca 300 windows ce 设备。
我可以看到，一个名为的存储过程MSenumgenerations90是罪魁祸首，它占用了大量的 IO 和 CPU。我在 CXPACKET 活动监视器中看到的最常见的等待，我知道这是并行性。我可以看到一些 pageiolatch，至少其中一些指向 tempdb。表 msMerge_GenHistory 包含多于 150 万条记录，我尝试向其添加索引以使存储过程中昂贵的操作运行得更快但没有成功。
我的保留期很长。它设置为 60 天，但我仍然可以看到，MSMerge_GenHistory当我一年前重新创建复制时，其中创建了几代（coldate）但是似乎有一些代被删除，因为最新一代的代号高于 2,2百万。元数据清理可能有问题还是这是正常行为？当 CXPACKET 等待显示时，我的缓冲区 I/O 等待时间为 2000 ms/s，并且还有很多 IO_COMPLETION 等待，当我在服务器上监视磁盘时，我可以看到 tempdb-file 的读取次数最多，并且写道。我读过的一件事是你可以为 tempdb 设置多个文件，它可以减轻 tempdb 的压力，这对我的情况有帮助吗？
运行合并复制时向 tempdb 添加更多文件是否安全？
更新。我运行了存储过程来获取实际的执行计划，并且有一个排序警告说排序溢出到 tempdb。我猜这就是我的问题的原因，sp 并行运行并且它溢出到 tempdb 并且 8 个连续线程正在访问 tempdb 以尝试对结果进行排序，这就是为什么 IO 中的等待很高以及为什么 CXPACKET 是显示！？ 我有点担心我 怎样才能让它停止溢出到 tempdb？可以通过更好地索引来完成吗？我无法修改 sp，因为它是复制的一部分。欢迎任何帮助。
