MS 同步框架 "Enumerating Inserts for Table xxxx" 突然变得非常慢
MS Sync framework "Enumerating Inserts for Table xxxx" is suddenly extremely slow
编辑了新信息。
我继承了一个项目，该项目利用 MS Sync Framework 2.1 将 SQL Server CE 3.5 DB 与 SQL Server 2008 R2 同步。大约有 100 万行分布在十几个 table 中。其中两个 table 占总行数的 ~75%。每天只有几十行发生变化，并且在这种轮辐式安排中只有不到 10 个用户/安装。 Sync 每天要做的工作很少。
此项目的先前版本可以在 1-2 分钟内完成 "do-nothing" 同步（在两端插入、更新或删除零行）。由于我重新生成了 .sdf（包括所有数据），现在最少需要 9 分钟，对于某些用户来说要长得多。
通过启用详细同步日志记录，并将新日志文件与旧日志文件进行比较，我将问题缩小到一种操作类型。所有额外时间都计入记录为 "Enumerating Inserts for Table xxxxx" 的步骤（客户端插入等待转到服务器）。较大的 tables 比较小的 tables 花费的时间更长，但所有这些都按比例增加，并且对于这个操作来说是显着的，即使结果是零行。
编辑： 出现在同步日志中的似乎不受支持的查询语法（对于 SQL Server CE），显然仅在与服务器资源管理器结合使用时无效查询 window。它在 VS T-SQL 编辑器中运行良好。我现在已经比较了两个 actual 查询计划。他们是一样的。从某种意义上说，大 table 被扫描也就不足为奇了。但是，在 T-SQL 编辑器中，它在任一数据库上花费的时间相同（~35 秒）。显然，在该操作期间，同步引擎中发生了更多事情；即使结果在所有情况下都是零行。
当我继承这个项目时，它已经进行了大约一半的小升级，但我没有看到任何在源代码控制历史中脱颖而出的东西。没有文档可以准确描述之前的开发工作站设置。我已将所有 table、列和索引与旧的 .sdf 进行了比较。新的 .sdf 和旧的 .sdf 大小相同。我所知道的没有更新的库。我完全被难住了。
我忽略了什么？
尽管在枚举要上传的本地更改时，我从未了解为什么新文件的执行速度比旧文件慢，但我想出了如何让它在这种情况下按应有的方式执行（非常快）。
如前所述，框架在生成缓存时不会创建任何索引。一些（实际上很多）实验表明创建这个索引（在每个 table 上）似乎是最佳的：
create index idx_ChangeTracking on yourTable (__sysChangeTxBsn, __sysTrackingContext, __sysInsertTxBsn);
枚举本地更改现在几乎是即时的，因为它本来应该一直如此。为什么在生成 table 时框架没有创建这个索引，为什么以前（没有）那么重要？我想我们永远不会知道。
编辑了新信息。
我继承了一个项目，该项目利用 MS Sync Framework 2.1 将 SQL Server CE 3.5 DB 与 SQL Server 2008 R2 同步。大约有 100 万行分布在十几个 table 中。其中两个 table 占总行数的 ~75%。每天只有几十行发生变化，并且在这种轮辐式安排中只有不到 10 个用户/安装。 Sync 每天要做的工作很少。
此项目的先前版本可以在 1-2 分钟内完成 "do-nothing" 同步（在两端插入、更新或删除零行）。由于我重新生成了 .sdf（包括所有数据），现在最少需要 9 分钟，对于某些用户来说要长得多。
通过启用详细同步日志记录，并将新日志文件与旧日志文件进行比较，我将问题缩小到一种操作类型。所有额外时间都计入记录为 "Enumerating Inserts for Table xxxxx" 的步骤（客户端插入等待转到服务器）。较大的 tables 比较小的 tables 花费的时间更长，但所有这些都按比例增加，并且对于这个操作来说是显着的，即使结果是零行。
编辑： 出现在同步日志中的似乎不受支持的查询语法（对于 SQL Server CE），显然仅在与服务器资源管理器结合使用时无效查询 window。它在 VS T-SQL 编辑器中运行良好。我现在已经比较了两个 actual 查询计划。他们是一样的。从某种意义上说，大 table 被扫描也就不足为奇了。但是，在 T-SQL 编辑器中，它在任一数据库上花费的时间相同（~35 秒）。显然，在该操作期间，同步引擎中发生了更多事情；即使结果在所有情况下都是零行。
当我继承这个项目时，它已经进行了大约一半的小升级，但我没有看到任何在源代码控制历史中脱颖而出的东西。没有文档可以准确描述之前的开发工作站设置。我已将所有 table、列和索引与旧的 .sdf 进行了比较。新的 .sdf 和旧的 .sdf 大小相同。我所知道的没有更新的库。我完全被难住了。
我忽略了什么？
尽管在枚举要上传的本地更改时，我从未了解为什么新文件的执行速度比旧文件慢，但我想出了如何让它在这种情况下按应有的方式执行（非常快）。
如前所述，框架在生成缓存时不会创建任何索引。一些（实际上很多）实验表明创建这个索引（在每个 table 上）似乎是最佳的：
create index idx_ChangeTracking on yourTable (__sysChangeTxBsn, __sysTrackingContext, __sysInsertTxBsn);
枚举本地更改现在几乎是即时的，因为它本来应该一直如此。为什么在生成 table 时框架没有创建这个索引，为什么以前（没有）那么重要？我想我们永远不会知道。