SQL Server 数据库备份文件是最终大小的两倍，直到备份完成

Question

我刚刚为一个相当大的数据库（1.3 TB）编写了一个备份语句，我一直在使用一个更小的数据库（10 GB + 10 GB 日志文件）对其进行测试。备份写入三个目的地。在测试期间，我注意到当备份运行时，每个备份文件的大小约为 1.2 GB，但是一旦备份过程完成，文件就会缩小到 600 MB 以下。

我有兴趣了解：

• 为什么文件在备份过程中变大然后缩小？
• 是否有办法防止这种情况，
• 当我备份 1.3 TB 的数据库时，文件可能有多大 - 如果文件再次是其最终大小的两倍，那么我可能需要请求更多的磁盘空间！

这是我正在使用的备份语句：

BACKUP DATABASE @DatabaseName
TO  DISK = @backupMedia1,
    DISK = @backupMedia2,
    DISK = @backupMedia3
WITH COMPRESSION, RETAINDAYS = 0, NOFORMAT, INIT, NOSKIP, NAME = @DatabaseName

Answer 1

这是一个已知问题和预期行为（这是设计使然）。本质上，备份保留了它认为可能需要的空间总量，然后在最后一步缩小。要更改行为，您可以使用跟踪标志 3042 进行试验。来自http://msdn.microsoft.com/en-us/library/bb964719.aspx#Allocation：

对于压缩备份，最终备份文件的大小取决于数据的可压缩程度，这在备份操作完成之前是未知的。因此，默认情况下，在使用压缩备份数据库时，数据库引擎对备份文件使用预分配算法。该算法为备份文件预先分配了数据库大小的预定义百分比。如果在备份操作期间需要更多空间，数据库引擎会增大文件。如果最终大小小于分配的空间，则在备份操作结束时，数据库引擎会将文件缩小到备份的实际最终大小。

要允许备份文件仅根据需要增长以达到其最终大小，请使用跟踪标志 3042。跟踪标志 3042 使备份操作绕过默认备份压缩预分配算法。如果您需要通过仅分配压缩备份所需的实际大小来节省空间，则此跟踪标志很有用。但是，使用此跟踪标志可能会导致轻微的性能损失（可能会增加备份操作的持续时间）。