SQL 日志文件 2TB 不够，现在怎么办？

Question

这是一个假设性问题，源自sepupic的回答，他们解释说 2TB 是 SQL 日志文件的物理限制。

如果您需要超过 2Tb，则添加第二个日志文件。

我一直认为多个日志文件是坏的，如多事务日志文件和性能影响一文中所述

我只是无法想象甚至会出现 2TB 日志文件的场景，但如果发生了，并且出于某种原因，更频繁的日志备份将无法治愈它（隐含多种场景），您会怎么做？

您是否添加了第二个日志文件，或者还有其他内容吗？

Answer 1

多个日志文件是坏的

并不是说多个日志文件不好……而是多个日志文件完全没有必要并且没有任何好处……除非您需要大于 2TB 的日志文件。

对于数据文件，SQL Server 可以从多个文件中受益，因为它可以同时对两个文件执行并行 I/O。但是，对于日志文件，SQL Server 只会写入其中之一。日志文件的循环性质意味着如果创建两个文件，SQL Server 将写入一个文件，到达末尾，然后写入另一个文件，到达末尾，然后返回到第一个文件，依此类推。

拥有多个日志文件不会带来性能提升。

但是，由于容量限制，任何日志文件的大小最多为 2TB，如果您需要超过 2TB 的日志文件，则需要创建多个日志文件。这是创建多个日志文件的唯一原因。

为什么需要 2TB 的日志文件？

我无法想象甚至会出现 2TB 日志文件的场景

因为您的事务日志会在完全备份期间增长，如果您有一个非常大的数据库，需要一个日志时间来备份，并且在备份期间非常繁忙，您在备份期间可能会生成超过 2TB 的事务日志。

同样，如果您有一个非常大的日志运行事务（例如在非常大的表上重建索引），您可能会生成 2TB 的事务日志，然后才能重新使用它。

当然，您的事务日志可能会因多种原因而增长。这些不一定使您的日志变得非常大是正常的，但它们确实有助于增长。如果您的事务日志备份没有成功完成，或者您的 AG 没有同步，或者复制没有从您的日志中读取事务......您的日志文件将会增长。如果这些问题继续存在，您的日志文件最终将达到 2TB。

也就是说，需要 2+TB 的日志文件是非常罕见的。