web-dev-qa-db-ja.com

単純な復旧モデルを使用しているデータベースに、非常に大きなトランザクションログがあるのはなぜですか。

以下と重複していません：

理由：ログは大きくありませんが、空です。大きいですが使用中です。

問題

小さなデータベース（100 MB）があり、1日を通して多くの小さなトランザクションワークロードが発生します。トランザクションログの上限を理解しているように見えますが、トランザクションログが増加し続けるのを見てきました。明らかに何かが欠けています。

  • データベースは単純な復旧モデルです（最初に作成されたときに、ある時点でデータベースがフル状態でなかったことは保証できませんが、フル状態でロードされたことは一度もありません）。

  • DBCC SQLPERF(Logspace)さんのコメント：

| Log Size (MB) | Log Space Used (%) | Status
--------------------------------------------
| 927.2422      | 94.72562           | 0
  • DBCC LOGINFOさんのコメント：

39行（VLF）があり、そのすべてにStatusの2があります。

  • DBCC opentranさんのコメント：

最も古いアクティブなトランザクション：
SPID：51
名前：user_transaction
開始時間：2019年3月11日19:27

注：サーバーの時間を考えると、このトランザクションは約5分前のものです。

非常に頻繁ではあるが、アプリケーションが作成するのが最大で約6ダースの短期トランザクションであるときに、すべてのVLF=が使用されている理由がわかりません。

このデータベースに接続する唯一のアプリケーションプロセスを強制終了しようとしましたが、トランザクションログが解放されませんでした。

Workaround

私はそのかゆみをひっくり返すためだけにフルバックアップを行い、それによってログスペース全体が解放されました...それで...それが再び過度に成長するかどうかを確認する必要があります。

sql-servertransaction-logsql-server-2017recovery-model
2
Jesse Hallam

このような問題の最初のストップは、常にこのクエリである必要があります。

SELECT log_reuse_wait, log_reuse_wait_desc
FROM sys.databases 
WHERE [name] = 'YourDatabaseName';

sys.databases ドキュメントから：

トランザクションログスペースの再利用は、最後のチェックポイントの時点で、次のいずれかで現在待機しています。

そのページには、可能な値のリストと、さまざまな値のかなりの詳細がここにあります。 トランザクションログ（SQL Server ログの切り捨てを遅延させる可能性がある要因）-

サーバーがあまりビジーでない場合は、自動CHECKPOINTが実行されてからしばらく時間が経過していない可能性があります。これは、データページがメモリ内で変更された後に、ディスクにデータページを書き込むプロセスです。トランザクションログ内の操作は、データファイルに正常にフラッシュされるまで上書きできないため、log_reuse_waitが1 = Checkpointになってしまいます。

単純な復旧モデルを使用しているため、これは最も可能性の高い原因の1つに思われます（長時間実行のトランザクションを除外したため）。データベース全体のバックアップを実行すると、CHECKPOINTが実行されます。これにより、バックアップの実行後にログファイルが最終的に消去された可能性があります。 From Database Checkpoints（SQL Server） 、特に「内部」チェックポイントタイプについて：

ディスクイメージがログの現在の状態と一致することを保証するためのバックアップやデータベーススナップショットの作成など、さまざまなサーバー操作によって発行されます。

5
Josh Darnell