SQL Server 如何计算（压缩）备份的初始大小？

Question

创建备份时，SQL Server 会猜测（？）初始备份文件的大小。稍后，也许当它附加日志时，大小会被重新调整，有时会多次调整，直到达到最终大小。差异越大，备份所需的时间就越长。（与另一个备份相比，稍后不会调整大小）。示例：Database1（大小为 500GB，使用了 70GB 的日志）通过压缩进行备份。创建的 .bak 文件大小为 85 GB，一段时间后 CPU 使用率上升，我可以看到 .bak 文件重新调整为 136 GB，这种情况再次发生，直到备份的最终大小为 178GB到达。

当这些重新计算发生时，与同一台机器上的其他备份相比，以 MB/s 为单位的平均备份速度会降低。唯一来自附加和清除日志吗？还是因为数据库中使用的数据类型不同？意味着它们以不同的压缩率压缩，或者其他什么？

我来到这个话题，因为我知道我的备份需要大约 30 分钟，但现在即使数据库没有增长到其大小的 300%，也需要 1.5 小时。它仅增长了 30%。

使用等待统计数据，我可以看到除了 BackupIO 之外，我还在某个时候等待 CPU (SOS_SCHEDULER_YIELD)。

Machine Details:
VMWare 6.0 
32 GB of Memory (Max memory 28GB given to SQL Server)
2 logical CPU
Max Degree of Parallelism (1, it's a Sharepoint 2013)   
SQL Server 2014
Windows Server 2012 R2
running on an SSD Raid (5)

当然，我为运行备份的用户启用了即时文件初始化。

Answer 1

SQL Server 如何计算（压缩）备份的初始大小？

来自 BOL：

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

要允许备份文件仅根据需要增长以达到其最终大小，请使用跟踪标志 3042。跟踪标志 3042使备份操作绕过默认的备份压缩预分配算法。

您应该遵循 - SharePoint 2013 中的备份和还原最佳实践。

此外，对我而言，您的具有 2 个 CPU 的 VM 似乎无法运行 70GB 数据库（不确定是只有一个数据库还是多个数据库）。