优化和监视性能
我们建议您采用以下方法提高同步性能：
配置每个服务器和数据库以及应用程序代码以获得最佳性能
确定性能基准
进行监视和优化，以满足或超过基准值
配置
性能优化的第一步是确保正确配置硬件和软件。
服务器和网络注意事项
确保每台计算机有适当的 IO 子系统，并且正确分配数据库文件。
从磁盘读取变更和将变更写入磁盘的速度一般比网络速度更重要，因此适当的 IO 子系统是优化性能的基本条件。建议使用多个 RAID 磁盘阵列，在服务器上对于 tempdb、用户数据库和事务日志分别使用一个专用阵列。应在单独的文件组中创建 tempdb、用户数据库和事务日志。如果一个或多个用户表被证实是处理瓶颈，请考虑将它们移到单独的文件组。
考虑增加同步拓扑中的计算机的内存。
对于大量并发同步会话中涉及的那些服务器，这一点特别重要。同步会话一般涉及长期运行的事务；因此提供可由服务器数据库直接寻址的足够内存很重要。在 SQL Server 中，考虑对 32 位系统使用 /3GB 开关或移到 64 位系统。有关更多信息，请参见 SQL Server 联机丛书中的“进程地址空间”。
设置分配给服务器数据库的最小和最大内存量。
例如，默认情况下，数据库引擎根据可用的系统资源动态改变它的内存要求。为避免在同步活动期间出现可用内存过低的问题，请使用 min server memory 选项设置最小可用内存。为避免将操作系统页写入磁盘以节省内存，也可以使用 max server memory 选项设置最大内存量。有关更多信息，请参见 SQL Server 联机丛书。
数据库和应用程序设计
遵循数据库设计最佳实践。
同步涉及的数据库通常能够从性能优化中获得与任何类似数据库一样的好处。有关优化数据库的更多信息，请参见 SQL Server 联机丛书。请了解索引的以下注意事项：
应使用同步活动测试基表上的索引，因为索引可以影响选择、插入、更新和删除性能。
元数据表应被正确索引。Sync Framework 向它创建的任何表添加索引。如果为 DbSyncProvider 创建了元数据表，请参见如何为协作同步设置服务器数据库（非 SQL Server）；如果为 DbServerSyncProvider 创建了元数据表，则请参见如何使用自定义变更跟踪系统。
为数据库锁超时和查询超时设置合适的值。
通过发布设计和应用程序行为最大限度地减少冲突。
在设计应用程序时便应避免产生冲突（如果能够做到这一点），因为冲突的检测和解决会增加应用程序的复杂性，增加处理负担和网络流量。避免冲突最常用的方法如下所示：
只在一个节点上更新一个表或
筛选数据，以便只有一个节点更新特定的行集。例如，在客户端-服务器方案中，您可以横向在各个客户端之间划分数据，以便每个客户端只变更数据的一个“片段”，如华盛顿客户的联系信息。
合理使用筛选功能。
筛选数据是一种减少冲突的好方法，只需要将更少的数据复制到每个节点。不过，要注意复杂的筛选子句会影响性能。如果筛选器联接很多表，请考虑使用其他方法来实现相同的逻辑。
在触发器和同步查询中慎用应用程序逻辑。
在每个查询和触发器中执行附加逻辑会显著降低性能。
使用存储过程执行数据库命令。
在同步会话期间，Sync Framework 使用几个查询来选择和应用数据和元数据变更。如果手动创建这些查询，请将它们封装在存储过程中。这通常会提供更好的性能和可维护性，还可以帮助保护应用程序。如果您的应用程序需要内联 SQL 而不是存储过程，请确保对所有命令使用 ADO.NET Prepare() 方法。这将提高内联 SQL 的性能。
只在每个节点同步所需的数据。
人们总是倾向于发布数据库中的所有表或大部分表，以防万一。请避免发布应用程序并不真正需要的表，考虑降低同步每个节点的频率。
合理设计同步组和作用域，并为每个作用域使用合适的同步方向。
作用域是作为一个单元同步的一组表。可以筛选作用域中的一个或多个表，并且表可以包含在多个作用域中。请确保作用域反映它们所包含的表的结构和使用模式。请考虑销售人员应用程序中的以下四个表：
Orders 和 OrderDetails
只在一台客户端计算机上将行插入这些表，但是在服务器上可能会更新。必须在同一事务中提交变更。这些表应在相同的作用域中，同步方向为双向。
Pricing
经常插入和更新行，但只在服务器上进行。此表和与之类似的表应在一个作用域中，从客户端的角度看同步方向为仅下载。
Products
在服务器上偶尔插入和更新行。此表所在的作用域应与 Pricing 所在的作用域不同，因为它更新的频率不同于后者，同步的频率较低。
备注
每个会话的同步方向可以改变，而作用域对于所有会话保持不变。作用域和同步方向之间没有直接关系，但是本示例说明在设计应用程序时如何兼顾这二者。
对于 DbSyncProvider，使用 SelectTableMaxTimestampsCommand 来优化枚举。
为此属性指定的查询选择每个基表或跟踪表中的最大时间戳。使用此时间戳确定对于每个表目标是否已具有来自源的所有变更。如果目标已具有这些变更，Sync Framework 通常可以避免运行枚举查询，这样可以提高性能。
通过分批处理解决网络不可靠和内存不足的问题。
默认情况下，Sync Framework 在单个 DataSet 对象中将变更传送给每个节点。变更被应用到节点时，将此对象保留在内存中。如果应用变更的计算机上有足够的内存并且与该计算机的连接可靠，则默认行为很适用。但是，将变更划分为批次可能对某些应用程序更有利。分批处理不会带来额外的开销，但实际上可以提高某些应用程序的性能。有关更多信息，请参见如何分批传递变更 (SQL Server)。
交错执行同步计划。
如果大量节点需要与某中心节点同步，请考虑将计划交错开，以便减小中心节点的内存压力和争用。可以基于时钟时间或相对时间排定计划。例如，应用程序可以每小时同步一次，或在该节点上次成功完成同步会话后 1 小时启动新的同步会话。
使用合理的元数据清除计划。
大量的元数据会影响同步查询的性能。
基准
配置同步后，我们建议制定一个性能基准，以便于确定同步在通常用于应用程序和拓扑的常见工作负荷中的行为方式。使用同步事件和系统监视器确定同步性能的以下五个维度的典型数目：
滞后时间：在拓扑中的节点之间传播数据变更所用的时间。
吞吐量：一段时间内系统可以持续的同步活动量（以一段时间内传递的行数来度量）。
并发度：可以同时与特定节点同步的节点数。这通常是可以与特定服务器同步的客户端数。
同步持续时间：完成给定同步会话所用的时间。
资源占用：进行同步处理所需的硬件和网络资源。
根据您的应用程序，这些性能度量值中的某些值可能会比其他值更重要。例如，为了获得较高的并发度，可以适当降低一下吞吐量。在建立性能基准时，请注意我们不将 Sync Framework 设计为像 SQL Server 事务性复制一样具有较短滞后时间和较高吞吐量的服务器到服务器系统。它设计用于支持脱机和协作应用程序的客户端到服务器和客户端到客户端的同步。
您确定基准数据后，请监视系统，查找性能和可伸缩性瓶颈并在必要时进行优化。
监视和维护
可以在制定性能基准期间进行监视，以后在生产环境中定期监视，如果出现性能问题则进行更密集的监视。我们建议使用以下工具来监视同步活动和性能：
同步事件
使用以下事件来确定特定阶段占用的时间：
每个提供程序上的每个表事件：SelectingChanges、ChangesSelected、ApplyingChanges 和 ChangesApplied
每个提供程序上的每个会话事件：SyncProgress
将每个阶段占用的时间保存在内存中，然后在同步会话结束后将结果写入日志文件或性能数据库。
SQL Server 事件探查器
使用 TSQL_SPs 模板，标识运行时间长于特定阈值（如 10 秒）的所有查询。如果要将跟踪信息写入日志文件或性能数据库，请将该数据保存在内存中并在同步会话结束后执行写操作。
SQL Server Management Studio
可以使用 Management Studio 检查每个同步查询的查询计划，确保使用最佳计划。
系统监视器
使用以下性能对象和计数器来监视影响同步的重要因素：
SQL Server 下的计数器：Memory Manager。例如，可以通过比较 Target Server Memory 和 Total Server Memory 来验证 SQL Server 是否有足够的内存。
PhysicalDisk 下的计数器。例如，Avg. Disk Read Queue Length 和 Avg. Disk Write Queue Length 可以帮助判断同步性能受 IO 限制还是计算机内存不足。如果队列长度不合理，请考虑增加内存和升级或添加驱动器。
默认值为对于该计数器报告所有驱动器的平均值。确保为每个驱动器添加计数器。
SQL Server 下的计数器：Transactions。例如，可以使用 Snapshot Transactions 和 Version Store Size 来确定变更枚举查询是否导致 tempdb 急剧增加。变更枚举查询使用快照事务，并且在 tempdb 中存储快照版本信息。较大的版本存储区意味着该 tempdb 可能需要调整大小。
SQL Server 下的计数器：Locks。例如，可以使用 Lock Wait Time 和 Number of Deadlocks 来确定在数据库的并发活动期间争用是否成问题。
同步跟踪
Sync Framework 包括基于 TraceListener 类的跟踪。跟踪可用于收集有关同步会话的信息，这些信息有助于进行监视和故障排除。但是，请注意跟踪会带来额外的开销，应主要在开发过程中使用它。有关更多信息，请参见如何跟踪同步过程（本主题主要针对 DbServerSyncProvider，但是其信息也适用于其他提供程序）。
除了监视，我们建议您定期执行以下维护任务：
根据碎片的情况，重新组织或重新生成基表和元数据表的索引。
更新索引统计信息。
清除同步元数据。