web-dev-qa-db-ja.com

データベース[.mdfファイル]が突然大きくなった原因

データベースのmdfを20 GBから100 GBに膨らませた原因を見つけようとしています。

これまでのところ、自動拡張イベントをチェックして時間を見つけようとしましたが、標準レポートやデフォルトのトレースファイルを使用しても何も見つかりませんでした。

再構築などのメンテナンスジョブやその他のプロセスが完了したかどうかを確認するためのサードパーティの監視ツールはありません。

このmdfの成長の原因を見つけるにはどうすればよいですか？

sql-serversql-server-2014auto-growth
3
BeginnerDBA

これにより、アクティブなシーケンスにあるすべてのエラーログファイル内のすべての自動拡張アクティビティが my answer here から見つかります。

DECLARE @path NVARCHAR(260);

SELECT 
   @path = REVERSE(SUBSTRING(REVERSE([path]), 
   CHARINDEX(CHAR(92), REVERSE([path])), 260)) + N'log.trc'
FROM    sys.traces
WHERE   is_default = 1;

SELECT 
   DatabaseName,
   HostName,
   ApplicationName,
   [FileName],
   SPID,
   Duration,
   StartTime,
   EndTime,
   FileType = CASE EventClass WHEN 92 THEN 'Data' ELSE 'Log' END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE EventClass IN (92,93)
-- AND DatabaseName = N'AdventureWorks'
ORDER BY StartTime DESC;

これで、疑わしいautogrowthイベントを識別したら、イベントを引き起こしたアプリケーション名やホスト名などの情報を確認できます。同じSPIDで他のアクティビティをキャプチャする可能性があるのは可能ですが、これに依存することはできません。任意のウィンドウ内で開始または終了したものを確認してください-これは、5分前と5分後を見て、上記で観察されたSPIDをハードコードします。

SELECT * FROM sys.fn_trace_gettable(@path, DEFAULT)
  WHERE StartTime >= DATEADD(MINUTE, -5, '2018-03-19 11:41:16.970')
    AND EndTime   <  DATEADD(MINUTE,  5, '2018-03-19 11:41:16.970')
    -- AND TextData IS NOT NULL
    AND SPID = 63;

1日あたり20個のエラーログファイルをロールスルーしている場合、何かが正しく構成されていないか、これらのログファイルでいっぱいになっている何かを実行しすぎていますノイズ。私見では。

6
Aaron Bertrand

whyを質問する前に、whatを質問する必要があります。

まず、次のようなクエリを実行して、現在のデータベースの各データ/ログファイルの使用済み/空き容量を確認します。

SELECT  dbname = DB_NAME(),
        filetype = type_desc,
        logical_name = name, 
        TotalMB = CONVERT(decimal(12,1),size/128.0),
        UsedMB = CONVERT(decimal(12,1),FILEPROPERTY(name,'SpaceUsed')/128.0),
        FreeMB = CONVERT(decimal(12,1),(size - FILEPROPERTY(name,'SpaceUsed'))/128.0),
        MaxSizeMB = CASE WHEN max_size = -1 THEN NULL 
            ELSE CONVERT(DECIMAL(18, 1), max_size / 128.0) END,
        GrowthRate=CASE WHEN is_percent_growth = 1 THEN CONVERT(varchar(12),growth)+'%'
                WHEN growth = 0 THEN 'FIXED'
                ELSE CONVERT(varchar(12), growth/128) + 'MB' END,
        physical_name
 FROM sys.database_files WITH (NOLOCK)
 ORDER BY type, file_id;

100GBファイルは実際にいっぱいですか？それともそれはほとんど空のスペースですか？

空の場合は、空スペースの一部を回復するための計画を立てることができます 縮小に関するすべての適切な注意事項 。

それがいっぱいの場合は、次のようなクエリを使用して、すべてのスペースを使用しているテーブルを確認します。

SELECT s.Name AS SchemaName,
    t.NAME AS TableName,
    max(p.rows) AS [RowCount],
    CONVERT(decimal(12,1),SUM(a.total_pages)/128.0) AS TotalSpaceMB, 
    CONVERT(decimal(12,1),SUM(a. used_pages)/128.0) AS UsedSpaceMB
FROM            sys.tables t
INNER JOIN  sys.indexes i ON t.OBJECT_ID = i.object_id
INNER JOIN  sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id
INNER JOIN  sys.allocation_units a ON p.partition_id = a.container_id
LEFT OUTER JOIN  sys.schemas s ON t.schema_id = s.schema_id
WHERE t.NAME NOT LIKE 'dt%' 
  AND t.is_ms_shipped = 0
  AND i.OBJECT_ID > 255 
GROUP BY t.Name, s.Name
ORDER BY 4 DESC

成長したテーブルがわかっている場合は、それが原因である可能性のあるプロセスに戻るはずです。

3
BradC