数据库碎片整理和自动增长设置

Question

我们确实为 SQL Server 2008 r2 express 制定了一些维护计划。如果任何表的页数超过 50 并且平均碎片超过 20，我们每个月都会对数据库进行碎片整理。

如果数据库日志大小>2MB，则恢复模式为简单，收缩，恢复模式重新设置为FULL。如果 Page_count>50 且 avg_fragmentation_in_percent > 30，则索引为 REBUILD。

如果 Page_count>50 且 avg_fragmentation_in_percent > 5 且 <30，则索引为 REORGANIZE。

这就是我们目前正在做的事情。但是我们发现自增长事件是资源密集型的，不应重复发生。现在，对于所有数据库，mdf 文件的自动增长设置为 MB，ldf 文件设置为 10%，这是创建新数据库时的默认值。我们计划根据每天变大的数据库数量来增加数据库的自动增长值。但是我想知道有多少自动增长事件对数据库来说是理想的。我应该设置自动增长以便它每天、每周或每月等只发生一次吗？所以请帮助我为我的数据库设置自动增长值。还有另一个问题，如果我每月对数据库进行碎片整理，那么它就会缩小。因此，在此之后，对于所有我确实收缩过的数据库，在写入新数据时都会发生一次自动增长。所以会有很多自动增长事件。那么会不会有问题呢？请告诉我一个解决方案。

Answer 1

如果任何表的页数超过 [超过] 50 [页]

那仍然是非常小的。对于少于1000 页的任何索引，我通常不会考虑碎片。

并且 avg_fragmentation_in_percent > 30 那么索引是 REBUILD

这是重建的一个很好的阈值，但我也会考虑重新组织碎片范围在 5% 到 30% 之间的索引。

如果数据库日志大小>2MB，则恢复模式为简单，收缩，恢复模式重新设置为FULL

你为什么做这个？如果日志文件大于 2 MB，为什么会出现问题？那是极小的。更不用说，当您切换到SIMPLE、缩小，然后返回到FULLrecovery 时，您正在破坏日志链。您可能会因时间点恢复而陷入严重的麻烦。 适当调整日志文件的大小，并仅在紧急情况下允许自动增长。 收缩数据库文件只能在极端情况下进行，绝不是日常维护计划的一部分。

但我们发现自生长事件是资源激励，不应重复发生

正确的。这就是尺寸调整发挥作用的地方。监视并在使用一定百分比的空间时收到警报。这样您就可以为维护窗口规划手动文件增长操作，以最大限度地减少对最终用户的影响。

和 10% 用于 ldf 文件，这是创建新数据库时的默认值

尽管文件增长百分比是默认的，但我建议不要这样做。您不希望文件增长数量可变。如果您必须依靠自动增长，那么您想确切地知道文件将增长多少。更不用说，随着日志文件的增长，您将拥有数量可变的虚拟日志文件 (VLF) 和额外的空间。您想巧妙地计划这一点，这可以通过固定数量的文件增长来完成。

我应该设置 autogroth 以便它每天、每周或每月等只发生一次吗

为固定数量的空间（不是百分比）设置自动增长，只有您可以确定什么是合适的数量。太小了，您将频繁地自动增长而对最终用户的影响最小，但经常发生。Autogrowth 设置得太高，那么你的增长频率会降低，但当它发生时，影响将持续更长的时间。

我的推荐？监视数据库文件中使用的空间。当它达到一定百分比（例如，使用了 80% 的空间）时，您应该收到警报。然后在维护窗口期间安排手动增长。

Answer 2

托马斯·斯金格 (Thomas Stringer) 的观点是您回答所需的全部内容。但我会更深入地了解您如何确定自动增长设置？

但我想知道有多少自动增长事件对数据库来说是理想的。我应该设置自动增长，使其每天、每周或每月等只发生一次。所以请帮助我为我的数据库设置自动增长值。还有另一个问题。如果我每月对数据库进行碎片整理，那么它就会缩小。因此，在此之后，对于所有我收缩的数据库，当新数据写入它时都会发生一次自动增长。所以会有很多自动增长事件。那么会不会有问题呢？

