我已经通过 sql server 2008 r2 中的数据收集器监控文件增长两周了。该数据库以每天 35 (MB) 左右的速度持续增长。数据库尚未达到 2 GB 的初始大小。
数据库文件自动增长设置为 5MB,我想尝试不同的方法,所以我正在寻找建议和/或评论。
每周日晚上 1:30 有一个调优任务运行。该任务将:
- 检查数据库完整性
- 缩小日志文件——(这没关系,因为日志模式很简单)
- 收缩数据库
- 重组索引
- 重建索引
- 更新统计
- 清理历史
我想在每周调整计划中再添加两个步骤:
- 如果已用空间达到某个阈值或总大小,则将数据库文件增加 500 MB。
- 如果已用空间达到总大小的某个阈值,则将日志文件增加 250 MB(收缩后)。
通过将增长负担放在离线时间,我希望通过减少重负载期间的自动增长事件数量来获得性能。
我有两个与自动增长文件有关的问题。
- 放置文件增长步骤的最佳位置是在当前步骤之前还是之后?
- 如果我使用
ALTER DATABASE|MODIFY FILE
来增长文件,那么我如何确定是否SpaceUsedInFile >= (TotalFileSpace-@AllowanceThreshold)
?
您的目标应该是尽可能少地自动增长。即使是即时文件初始化,一天七次也很痛苦。
不要做收缩数据库。曾经。Shrinkfile,也许是,但只有在一个非常事件之后。收缩它只是为了再次增长是徒劳的,实际上应该被称为自动碎片。
如果恢复模型很简单,那么您根本没有办法将日志文件增加 250 GB。文件中的已用空间会随着时间的推移自动清除,除非您在一个月前开始交易并且无意提交或回滚它。
所以我的建议是:
在安静期间手动自动增长数据文件,使其大小可以适应几个月的增长。这段时间你存它干什么?
将数据文件的自动增长增量设置为相对较小的值(这样它在发生时不会中断用户),并在此事件上发出警报(例如,您可以在默认跟踪中捕获它,或通过扩展事件)。这可以告诉您,您正在达到您估计的高点,是时候再次手动增长了。此时,您需要保留本手册,以防您想在不同的驱动器上添加新文件/文件组以容纳空间,因为最终您将填满当前驱动器。
例如,将日志文件自动增长到有史以来最大的两倍。它不应该进一步自动增长,除非有一些异常交易阻碍了事情。您还应该监视此事件,以便了解它们。
如果可能,您应该尽量避免自动增长。问题是您无法控制何时会发生增长,并且您的系统可能会受到严重打击。
将您的文件大小设置为一个月左右的合理大小,并从那里监控您的增长率,计算出您估计 X 时间量的空间量,并将您的大小设置为该值 + 误差范围。
我已经设置了一个简单的监控作业,当文件大小在自动增长之前达到预定义的最大值时会提醒我。你可以使用这样的东西:
这当然可以安排为一项工作。