web-dev-qa-db-ja.com

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

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

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

sql-serversql-server-2008size
10
Diego Flores

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

私が目指しているのは何時ですか？あなたのケースでは、12か月の数字を探しています。

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

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

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

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

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

開発者またはDBAはインデックスをパフォーマンスチューニングしますか？ユーザーがインデックスを作成できるようにする場合、取得する熱量に応じて、データのサイズを簡単に2倍（または3倍、4倍）にすることができます。

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

21
Brent Ozar

以前の成長の履歴がなければ、将来の成長を正確に予測することはできません。ただし、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]);
14
Mark Storey-Smith

データベースの容量計画を行う方法はたくさんあります。

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;

SSCのチャドミラー-データベーススペースキャパシティプランニング で詳しく説明されているように、実際に役立つ別の方法があります。彼はまた、days remaining非常に便利です。

1
Kin Shah

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

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

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

ヒープの推定サイズ

テーブルの推定サイズ

1
Shanky

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

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

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

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

それ以外は、本当にあなたの状況に依存します。現在のDBの使用率は、次の6か月のほんの一部にすぎない可能性があります。たとえば、ソフトウェアがより多くの地位を獲得し、今後の爆発的な成長を予測できなくなった場合などです。毎年、DBのサイズが2倍になる大量のデータ転送があるかもしれませんが、その大容量について知ることができるのは、実際になってからです。

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

0
Kahn