大型事务日志会导致 CPU 升高吗答案

【问题标题】：Can a large transaction log cause cpu hikes to occur大型事务日志会导致 CPU 升高吗
【发布时间】：2010-12-23 12:41:16
【问题描述】：

我有一个客户端，在 Sql Server 2005 上拥有一个非常大的数据库。分配给数据库的总空间为 15Gb，其中大约 5Gb 分配给数据库，10Gb 分配给事务日志。就在最近，连接到该数据库的 Web 应用程序正在超时。

我已经跟踪了网页上的操作，并检查了在执行这些 Web 操作时执行的查询。执行计划中没有任何不妥之处。

查询本身使用了多个连接，但完成速度非常快。但是，数据库服务器的 CPU 在几秒钟内上升到 100%。当多个同时用户在系统上工作时会出现此问题（当我说多个 .. 阅读大约 5 时）。在此超时开始发生。

我想我的问题是，大型事务日志会导致 CPU 性能问题吗？目前磁盘上有大约 12Gb 的可用空间。配置有点失控，但 db 和 log 都在同一个物理磁盘上。

我很欣赏日志文件很大并且需要注意，但我只是想知道这是否会导致 CPU 峰值（即试图找到相关性）。超时是最近发生的事情，这个应用已经响应了几年（即它最近的表现）。

非常感谢，

【问题讨论】：

【解决方案1】：

由于缺乏数据，很难准确地说出，但在事务日志检查点上通常会观察到峰值。

检查点是将按顺序附加并存储在事务日志中的数据应用到实际数据文件的过程。

这涉及大量I/O，包括CPU 操作，可能是CPU 活动高峰的原因。

通常，当事务日志70% 已满或SQL Server 确定恢复过程（重新应用日志）需要的时间超过1 分钟时，就会出现检查点。

【讨论】：

【解决方案2】：

您的首要任务应该是处理事务日志大小。数据库是否被正确备份，以及备份的频率。解决这些问题，然后查看 CPU 峰值是否消失。 CHECKPOINT 是读取您的事务日志并将更改应用到数据库文件的过程，如果事务日志很大，那么它可能会影响它是否有意义？

【讨论】：

【解决方案3】：

您可以尝试扩展自动增长：Kimberley Tripp 建议以 GB 为单位的事务日志自动增长超过 500MB：

（见第 7 点）

【讨论】：

【解决方案4】：

虽然如果有这么大的日志不会导致问题，我不会感到惊讶，但也有其他问题。统计数据最近更新了吗？当某些自动化作业正在运行时是否会出现峰值，是否有明确的时间模式来判断何时出现峰值 - 然后看看还有什么正在运行？您是否在峰值开始发生时在服务器上加载了任何新版本？

无论如何，事务日志都需要修复。它如此之大的原因是它没有被备份（或没有足够频繁地备份）。备份数据库是不够的，还必须备份日志。我们每 15 分钟备份一次，但我们的系统是一个高度事务性的系统，我们不能承受丢失数据的后果。

【讨论】：