没有数学公式来计算您的自动增长设置，尤其是当您不做数据库基线时。

现在，正如@ThomasStringer 指出的那样，您不应允许数据库自动增长以 % 为单位，而应将其设置为 MB，您可以使用默认 Trace找出服务器实例上发生的自动增长事件。

--below code will help you in finding autogrowth events on your server instance.
IF OBJECT_ID('tempdb..#autogrowthTotal') IS NOT NULL
    DROP TABLE #autogrowthTotal;

IF OBJECT_ID('tempdb..#autogrowthTotal_Final') IS NOT NULL
    DROP TABLE #autogrowthTotal_Final;

DECLARE @filename NVARCHAR(1000);
DECLARE @bc INT;
DECLARE @ec INT;
DECLARE @bfn VARCHAR(1000);
DECLARE @efn VARCHAR(10);

-- Get the name of the current default trace
SELECT @filename = CAST(value AS NVARCHAR(1000))
FROM::fn_trace_getinfo(DEFAULT)
WHERE traceid = 1
    AND property = 2;

-- rip apart file name into pieces
SET @filename = REVERSE(@filename);
SET @bc = CHARINDEX('.', @filename);
SET @ec = CHARINDEX('_', @filename) + 1;
SET @efn = REVERSE(SUBSTRING(@filename, 1, @bc));
SET @bfn = REVERSE(SUBSTRING(@filename, @ec, LEN(@filename)));
-- set filename without rollover number
SET @filename = @bfn + @efn

-- process all trace files
SELECT ftg.StartTime
    ,te.NAME AS EventName
    ,DB_NAME(ftg.databaseid) AS DatabaseName
    ,ftg.[FileName] AS LogicalFileName
    ,(ftg.IntegerData * 8) / 1024.0 AS GrowthMB
    ,(ftg.duration / 1000) AS DurMS
    ,mf.physical_name AS PhysicalFileName
INTO #autogrowthTotal
FROM::fn_trace_gettable(@filename, DEFAULT) AS ftg
INNER JOIN sys.trace_events AS te ON ftg.EventClass = te.trace_event_id
INNER JOIN sys.master_files mf ON (mf.database_id = ftg.databaseid)
    AND (mf.NAME = ftg.[FileName])
WHERE (
        ftg.EventClass = 92 -- Data File Auto-grow
        OR ftg.EventClass = 93
        ) -- Log File Auto-grow
ORDER BY ftg.StartTime

SELECT count(1) AS NoOfTimesEventFired
    ,CONVERT(VARCHAR(10), StartTime, 120) AS StartTime
    ,EventName
    ,DatabaseName
    ,[LogicalFileName]
    ,PhysicalFileName
    ,SUM(GrowthMB) AS TotalGrowthMB
    ,SUM(DurMS) AS TotalDurationMS
INTO #autogrowthTotal_Final
FROM #autogrowthTotal
GROUP BY CONVERT(VARCHAR(10), StartTime, 120)
    ,EventName
    ,DatabaseName
    ,[LogicalFileName]
    ,PhysicalFileName
--having count(1) > 5 or SUM(DurMS)/1000 > 60 -- change this for finetuning....
ORDER BY CONVERT(VARCHAR(10), StartTime, 120)

SELECT *
FROM #autogrowthTotal_Final

下面将是输出

注意：我在图片中突出显示了每列的含义以及您应该查找的内容。

基本上，您必须在一段时间内监视您的自动增长事件，例如在高活动期间或整个业务周期，然后对其进行平均将为您提供一些您可以为自动增长设置选择的确切值。

现在，对于日志文件，您还必须考虑索引维护、CHECKDB 运行等因素。因此，请调整日志文件的大小以支持数据库中发生的数据更改量，并经常进行日志备份，以便快速重用空间日志文件中。

此外，值得一提的是，您还应该启用即时文件初始化。仅适用于数据文件！

请参阅数据文件大小管理的重要性，尤其是 Paul Randal 的数据文件增长和数据文件收缩。

注意：不要缩小数据库，除非您对数据进行了大量清除并且确定数据库不会再增长那么大。它会导致碎片化，并且数据库会增长！