我继承了执行以下任务的维护计划:
- 清理旧数据
- 检查数据库完整性
- 执行数据库和事务日志备份
- 重组我们的索引
- 更新统计
- 删除旧的备份和维护计划文件
在23分钟的维护计划中,更新统计信息需要花费惊人的13分钟。在这13分钟内,对数据库的访问被阻止(或至少暂停了从该数据库到我们其他数据库的复制)。
我的问题是:
我们什么时候应该更新统计信息,为什么?
这似乎是我们每天应该减少的工作频率。我试图让我们摆脱“不必要”维护不必要的思维定势。
我继承了执行以下任务的维护计划:
在23分钟的维护计划中,更新统计信息需要花费惊人的13分钟。在这13分钟内,对数据库的访问被阻止(或至少暂停了从该数据库到我们其他数据库的复制)。
我的问题是:
我们什么时候应该更新统计信息,为什么?
这似乎是我们每天应该减少的工作频率。我试图让我们摆脱“不必要”维护不必要的思维定势。
Answers:
如果您没有维护窗口,那么每天更新统计信息可能有点过头了。 特别是如果您为数据库打开了“自动更新统计信息”。在您的原始帖子中,您说过由于该维护计划,用户会发现性能下降。没有其他时间运行此维护计划了吗?没有其他窗口?我看到您的计划包括索引重组,何时重建索引?发生该操作时,统计信息会自动更新(前提是尚未关闭索引功能)。
您究竟应该多久更新一次统计信息,在很大程度上取决于索引和数据接收到的数据修改量。如果有很小的修改(INSERT
,UPDATE
,DELETE
)的数据,那么你可以有更新的统计工作更加罕见的时间表。
找出统计信息是否过时的一种方法是查看执行计划,并且如果您估算的行与返回的实际行有很大差异,则这很好地表明需要增加间隔。在您的情况下,您将采用另一种方式,可能需要进行一些试验。每周更新统计信息,如果您开始看到过时的统计数据的迹象,则从那里开始。
如果您对数据库使用自动更新统计信息,请参阅此参考,以获取更新统计信息的阈值。
何时更新统计信息?
当且仅当自动更新统计信息功能不足以满足您的要求时。我的意思是,如果自动创建和自动更新统计信息处于启用状态,并且由于统计信息不准确或最新,您得到的查询计划很糟糕,那么控制统计信息的创建和更新可能是一个好主意。但是如果您对sql服务器的性能和查询的执行时间还满意的话。
那么我建议您从维护计划中停止“ 更新统计信息”命令
更新统计信息非常重要和有用 。1.允许SQL Server查询优化器一致地生成良好的查询计划,同时保持较低的开发和管理成本。2.查询优化器使用统计信息来估计表达式的选择性,从而估计中间值的大小。和最终查询结果。3.良好的统计数据可使优化器准确评估不同查询计划的成本,然后选择高质量的计划
如果要手动更新统计信息,首先应该知道何时自动更新统计信息
如果自上次创建或更新统计信息以来,SQL Server查询优化器要求表中特定列的统计信息已经经历了实质性的更新活动,则SQL Server将通过对列值进行采样来自动更新统计信息(使用自动更新统计信息) 。统计信息自动更新由查询优化或执行已编译的计划触发,并且仅涉及查询中引用的列的子集。如果AUTO_UPDATE_STATISTCS_ASYNC为OFF,则在查询编译之前更新统计信息
这是一些不错的文章,它们谈论何时在SQL Server中触发更新统计信息
了解统计信息何时触发后,它将帮助您决定何时手动更新统计信息
要了解有关统计信息及其对性能的影响的更多信息,我建议BrentOzar和Kimberly在sqlskills非常好的博客和博客中使用。