复制快照大小过大导致失败

Question

我正在寻找复制快照超过我们预测的 5 倍的解释

复制失败后，我们尝试使用新快照重新初始化订阅。数据库大小为135GB，数据库中的一张表为60GB - 我们已将本文从出版物中排除。这意味着我们期望快照大小约为 75GB。

我们曾多次尝试创建快照，但由于磁盘空间不足而失败。昨晚快照用 340GB 的可用空间填充了磁盘。

我欢迎对这个巨大的快照大小的任何解释。

在检查可能的原因时，我注意到快照格式设置为“字符 - 如果发布者或订阅者未运行 SQL Server，则为必需”。尽管事实上这种跨国复制的两端都是本机 SQL Server。格式之间有大小不同吗？

提前致谢。

Native mode file Size:105 MB
C:>bcp IVM_ArchiveTest.dbo.Event out D:\NOBACKUP\UseOnce\EventNative.dat -T -n 
218977 rows copied. Network packet size (bytes): 4096 Clock Time (ms.) 
Total : 7878 Average : (27796.01 rows per sec.) 

Character mode file Size:66 MB 
C:\>bcp IVM_ArchiveTest.dbo.Event out D:\NOBACKUP\UseOnce\EventChar.dat -T -c 
218977 rows copied. Network packet size (bytes): 4096 Clock Time (ms.) 
Total : 1654 Average : (132392.38 rows per sec.) 

Answer 1

请注意，任何数据的字符表示几乎总是会超过原始大小。根据类型的不同，它可以大大超过。例如。一个 int 列需要 4 个字节，但是1000000Unicode的字符表示需要 ~16 个字节，包括分隔符。那是一个 x4 增加。日期、浮点数、数字通常都会增加，甚至比 x4 更大。

本机格式替代方案是 bcp 实用程序本机格式（因为使用 bcp 应用快照）。在比较单个值时，此格式仅比本机 SQL 存储略长，但它实际上可能导致文件比 SQL Server 所需的存储更小，因为 bcp 文件很密集：没有页头开销，也没有部分填充的页面（碎片，填充因子）。请参阅使用本机格式导入或导出数据。

此外，您还应该压缩快照。请参阅增强常规复制性能：

• 除非需要字符模式快照，否则请使用纯模式快照。对所有订阅服务器使用默认的纯模式快照，但非 SQL Server 订阅服务器和运行 SQL Server Compact 的订阅服务器需要字符模式快照。
• 为发布使用单个快照文件夹。指定与快照位置相关的发布属性时，您可以选择将快照文件生成到默认快照文件夹、备用快照文件夹或两者。当快照代理运行时，在两个位置生成快照文件需要额外的磁盘空间和更多的处理。
• 将快照文件夹放在不用于存储数据库或日志文件的分发服务器本地驱动器上。快照代理将数据按顺序写入快照文件夹。将快照文件夹放在与任何数据库或日志文件不同的驱动器上可以减少磁盘之间的争用，并有助于更快地完成快照过程。
• 在订阅服务器上创建订阅数据库时，请考虑指定 simple 或 bulk-logged 的​​恢复模型。这允许在订阅服务器上应用快照期间执行的批量插入的日志记录最少。将快照应用于订阅数据库后，您可以根据需要更改为不同的恢复模型（复制的数据库可以使用任何恢复模型）。有关选择恢复模型的详细信息，请参阅还原和恢复概述 (SQL Server)。
• 考虑使用备用快照文件夹和压缩快照在低带宽网络的可移动媒体上。压缩备用快照文件夹中的快照文件可以减少快照磁盘存储要求，并使在可移动媒体上传输快照文件变得更容易。在某些情况下，压缩快照可以提高通过网络传输快照文件的性能。但是，压缩快照需要在生成快照文件时由快照代理进行额外处理，在应用快照文件时由分发代理或合并代理进行额外处理。在某些情况下，这可能会减慢快照的生成速度并增加应用快照所需的时间。此外，如果发生网络故障，压缩快照将无法恢复；因此它们不适用于不可靠的网络。在网络上使用压缩快照时，请仔细考虑这些权衡。有关更多信息，请参阅备用快照文件夹位置和压缩快照。