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