web-dev-qa-db-ja.com

トランザクションログが夜間バックアップのシンプルリカバリモードで増加し続ける理由

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

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

log_reuse_wait_descから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のログが必要でした。そのダウンを追跡する鍵は、 にあるAaron Bertrandからのクエリでしたhttps://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace

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-serversql-server-2008-r2transaction-log
24
DerekCate

原因を推測することは不可能ですが、SQL Serverはログファイルを300 MBに拡大するだけでなく、300 MBに拡大します。これは、前回の縮小操作以降のある時点で、大きなログスペース（大きな単一トランザクションによるものか、多数の小さな同時トランザクションによるものか）。ログファイルの増加イベントを追跡する必要があります（これについて here と here について説明しました）。これが発生するタイミングまたは理由を絞り込むために（ファイルの増加をログに記録する場合も）設定は300 MB程度で、アクティブなトランザクションに対応するために1 MBを超えるスペースが必要になるとすぐに300 MB増加します。

とにかく、なぜ300 MBに達したらログファイルを圧縮する必要があると思いますか。 Mikeの質問 で、実際にすべての回答を完全に読みましたか？ログファイルを1MBに縮小することは、最大のトランザクション中に再び大きくなる可能性があるため、それ自体では時間の無駄です。それまでの間、その空き領域をすべてどうするつもりですか？

20
Aaron Bertrand

現在のすべてのテスト（DBCC SHRINKFILE、log_reuse_wait_desc）は、トランザクションログの仮想ログファイルを適切に再利用しているnowことを証明しているだけです。ただし、トランザクションログファイルで自動拡張イベントが発生した場合、それはログを再利用できないという反応です。

多くの場合、そのは進行中の状態ではありません（実際には、現在見られている症状がないため、現在の状態は正確にどのように見えますか）。単純な復旧モデルであっても、この動作を引き起こす可能性があるものはいくつかあります。

あなたの最善の策は、定期的にlog_reuse_wait_descをデータベースに追加し、どこかに定期的に記録します。次に、ログの再利用の欠如を引き起こしているものをリバースエンジニアリングできるはずです。

ログスペースは再利用する必要があると言い続けていますが、数か月にわたってこのゆっくりとした増加で、そうではないようです。

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

6
Thomas Stringer

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

自動縮小の後にインデックスのメンテナンスを行うと、大量のログが生成されます。

GUIDのクラスター化インデックスのようなDB設計の問題がある場合は、インデックスのメンテナンスだけでも、大量のログが生成されます。

0
Pete