なぜ毎晩バックアップするシンプルリカバリモードでトランザクションログが増大し続けるのか

すぐに重複としてマークする前に、Mike Walshの「なぜトランザクションログが増え続けるか、スペースが足りないのですか？」を読みました。、しかし、それが私の状況に答えを与えたとは思わない。私は十数個の同様の質問に目を通しましたが、関連する質問のほとんどは「重複」と言って、マイクの質問を指しています。

詳細：SQL Server 2008 R2には約500MBのデータベースがあり、すべてSIMPLEリカバリモード（選択ではありません）、夜間フルバックアップ、最大200MBのデータファイル、および約300MBのログファイルがあります。ログはすぐに300MBに拡大するのではなく、数か月かけてゆっくりと拡大します。少なくともsp_who2とアクティビティモニターによれば、それらのいずれにもオープントランザクションはありません。データベースを右クリックしてプロパティを選択すると、最大50MBの空きがあることがわかります。特にバックアップ直後は、ログ全体を解放すべきではありませんか？SIMPLEモードでは、開いているトランザクションがない限り、ログは解放されませんか？

log_reuse_wait_descfrom sys.databasesは「NOTHING」と言っており、上記の質問と回答に基づいて、スペースを再利用するために何も待つべきではないことを示しています。

「DBCC SHRINKFILE」を実行すると、ログファイルが1MBに縮小されるため、スペースを再利用できます。毎週ログを圧縮し、制御不能にならないように設定することはできますが、SQL Serverがそれを行う理由について混乱しています。

ログに300MBを必要とするクレイジーなトランザクションがあったかどうかはわかりますが、極端なことはしていません。基本的なOLTPだけです。マイクの質問/回答から：

単純復旧モデル-したがって、上記の概要では、最初に単純復旧モデルについて説明するのが最も簡単です。このモデルでは、SQL Serverに通知しています-クラッシュと回復の再開にトランザクションログファイルを使用しても問題ありません（実際には選択の余地はありません。ACIDプロパティを検索し、すぐに意味をなすはずです）。クラッシュ/リスタートリカバリの目的でこれが必要になったら、ログファイルを再利用してください。

SQL Serverは、シンプルリカバリでこのリクエストをリッスンし、クラッシュ/リカバリの再開に必要な情報のみを保持します。データがデータファイルに（多少なりとも）強化されているためにSQL Serverが回復できることが確認されると、強化されたデータはログに不要になり、切り捨てのマークが付けられます。つまり、再利用されます。

ログスペースを再利用する必要があると言われ続けていますが、数か月にわたるこの緩やかな成長により、そうではないようです。

私は何が欠けていますか？SQL Serverがデータを「強化された」ものとして認識し、ログを解放できないようにしているのでしょうか？

（編集） アフターアクションレポート-ちょっとした知識は危険です

これが「一般的な質問」であることがわかった後、7か月前に何が起こったのか、他の人々に悲しみを救うために学んだことを説明する義務があると感じました。

まず、データベースのプロパティを表示したときにSSMSに表示される使用可能な領域は、データファイルで使用可能な領域です。これを表示するには、データベースで次のコマンドを実行します。SSMSによって報告される使用可能な領域は、FileSizeMBとUsedSpaceMBの違いです。

SELECT
    DB.name,
    MF.physical_name,
    MF.type_desc AS FileType,
    MF.size * 8 / 1024 AS FileSizeMB,
    fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB,
    mf.name LogicalName
FROM
    sys.master_files MF
    JOIN sys.databases DB ON DB.database_id = MF.database_id
WHERE   DB.name = 'yourdatabasename'

これにより、通常の状況ではログ領域がほとんど使用されていないこと（20MB以下）が確認されましたが、これは2番目の項目につながります...

第二に、ログの成長に対する私の認識は、時間の経過とともにゆっくりと認識されていました。しかし、実際には、このサードパーティアプリケーションのパッチを適用する担当者がパッチを適用していた夜、ログは急速に成長していました。パッチは単一のトランザクションとして実行されたため、パッチによっては200MBのデータに300MBのログが必要でした。その追跡のキーは、https：//sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-traceの Aaron Bertrandからのクエリでした。

DECLARE @path NVARCHAR(260);

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

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

これは、顧客がデータベースを使用していなかった特定の夜にログが増大していることを示していました。その結果、パッチを適用する男との会話とミステリーへの答えに至りました。

答えを教えてくれた人々に再び感謝します。

原因を推測することはできませんが、SQL Serverは単にログファイルを300 MBに増やすだけでなく、最後の縮小操作からのある時点で、それを必要としたため、300 MBに増えます多くのログ領域（大きな単一のトランザクションまたは多数の小さな同時トランザクションが原因）。ログファイルの増加イベントをトレースする必要があります（これについては、ここでここで説明しました）。これが発生するタイミングまたは理由を絞り込みます（ログファイルの増加設定が300 MBかそれ以上の場合は、300 MB増加します）アクティブなトランザクションに対応するために1 MB以上のスペースが必要になるとすぐに）。

とにかく、ログファイルが300 MBに達したら、なぜ縮小する必要があると思いますか？マイクの質問について、実際にすべての答えを徹底的に読みましたか？ログファイルは1 MBに縮小するので、それ自体では縮小しません-最大のトランザクション中に再び拡大できるため、時間の無駄です。その間にすべての空きスペースをどうするつもりですか？

あなたの現在のテストの全ては（DBCC SHRINKFILE、log_reuse_wait_desc）単に右のことを証明している今、あなたは適切なトランザクションログの仮想ログファイルを再利用しています。ただし、トランザクションログファイルで自動成長イベントが発生すると、ログを再利用できないという反応になります。

多くの場合、それは継続的な状態ではありません（現在表示されている症状がなく、まさに今の状態です）。単純な復旧モデルであっても、この動作を引き起こす可能性のあるものがいくつかあります。

あなたの最善の策は、データ収集ジョブをセットアップしlog_reuse_wait_descて、データベースを定期的にプルし、これをどこかに定期的に記録することです。その後、ログの再利用の不足の原因をリバースエンジニアリングできるようになります。

ログスペースを再利用する必要があると言われ続けていますが、数か月にわたるこの緩やかな成長により、そうではないようです。

上記で示したように、通常はトランザクションログの再利用の不足を引き起こす継続的な状態ではないため（不完全に構築されたトランザクションなど、いくつかのコーナーケースを保存します）、これが発生している時間を特定する必要があります。軽量の診断データの収集は、良い出発点です。

DBで自動圧縮が有効になっていますか？および/または、インデックスの再構築を実行する定期メンテナンス計画がありますか？

自動縮小とそれに続くインデックスメンテナンスにより、大量のログが生成されます。

GUIDのクラスター化インデックスのようなDB設計の問題がある場合、インデックスのメンテナンス自体もかなりのログボリュームを生成します。

 create table #dblog (Databasename varchar(100),
                     logsize float,
                     logspace%] float,
                     [Status] int)

 insert into #dblog
 EXEC ('DBCC sqlperf(logspace)') 

 select * from #dblog

 alter table #dblog 
 add [lgspace used GB] float;

 update #dblog 
 set [lgspace used GB ] = (logsize*[logspace%]/1024)

 update #dblog 
 set [logsize] =([logsize]/1024)

 alter table #dblog 
 drop column [Status];

 select * from #dblog

 drop table #dblog