数据库复制就是由两台服务器，主服务器和备份服务器，主服务器修改后，备份服务器自动修改，在以前的文章中已经做了详细的说明，这里就不在重复，具体请参见
https://www.jb51.net/article/30661.htm
使用了数据库复制的人，首先担心的就是主服务器和备份服务器的性能消耗问题，本人也是对此十分担忧，查了半天，基本上没发现类似的测试说明，就自己测试了一下，下面为测试的结果，仅供参考
我采用的是数据库推送的复制模式，下面测试页是基于此模式
因为数据库复制主要是I/O操作，所以在此测试主要测试服务器的硬盘读写操作，此次测试主要监控的对象为
avg. disk queue length（下文简称为dql） 简单可以理解成磁盘数据吞吐量的外在体现。通俗的将就是曲线上随便取两个不同的点，高的一点说明正在的进行读写操作的量比较大，反之，比较小。
第一种情况：1秒钟写入一次数据，一次数据写入三个表，循环写入10000条
过程：关闭复制，单纯的写入，dql平均值最大值为：0.126
开启复制，同步性的写入 ， dql平均值最大值为 ：0.132
结论：鉴于这种比例，1秒钟一次是这种小数据库的写入，同步问题，我们可以完全忽略了
第二种情况：忽略等待时间，一次数据写入三个表，死循环写入10000 次数据
过程 ：关闭复制，单纯的写入，第一次测试：dql平均值最大值为：3.05-3.08 第二次测试：2.2-2.30
开启复制，同步性的写入 ， dql平均值最大值为 ：3.06-3.10 第二次测试： 2.2-2.34
结论：可以由于两次测试间隔时间比较长，机器的情况不一致，但是结果很明显，都是相差不大
第三钟情况：关闭复制，主服务器写入 10000 次数据 ，每次写三个表，然后开启服务器，主服务器的 dql基本没变化，因为是复制服务器写数据，和主服务器关联性不大
就上述情况来看，复制基本上不会影响主服务器的性能消耗，但是，我们通过监控SQL Server Profiler 会发现，出现大量的复制监视器，这种复制监视器，会非常消耗服务器的性能，造成服务器缓慢，因为是推送模式，所以主服务器要时刻监控自己的变化情况，而造成性能消耗，如下图
如何解决这个问题呢？我们首先会想到，减少主服务器的监视频率即可，打开复制监视器，
右键--》发布服务器属性设置，修改一下刷新速度，一般我们可以接受的是范围是30-60秒的延迟
修改后，我们在去SQL Server Profiler 查看，就会发现基本上消耗就会很少了
如果你的服务器复制模式为订阅模式，那么你去--代理配置文件---》分发代理--里面去修改你的订阅时间即可
作者： cnblogs 習 慣
您可能感兴趣的文章:- .net 通过URL推送POST数据具体实现
- SQL Server 2000向SQL Server 2008 R2推送数据图文教程
- JavaScript数据推送Comet技术详解
- Node.js实现数据推送
