估计预计的数据库增长

我最近开始以DBA培训生的身份使用SQL Server 2008。我需要计算数据库的大小，还需要估计数据库在最近几个月的增长以及未来12个月的预测增长。

我可以使用sp_spaceused语句来计算实际大小，但是如何计算其他所有内容？

其他答案在技术上是正确的，但在现实世界中不是正确的。您需要向商家咨询以下内容：

我的目标是什么时间范围？就您而言，您正在寻找一个12个月的数字。

在那段时间里，我们将归档数据还是保留所有数据？在某些企业中，您只能（或被要求）保留一定数量的数据，例如最近12个月。在这种情况下，您需要确定数据增长（后续问题将回答），然后回溯到最后一个滚动的12个月。您不能只说“现在数据量为100GB”，因为如果您的数据量在增长，那么过去12个月也在增长。时间量可能是恒定的，但数据不是恒定的。

我们会添加其他用户吗？例如，企业可能正在发展到新的领域或获得新的客户。如果他们使用户群增加一倍，那么在某些情况下，数据也会开始增加一倍。

我们期望业务量增长吗？例如，如果您正在网站上跟踪销售情况，并且开始投放“超级碗”或“世界杯”广告，则数据量会达到曲棍球棒增长曲线。

我们会在应用程序中添加其他功能吗？如果应用突然开始存储图像，这将极大地影响数据库的大小。

我们将要添加其他来源的数据还是记录新数据？如果您开始捕获网站的点击，或者在数据仓库中添加其他来源，那么数据量将会增加。

开发人员或DBA是性能调优指标吗？如果要让人们创建索引，则可以根据数据获取的热情程度轻松地将数据大小增加一倍（或三倍或四倍）。

而且，只要您在问这些问题，您还应该询问性能是否期望保持不变，下降或变得更好。我喜欢在折线图上绘制预计的增长，然后比较同一时间范围内的硬件和员工培训投资。

没有以前的增长历史，就无法准确预测未来的增长。但是，您可以使用备份历史记录作弊并获得大致趋势，如Erin Stellato在“ 从备份趋势化数据库增长”中详细介绍的那样。

在Excel中绘制以下查询的输出：

SELECT
    [Database] = [database_name]
    , [Month] = DATEPART(month,[backup_start_date])
    , [Backup Size MB] = AVG([backup_size]/1024/1024)
    , [Compressed Backup Size MB] = AVG([compressed_backup_size]/1024/1024)
    , [Compression Ratio] = AVG([backup_size]/[compressed_backup_size])
FROM 
    msdb.dbo.backupset
WHERE 
    [database_name] = N'YourDatabaseName'
AND [type] = 'D'
GROUP BY 
    [database_name]
    , DATEPART(mm, [backup_start_date]);

有许多方法可以执行数据库容量规划。

如果定期修整msdb备份历史记录，您将没有太多数据可用于分析

正如Mark所指出的那样，可以使用Erin描述的方法来完成-通过备份来趋势化数据库的增长。

您甚至可以使用PIVOT从备份历史记录中找出12个月内的数据库增长情况，如下所示：

DECLARE @startDate DATETIME;

SET @startDate = GetDate();

SELECT PVT.DatabaseName
    ,PVT.[0]
    ,PVT.[-1]
    ,PVT.[-2]
    ,PVT.[-3]
    ,PVT.[-4]
    ,PVT.[-5]
    ,PVT.[-6]
    ,PVT.[-7]
    ,PVT.[-8]
    ,PVT.[-9]
    ,PVT.[-10]
    ,PVT.[-11]
    ,PVT.[-12]
FROM (
    SELECT BS.database_name AS DatabaseName
        ,DATEDIFF(mm, @startDate, BS.backup_start_date) AS MonthsAgo
        ,CONVERT(NUMERIC(10, 1), AVG(BF.file_size / 1048576.0)) AS AvgSizeMB
    FROM msdb.dbo.backupset AS BS
    INNER JOIN msdb.dbo.backupfile AS BF ON BS.backup_set_id = BF.backup_set_id
    WHERE BS.database_name NOT IN (
            'master'
            ,'msdb'
            ,'model'
            ,'tempdb'
            )
        AND BS.database_name IN (
            SELECT db_name(database_id)
            FROM master.SYS.DATABASES
            WHERE state_desc = 'ONLINE'
            )
        AND BF.[file_type] = 'D'
        AND BS.backup_start_date BETWEEN DATEADD(yy, - 1, @startDate)
            AND @startDate
    GROUP BY BS.database_name
        ,DATEDIFF(mm, @startDate, BS.backup_start_date)
    ) AS BCKSTAT
