大型事务日志是否会导致cpu上升

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

要回复问题请先登录注册