我有一个客户端，在 Sql Server 2005 上有一个非常大的数据库。分配给数据库的总空间为 15Gb，其中大约 5Gb 分配给数据库，10Gb 分配给事务日志。就在最近，连接到该数据库的 Web 应用程序正在超时。
我已经跟踪了网页上的操作，并检查了在执行这些 Web 操作时执行的查询。执行计划中没有任何不妥之处。
查询本身使用了多个连接，但完成速度非常快。但是，数据库服务器的 CPU 在几秒钟内上升到 100%。当多个同时用户在系统上工作时会出现此问题（当我说多个 .. 阅读大约 5 时）。在此超时开始发生。
我想我的问题是，大型事务日志会导致 CPU 性能问题吗？目前磁盘上有大约 12Gb 的可用空间。配置有点失控，但数据库和日志都在同一个物理磁盘上。
我很欣赏日志文件很大并且需要注意，但我只是想知道这是否可能导致 CPU 峰值（即试图找到相关性）。超时是最近的事情，这个应用程序已经响应了几年（即它最近的表现）。
非常感谢，
由于缺乏数据，很难准确地说，但在事务日志检查点上通常会观察到峰值。
检查点是将顺序附加并存储在事务日志中的数据应用到实际数据文件的过程。
这涉及很多I/O，包括CPU操作，并且可能是CPU活动高峰的一个原因。
通常，当事务日志70%已满或SQL Server决定恢复过程（重新应用日志）需要超过1一分钟的时间时，就会出现检查点。
您的首要任务应该是处理事务日志大小。数据库是否被正确备份，以及备份的频率。解决这些问题，然后查看 CPU 峰值是否消失。CHECKPOINT 是读取事务日志并将更改应用到数据库文件的过程，如果事务日志很大，那么它可能会影响它是否有意义？
您可以尝试扩展自动增长：Kimberley Tripp 建议以 GB 为单位的事务日志自动增长超过 500MB：
http://www.sqlskills.com/blogs/kimberly/post/8-Steps-to-better-Transaction-Log-throughput.aspx
（见第 7 点）
虽然如果拥有这样大小的日志不会导致问题，我不会感到惊讶，但也可能存在其他问题。统计数据最近更新了吗？当某些自动化作业正在运行时是否会出现峰值，是否有明确的时间模式来判断何时出现峰值 - 然后看看还有什么正在运行？您是否在峰值开始发生时在服务器上加载了任何新版本？
无论如何，事务日志都需要修复。它如此大的原因是它没有被备份（或没有足够频繁地备份）。备份数据库是不够的，还必须备份日志。我们每 15 分钟备份一次，但我们的系统是一个高度事务性的系统，我们不能承受丢失数据的后果。