PIVOT(SUM(BCKSTAT.AvgSizeMB) FOR BCKSTAT.MonthsAgo IN (
            [0]
            ,[-1]
            ,[-2]
            ,[-3]
            ,[-4]
            ,[-5]
            ,[-6]
            ,[-7]
            ,[-8]
            ,[-9]
            ,[-10]
            ,[-11]
            ,[-12]
            )) AS PVT
ORDER BY PVT.DatabaseName;

乍得·米勒（Chad Miller）在SSC-数据库空间容量规划中出色地描述了另一种方法，您会发现它确实有用。他还重点介绍了days remaining非常有用的内容。

还有其他涉及数学计算的方法，这样可以得出准确的结果。如前所述，备份最好是指数据的增长，因为您说过需要计算和预测数据库的大小，Microsoft链接将帮助您

估计数据库大小

聚集索引的估计大小

估计堆大小

桌子的估计大小

希望这段代码对您有帮助：

根据备份大小历史记录（以MB为单位）工作，逐月给出最小MB，平均MB，最大MB以及与其他月份的差异（以MB为单位）。

列出所有带备份的数据库，系统数据库除外。

-- T-SQL script - Analyses database growth using backup information (Last (12) months in that case
-- Looks only to FULL backups information
-- Parameters: Date GetDate() and nr of months to analyse

SET NOCOUNT ON
DECLARE @endDate datetime, @months smallint; 
SET @endDate = GetDate();  -- Data atual
SET @months = 12;          -- Nr. de meses a analisar

;WITH HIST AS 
   (SELECT BS.database_name AS DatabaseName 
          ,YEAR(BS.backup_start_date) * 100 
           + MONTH(BS.backup_start_date) AS YearMonth 
          ,CONVERT(numeric(10, 1), MIN(BS.backup_size / 1048576.0)) AS MinSizeMB 
          ,CONVERT(numeric(10, 1), MAX(BS.backup_size / 1048576.0)) AS MaxSizeMB 
          ,CONVERT(numeric(10, 1), AVG(BS.backup_size / 1048576.0)) AS AvgSizeMB 
    FROM msdb.dbo.backupset as BS 
    WHERE NOT BS.database_name IN 
              ('master', 'msdb', 'model', 'tempdb') 
          AND BS.type = 'D' 
          AND BS.backup_start_date BETWEEN DATEADD(mm, - @months, @endDate) AND     @endDate 
    GROUP BY BS.database_name 
            ,YEAR(BS.backup_start_date) 
            ,MONTH(BS.backup_start_date)) 
SELECT @@SERVERNAME
      ,MAIN.DatabaseName 
      ,MAIN.YearMonth 
      ,MAIN.MinSizeMB 
      ,MAIN.MaxSizeMB 
      ,MAIN.AvgSizeMB 
      ,MAIN.AvgSizeMB  
       - (SELECT TOP 1 SUB.AvgSizeMB 
          FROM HIST AS SUB 
          WHERE SUB.DatabaseName = MAIN.DatabaseName 
                AND SUB.YearMonth < MAIN.YearMonth 
          ORDER BY SUB.YearMonth DESC) AS GrowthMB 
FROM HIST AS MAIN 
ORDER BY MAIN.DatabaseName 
        ,MAIN.YearMonth

我认为Brent Ozar的职位很明确。我参与了一个庞大的DB项目，遇到的问题与您在此处所做的完全一样，而且不是那么简单。

由于最好至少做一些事情-即使不是那么准确-我会设置所需的表和一个工作（或者您想要的任何其他方法，只是查询大小并将其可靠地存储在某个地方）以进行跟踪每周用于数据库及其所有表的行和空间，并以此来预测最可能的增长曲线。使用备份历史记录也是一个好主意。但是，无论采用哪种方法，您都需要时间来获取甚至远程可靠的数据。

除此之外，这实际上取决于您的情况。这可能是您数据库的使用率现在仅是未来六个月的一小部分，例如，当您的软件获得更大的发展时，就无法预测即将到来的爆炸性增长。可能每年都会有大量的数据传输，这会使数据库的大小增加一倍，但事实一经发现，您就只能发现该数量。

但是，正如所说的那样，如果要关注增长，那么您绝对应该做些事情来跟踪它。您想要做的最后一件事是，从现在起的6个月内，拥有一个数据库，其大小是其原始生命周期预测的两倍，不得不向您的客户解释这种情况的发生原因或原因，更不用说不得不开始猜测它会增长多少了。在接下来的6个月中。了解新数据的去向以及给定时间内每个表的相对增长情况还有一些非常明显的好处，因为它可以提供相对较少的工作量的有关不同趋势，潜在软件问题等的有价值的信息。 。