Server如何计算(压缩)备份的初始大小？

Question

创建备份时，Server猜测(？)初始备份文件的a大小。稍后，当它附加日志时，大小可能会被重新调整，有时是多次调整，直到最终大小达到为止。差异越大，备份所需的时间就越长。(与另一个备份相比，该备份的大小稍后不会调整那么多)。示例:使用压缩备份Database1 (大小为500 GB，使用70 GB日志)。.bak文件是以85 GB的大小创建的，经过一段时间的CPU使用之后，我可以看到.bak文件被重新调整为136 GB，这种情况再次发生，直到备份的最终大小达到178 GB为止。

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

我谈到这个话题，是因为我知道我的备份大约需要30分钟，但是现在它花了1，5个小时，尽管数据库并没有增加到300%的大小。仅增长了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

Server如何计算(压缩)备份的初始大小？

从波尔：

对于压缩备份，最终备份文件的大小取决于数据的可压缩性，这在备份操作完成之前是未知的。因此，默认情况下，当使用压缩备份数据库时，数据库引擎将使用pre-allocation algorithm作为备份文件。此算法预先为备份文件分配数据库大小的预定义百分比。如果备份操作需要更多空间，则数据库引擎将生成该文件。如果最终大小小于分配的空间，则在备份操作结束时，数据库引擎将文件缩小到备份的实际最终大小。若要允许备份文件仅在需要时增长才能达到其最终大小，请使用跟踪标志3042。跟踪标志3042导致备份操作绕过默认备份压缩预分配算法。

你应该跟着- 2013年年SharePoint中的备份和恢复最佳实践。

而且，对我来说，你的VM有2 CPU似乎不适合运行70 be的数据库(不确定是只有一个数据库还是多个数据库)。