相关疑难解决方法(0)

这个问题在大多数论坛和整个网络中似乎是一个常见问题，这里以多种格式提出，通常听起来像这样：

在 SQL Server 中 -

• 事务日志变得如此之大的一些原因是什么？
• 为什么我的日志文件这么大？
• 有什么方法可以防止这个问题的发生？
• 当我找到根本原因并希望将我的事务日志文件调整到正常大小时，我该怎么办？

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