予測されるデータベースの増加を見積もる

私は最近、DBA研修生としてSQL Server 2008を使い始めました。データベースのサイズを計算する必要がありますが、最近の数か月間のデータベースの成長と、今後12か月の予測される成長も予測します。

sp_spaceusedステートメントを使用して実際のサイズを計算できますが、他のすべてをどのように計算しますか？

他の答えは技術的には正しいですが、実際には正しくありません。ビジネスに尋ねる必要があるものは次のとおりです。

何時を目指していますか？あなたの場合、あなたは12ヶ月の数字を探しています。

その間、データをアーカイブしますか、それともすべてのデータを保持しますか？一部のビジネスでは、過去12か月など、特定の量のデータのみを保持することが許可されています（または必要とされています）。その場合は、データの増加を把握する必要があります（その後の質問で回答されます）が、最後の12か月までさかのぼります。「今のところ、そのデータ量は100GBです」と言ってはいけません。データ量が増えると、過去12か月も増えるからです。時間量は一定である可能性がありますが、データは一定ではありません。

ユーザーを追加しますか？たとえば、ビジネスが新しい領域に成長したり、新しい顧客を獲得したりする場合があります。ユーザーが2倍になると、場合によっては、データも倍増し始めます。

取引量は増えると思いますか？たとえば、Webサイトで売上を追跡していて、スーパーボウルやワールドカップの広告を掲載し始めた場合、データ量はホッケースティックの成長曲線に達する可能性があります。

アプリに機能を追加しますか？アプリが突然画像の保存を開始すると、データベースのサイズに劇的な影響を与えます。

別のソースからデータを追加するか、新しいデータをログに記録しますか？Webサイトのクリックのキャプチャを開始するか、データウェアハウスでソースを追加すると、データ量が増大します。

開発者またはDBAはパフォーマンスチューニングインデックスになりますか？インデックスの作成を許可する場合は、取得する負荷の大きさに応じて、データのサイズを簡単に2倍（または3倍、4倍）にすることができます。

また、これらの質問をしている間は、パフォーマンスが変わらない、低下する、または改善することが期待されるかどうかも確認する必要があります。予測される成長を折れ線グラフで描き、ハードウェアとスタッフのトレーニングへの投資を同じタイムラインで比較するのが好きです。

以前の成長の履歴がないと、将来の成長を正確に予測することはできません。ただし、Erin StellatoがTrending Database Growth From Backupsで詳細を説明しているように、バックアップ履歴を使用して不正な操作を行って大まかなトレンドを取得できます。

次のクエリの出力を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どれが非常に役立つかに焦点を当てています。

数学的な計算を含む他の方法があり、これは正確な結果を与えます。マイクロソフトのリンクの下でデータベースのサイズを計算して予測する必要があると言ったので、すでに指摘したバックアップはデータの増加を参照するのに最適です。

データベースの推定サイズ

クラスター化インデックスのサイズの推定

ヒープの推定サイズ

テーブルの推定サイズ

このコードが役立つことを願っています：

バックアップサイズの履歴（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

ブレント・オザールの投稿は定評があると思います。私は大規模に膨れ上がっているDBプロジェクトに参加していて、ここで行うのとまったく同じ問題がありましたが、それはそれほど単純ではありません。

少なくとも何かをする方が良いので-実際にはそれほど正確ではありませんが-追跡するために、必要なテーブルとジョブ（または、必要な他の方法、サイズをクエリしてどこかに確実に保存するためのもの）をセットアップします週ごとにDBとそのすべてのテーブルに使用される行とスペースを使用して、最も可能性の高い成長曲線を予測します。バックアップ履歴を使用することも素晴らしいアイデアです。しかし、方法に関係なく、リモートで信頼できるデータを取得するためにも時間が必要です。

それ以外、それは本当にあなたの状況に依存します。現在のDBの使用率は、次の6か月の数分の1にすぎない可能性があります。たとえば、ソフトウェアの基盤が拡大し、爆発的な成長が予測できなくなった場合などです。毎年、DBのサイズを2倍にする大量のデータ転送があるかもしれませんが、その量については、事後に知るだけです。

しかし、前述のように、成長が懸念される場合は、それを追跡するために絶対に何かを行う必要があります。最後に、6か月後に、DBを元の寿命の予測の2倍の規模で見つけ、それがどのようにまたはなぜ起こったかを顧客に説明する必要があります。さらに、それがどれだけ大きくなるかを推測し始める必要はありません。次の6ヶ月で。また、比較的小さな労力でさまざまな傾向、潜在的なソフトウェアの問題などに関する貴重な情報を提供できるため、新しいデータがどこに移動したか、および特定の時間内の各テーブルの相対的な成長は何かを知ることの非常に明らかな利点もあります。 。