我想将数据从海上船只复制到岸上。有时通过卫星链路进行连接，速度很慢，延迟很高。
我们的申请延迟很重要，岸上的人应该尽快获得数据。
有一个表被复制，由id，datetime和一些二进制数据组成，这些数据的长度可能不同，通常＆lt; 50个字节。
离岸应用程序不断地将数据（硬件测量）推送到表中，我们希望这些数据尽可能快地在岸上传输。
MS SQL Server 2008中是否有任何技巧可以帮助减少带宽使用并减少延迟？初始测试使用100 kB / s的带宽。
我们的选择是推动我们自己的数据传输，这里的初始原型设计使用10 kB / s的带宽（同时在相同的时间跨度内传输相同的数据）。这没有任何可靠性和完整性检查，因此这个数字是人为的低。
答案 0 :(得分：1)
您可以尝试不同的复制配置文件或创建自己的配置文件。针对不同的网络/带宽场景优化了不同的配置文件。
MSDN讨论了复制配置文件here。
答案 1 :(得分：1)
您是否考虑过使用WAN加速器设备？我在这里发布一个链接太新了，但有几个可用。
本质上，发送端的设备会压缩传出的数据，接收端会对其进行解压缩，所有操作都是完全无形的。这样做的好处是可以提高流量的表观速度，而无需更改服务器配置。它应该是完全透明的。
答案 2 :(得分：0)
我建议在SQL Server之外进行压缩/解压缩。也就是说，SQL会正常复制数据，但网络堆栈中的某些内容会压缩，因此它会更小，带宽效率更高。
我不知道什么，但我确信这些存在。
不要直接乱用SQL文件。如果不是不可能的话，那就是疯狂。
答案 3 :(得分：0)
您是否期望它始终只是一个复制的表？是否有许多更新，或只是插入？通过在每个更改的行的目标上调用插入/更新sproc来实现复制。一个廉价的优化是强制sproc名称小。默认情况下，它由表名组成，但是IIRC可以为文章强制使用不同的sproc名称。给定一行大约58个字节的插入，在sproc名称中保存5或10个字符是很重要的。
我猜想如果你更新二进制字段，它通常是一个完整的替换？如果这是不正确的，你可能会改变一小部分，你可以推出自己的差异修补机制。也许第二个表包含原始字节更改的时间序列。听起来很痛苦，但可以根据您的工作量大幅节省带宽变化。
插入通常是按逻辑批次完成的吗？如果是这样，您可以将一批插入作为一个自定义blob存储在复制表中，并具有一个辅助进程，将它们解压缩到您要使用的最终表中。这将减少流经复制的这些小行的开销。