多个事务日志文件和性能影响

Question

所以我和几个人就一个给定的数据库应该拥有的事务日志文件的数量进行了争论。我看过几篇帖子说每个数据库应该只有 1 个事务日志文件，但在任何 Microsoft 白皮书中都没有。然而，在许多情况下，我已经看到增加给定数据库的事务日志文件的数量实际上会提高对数据库的写入性能。我应该注意到，所有这些数据库都处于完全恢复模式，并且为 I/O 子系统使用了大型 SAN 框架。如果很多帖子都说事务写入都是串行发生在一个文件中，直到到达文件末尾，那么写入会转移到后续的日志文件中，为什么增加日志文件的数量最终会对磁盘写入速度有非常明显的提高？在最近的案例中，通过将日志文件的数量从 1 增加到 8，我们看到 IO 从 700 Kb/s 跃升至超过 60 Mb/s。任何输入都将不胜感激。

Answer 1

事务日志写入是顺序的。任何时候都只会写入其中一个日志文件，因此拥有多个文件 - 就其本身而言 - 不可能更改该数据库的I/O 模式。

除非你很幸运。例如，您已将第二个日志文件添加到 SSD 或其他更快或更不繁忙的磁盘，或将日志文件拆分到多个磁盘并为多个数据库这样做，并且您现在观察到更好的 I/O，因为日志已切换到更快磁盘上的该文件，或者与您的其他数据/日志文件更加隔离。换句话说，我相信任何观察到的 I/O 差异完全是由于其他因素造成的，只是巧合，而不是因为您单独添加了日志文件。SQL Server 被明确设计为一次仅使用一个日志文件 - 那么多个日志文件如何可能提高日志写入性能，除非当前日志文件在更快/更隔离的磁盘上？我认为您需要提供更好的经验证据（这样做您可能会发现性能提高的真正原因）。

请完整阅读这些帖子——它们是由一位在 SQL Server 存储团队工作了很长一段时间的非常聪明的人写的，所以我认为他不会为了好玩而制作这些东西：

• 多个日志文件以及它们为什么不好
• 适当的事务日志大小管理的重要性

Kimberly Tripp 在一篇有价值的文章中也谈到了这一点：

• 提高事务日志吞吐量的 8 个步骤

请注意，这 8 个步骤均不涉及添加事务日志文件。事实上，她建议反对。

拥有多个日志文件还有其他危险，特别是如果它们很大（想想 RTO）——而且真的没有任何好处。

Answer 2

您最初的想法是正确的：拥有多个事务日志文件没有任何好处。SQL Server 按顺序而不是同时使用事务日志。

为什么增加日志文件的数量最终会显着提高磁盘写入速度？

不会的。肯定还涉及另一个尚未考虑的因素（即，您是否只是简单地推送更多记录的事务以获得更高的吞吐量，从而导致实际更高的吞吐量？添加的事务日志文件是否比单个日志文件存储在更快的存储上，从而导致多重测试中的当前事务日志文件是否优于初始测试中的单个事务日志？）。

拥有多个事务日志文件唯一有意义的情况是在紧急情况下，您需要更多事务日志空间，并且当前的单个事务日志无法增长（卷空间不足等）。在这种情况下，它会让您清楚，但拥有多个事务日志将是一个非常临时的状态。在这种情况下，明智的做法是尽快清理并恢复到单个事务日志。