我是否需要在我的数据库日志文件所在的磁盘上留下一些额外的可用空间，以便成功进行日志备份操作？

Question

如果我调整日志文件的大小以均匀分割它们所在的整个驱动器，不留下额外的可用空间，日志备份是否仍然能够成功进行？我有多个数据库，每个数据库有一个日志文件。

不要在驱动器上留下任何可用空间，即将它全部分配给日志文件是一种好习惯吗？（在这种情况下，驱动器专用于日志文件，数据和操作系统位于它们自己的分区上。）

Answer 1

日志备份不会改变日志文件的大小，并且您需要该驱动器上的空间的唯一原因是如果您在那里备份日志（这与放置房屋钥匙和同一个密钥环上的备份）。但是一个稍微不同的问题，您是否希望您的日志文件永远不会增长？留出一点空间至少可以让您有一些时间来处理异常增长的日志文件。没有剩余空间，只要日志文件需要增长，您就会崩溃。

Answer 2

如果日志文件所在的驱动器没有可用空间，则SQL Server没有技术问题，假设日志本身没有用完可用的、未使用的 VLF 条目。

如果日志用完可用空间，则在解决问题之前您将无法提交任何事务。如果日志文件占用了整个驱动器，则您可以采取的唯一操作是将不同驱动器上的日志文件添加到数据库中。如果您主动管理您的日志文件，并且永远不会用完日志空间，那么就没有技术禁止做您正在考虑的事情。

话虽如此，我不建议您调整日志文件的大小以消耗所有可用的驱动器空间：

1. Windows 会抱怨磁盘空间不足，这很烦人。
2. 如果您确实用完了日志空间，并且您几乎肯定会在某个时候用完，那么在您添加新的日志文件之前，将无法访问数据库。
3. 磁盘空间的成本是多少？与 SQL Server 企业版许可的价格以及停机时间给企业带来的潜在成本相比，这几乎算不了什么。问问自己为什么不在驱动器上留一点空闲空间。请不要认为这意味着我支持使用错误的数据类型，例如使用 abigint而不是int，甚至是smallint。未使用的磁盘空间很便宜，但由于@SolomonRutzky在这里简要概述的原因，应将数据库内使用的空间视为溢价。

在评论中，您提到您发现日志增长以填充磁盘与磁盘已经被填充的大部分空日志随后被填充之间没有区别。假设是正确的，这两个事件都会导致服务器返回以下错误：

消息 9002，级别 17，状态 2，第 22 行
由于“LOG_BACKUP”，数据库“<database_name>”的事务日志已满。

但是，如果您有 SAN，您可以精简配置最大大小为 10TB 的驱动器。使用估计的“正确”初始大小创建日志文件，比如 1GB，增长设置为 1GB（或任何有意义的）。这样您使用的 SAN 磁盘空间就不会超过您的需要，但您将有空间增长日志文件，而无需涉及 SAN 管理员。双赢。

在我之前版本的回答中，我陈述了以下不正确的信息：

当您已经用完日志空间时添加日志文件可能是不可能的，因为添加日志文件这一事实会修改主数据文件，这需要写入日志。这是一种先有鸡还是先有蛋的事情。

经过一些相当广泛的测试，我能够在现有日志文件空间不足后成功添加新的日志文件。我在SQLServerScience.com 上写了一篇博客文章，展示了它是如何工作的。添加新日志文件所需的操作包括：

1. 在磁盘上物理创建新文件
2. 将新的 VLF 结构写入文件
3. 更新现有的日志文件 - 现有的日志文件中必须有足够的空间来预分配用于此目的，不能用于其他任何用途。
4. 更新主 mdf 以反映新创建的日志文件。

以上已在 SQL Server 2008 R2 和 SQL Server 2016 上进行了验证。