Question

我们运行SQL Server 2008 R2。数据库大小从20-500 gb不等，并且都处于完全恢复模式。

我发现很难确定事务日志文件的良好初始大小，以防止自动增长。这取决于多重因素，但任何人都可以根据日志的初始大小给出一些好的经验法则吗？我能看到日志在最后xx时间内增长的速度有多快吗？

非常欢迎任何有关此主题的建议..谢谢！

Answer 1

您需要在一段时间内收集元数据，以了解日志文件的增长模式。下面的查询可以设置为作业，使用元数据获取和填充表格，然后您就可以了解您的初始大小需要是什么

SELECT GETDATE() AS DateRun 
     ,(size * 8.0)/1024.0 AS size_in_mb
     , CASE
  WHEN max_size                                 = -1 
  THEN 9999999                  -- Unlimited growth, so handle this how you want
  ELSE (max_size * 8.0)/1024.0                  END AS max_size_in_mb
  FROM YOURDBNAMEHERE.sys.database_files
 WHERE data_space_id                            = 0

Answer 2

您希望避免自动增长，因为它可能会引入延迟和加载峰值。小的自动增长增量也会导致VLF碎片化。尽管如此，应该启用自动增长作为安全网。

目标是让它开启，但从未在实践中发挥作用。第二级目标是不浪费空间并且具有快速恢复时间。日志无法立即初始化。

当我调整日志大小时，我会调整大小，以便在正常操作期间自动增长事件的可能性很低。如果我被迫量化，我会说每年10％的几率是一个非常安全的标准。我将增长增量设置为较低的值，以避免在需要自动增长的情况下加速延迟（甚至超时）。

确定两个日志备份之间最多生成多少日志空间。您可能想要测量峰值负荷下每小时的增长率并增加安全边际。您可以通过记录相隔一小时的日志文件中分配的空间来粗略地衡量增长率。

某些维护操作也可以非常快速地生成大量日志。你也需要测量它。

关键是根据您的备份计划测量两个日志备份之间的峰值日志生成。

如果你想要一个更快，更不科学的解决方案：从一个小的日志开始，让它自动增长一个相当小的增量（256MB？），并看看它在一周后有多大。然后“重新格式化”日志以删除VLF碎片（收缩，然后设置最终大小加上安全边际）。

如何确定SQL Transaction LOG文件的初始大小？

2 个答案: