SQL Server提升事务复制效率优化（一）整体概述

  随着公司业务的发展，数据量增加迅速，在解决Scale Out的同时，还要考虑到主从的复制延迟问题，尽可能降到1s之内知足线上业务，若是不调整，SQL Server默认的配置可能平均要3s左右。生产的复制架构采用的是推送方式进行事务复制，发布服务器下面有4个从节点，两两指向同一虚拟IP，构成负载均衡，服务于不一样的线上业务。对于4个节点，发布库和分法库的压力都很大，订阅库每秒I/O能达到5M，高峰时能达到数十兆。研究并试验了一些时间，给出一些优化建议：

1.硬件、数据库设计：

• 使用SSD磁盘，有钱的可使用PCI-e卡，SSD作RAID10，全部节点部署在内网。
• 更改事务隔离级别为READ_COMMITTED_SNAPSHOT。说实话，SQL Server默认事务隔离级别是读已提交，可是没有多版本的概念，须要设置为READ_COMMITTED_SNAPSHOT才是咱们理解上的读已提交。若是不设置这个，照样会读写互相阻塞。     
• 在建立订阅以前，先将目标数据库的恢复模式改为简单，可以减小日志

ALTER DATABASE [数据库名称] SET RECOVERY SIMPLE WITH NO_WAIT

2.发布、订阅设计：

• 仅发布须要的数据，对于将日志写入数据库并且还要同步复制的，DBA可直接拒绝。
• 表中存在大量非汇集索引，发布时能够不勾选复制非汇集索引选项。通过测试，虽然数据库引擎是在应用完快照最后建立索引的，但建立时间很长，有时甚至会出错。能够在后期手工创建。咱们采用导出脚本方式，而后只保留非汇集索引的脚本在订阅库中创建。

• 若是资源容许，单独创建一个分发服务器。发布和分发服务器在一个服务器上会增长性能损耗，尤为是分发服务器下面有多个订阅服务器时。
• 分发库默认是distribution库，会有专门的做业对该库进行清理，名字就叫“分发清除：distribution”。但这个进程清除分发库的效率过低了，会致使分发库积累大量数据，须要修改运行间隔和每次清楚的数据量。详见以前的随笔：distribution库过大的问题
• 合理使用订阅方式，若是选择推送订阅，势必加大分发服务器的压力，但延迟低 ；若是选择请求订阅，代理服务是在订阅服务器上，减小了分发服务器压力，但延迟会增长。
• 快照代理的生成。对于生成几百GB数据库的快照，采用SSD盘可能在10分钟左右。但会形成很高的性能损耗，要在业务非高峰期生成快照。快照代理文件也要放在SSD盘上，若是资源容许，单独一个驱动盘也能够。
• 若是已经有备份了，那么能够经过备份直接来初始化订阅，省去了生成快照和应用快照的步骤。
• 新发布新的表对象，对于发布库很大的状况下从新初始化是不实际的，能够增量发布，详见sqlserver同步后在不从新初始化快照的状况下新增表
• 对于已发布的表有批处理更新，一种方法是将批量更新分红若干小批量执行，减少事务处理的数据量；另外一种方法是经过存储过程执行更改，并将存储过程发布。推荐第一种
• 将项目分布在多个发不上，这样至关于变向的实现了多线程并行发布，固然也能够经过参数实现并行，下面会讲到

3.参数优化：

• 下降复制代理的详细级别，在初始测试、监视或调试期间除外。 减少分发代理或合并代理的 –HistoryVerboseLevel 参数和 –OutputVerboseLevel 参数。这样能够减小为跟踪代理历史记录和输出而插入的新行数。相反，具备相同状态的之前的历史记录消息将更新为新的历史记录信息。提升测试、监视和调试的详细级别，这样就能够得到有关代理活动的尽量多的信息。在系统开销不是很大的状况下，建议使用默认值1，自己这点对性能消耗能够忽略。
• 增大快照代理的BcpBatchSize参数，-BcpBatch参数表示一个批事务的行数。
• 将快照代理的- MaxNetworkOptimization设置为1，减小将没必要要的信息发送到订阅服务器上。
• 使用快照代理、分发代理的 –MaxBcpThreads 参数（指定的线程数不该超过计算机上的处理器数）。此参数指定建立和应用快照时能够并行执行的大容量复制操做的数目。
• 为分发代理使用 –SubscriptionStreams 参数。 –SubscriptionStreams 参数能够显著提升聚合复制吞吐量。它使到一台订阅服务器的多个链接能够并行应用批量更改，同时在使用单线程时保持多个事务特征的存在。若是有一个链接没法执行或提交，则全部链接将停止当前批处理，并且代理将用单独的流重试失败的批处理。在重试阶段完成以前，订阅服务器上会存在临时事务不一致。失败的批处理成功提交后，订阅服务器将恢复到事务一致状态。官方文档有这个参数，但增长这个参数报错。
• 增大分发代理的 -CommitBatchSize 和CommitBatchThreshold参数的值。 提交一组事务的开销是固定的；经过不常常提交大量事务，就能够将开销分散在大量数据上。可是，增大此参数的优点因应用更改的开销由其余因素（例如包含日志的最大磁盘 I/O）限制而下降。另外，须要考虑如下权衡问题：任何致使分发代理从新开始的失败必须回滚并从新应用大量事务。对于不可靠的网络，越小的值致使失败的概率越小，若是致使失败，将回滚并从新应用较少许事务。
• 增大日志读取器代理的 -ReadBatchSize 参数的值。-ReadBatchSize 表示日志读取器代理和分发代理支持事务读取和提交操做的批大小。批大小的默认值为 500 个事务。日志读取器代理从日志中读取特定数量的事务，而无论这些事务是否标记为复制。将大量事务写入发布数据库，而其中只有一小部分标记为复制时，则应使用 -ReadBatchSize 参数增长日志读取器代理的读取批大小。此参数不适用于 Oracle 发布服务器。
• 为日志读取器代理使用 –MaxCmdsInTran 参数。–MaxCmdsInTran 参数指定日志读取器向分发数据库写入命令时组成一个事务的语句的最大数量。使用此参数可以使日志读取器代理和分发代理在订阅服务器上应用命令时将发布服务器上的大事务（由许多命令组成）分红若干个较小的事务。指定此参数能够减小分发服务器的争用问题并缩短发布服务器与订阅服务器之间的滞后时间。因为初始事务是以较小的单元应用的，订阅服务器能够在初始事务结束以前访问一个较大的逻辑发布服务器事务的行，于是会破坏事务的原子性。默认值为 0，这将保持发布服务器的事务边界。官方文档有该参数，但实际设置里面没有。
• 减少日志读取器代理和分发代理的 -PollingInterval 参数的值。 -PollingInterval 参数指定为要复制的事务查询已发布数据库的事务日志的频率。默认值为 5 秒。若是减少此值，日志的轮询将更加频繁，这会使事务从发布数据库传递到分发数据库的滞后时间较低。可是，应该对较低滞后时间的须要和因频繁轮询致使的服务器上增长的负荷之间进行平衡。