短い答え：
おそらく、長時間実行されているトランザクションが実行されているか（インデックスのメンテナンス？バッチの大規模な削除または更新？）、または「デフォルト」（デフォルトの意味については以下を参照）リカバリモードでFullあり、ログバックアップを取得していない（またはそれらを十分に頻繁に服用していない）。
復旧モデルの問題であるSimple場合、ポイントインタイムリカバリと定期的なログバックアップが不要な場合、簡単な答えは復旧モードに切り替えることです。ただし、多くの人々は、回復モデルを理解せずにその答えを出します。読み続けて、なぜそれが重要なのかを理解してから、あなたが何をするかを決定します。また、ログバックアップの取得を開始し、Full回復状態を維持することもできます。
他の理由もありますが、これらが最も一般的です。この回答では、最も一般的な2つの理由を詳しく説明し、その理由とその背後にある背景情報を提供するとともに、その他の理由についても説明します。
より長い回答：
ログが成長し続ける原因となるシナリオは何ですか？多くの理由がありますが、通常、これらの理由は次の2つのパターンにあります。復旧モデルについての誤解があるか、長時間実行されているトランザクションがあります。詳細をお読みください。
一番の理由1/2：復旧モデルを理解していない
（にいる完全復旧モードと取っていないログのバックアップを -これは、最も一般的な理由である-この問題が発生して、それらの大半があります。）
この回答はSQL Server復旧モデルの詳細な説明ではありませんが、復旧モデルのトピックはこの問題にとって重要です。
SQL Serverには、次の3つの復旧モデルがあります。
Full、Bulk-Logged そして Simple。
今は無視Bulk-Loggedしますが、これはハイブリッドモデルであり、このモデルを使用しているほとんどの人は理由があり、復旧モデルを理解しています。
我々は気に2とその混乱は、この問題を持つ人々の例大半の原因であるSimpleとFull。
休憩：一般的な回復
復旧モデルについて説明する前に、一般的な復旧について説明しましょう。このトピックをさらに詳しく知りたい場合は、Paul Randalのブログを読んでください。ただし、この質問については：
クラッシュ/リスタートリカバリ
トランザクションログファイルの目的の1つは、クラッシュ/リスタートリカバリです。クラッシュまたは再起動の前に行われた作業（ロールフォワード/リドゥ）と、クラッシュまたは再起動後に開始されたが終了していない作業（ロールバック/アンドゥ）のロールフォワードおよびロールバック用。トランザクションが開始されたが終了していない（トランザクションがコミットされる前にロールバックまたはクラッシュ/再起動が発生した）ことを確認するのは、トランザクションログの仕事です。そのような状況では、回復中に「ちょっと、これは本当に終わったことはありません。ロールバックしましょう」と言うのはログの仕事です。また、あなたが何かを完了し、クライアントアプリケーションが完了したと言われたことを確認するのはログの仕事です（たとえデータファイルにまだ固まっていないとしても）「ねえ、これは本当に起こった、それを前に進めましょう、アプリケーションがそれがあったと思うようにしましょう」再起動後。今はもっとありますが、それが主な目的です。
タイムリカバリでのポイントは、
トランザクション・ログ・ファイルの他の目的は、私たちに回復する能力を与えることができるようにすることです時点の原因に「おっと」データベース内またはハードウェア障害時のリカバリポイントを保証しますデータベースのデータおよび/またはログファイルが含まれます。このトランザクションログに、回復のために開始および終了したトランザクションの記録が含まれている場合、SQL Serverはこの情報を使用して、問題が発生する前の場所にデータベースを取得します。しかし、それは常に利用可能なオプションではありません。そのためには、適切な復旧モデルでデータベースを使用する必要があり、ログのバックアップを作成する必要があります。
復旧モデル
復旧モデルについて：
単純な復旧モデル
したがって、上記の概要では、Simple Recovery最初にモデルについて説明するのが最も簡単です。このモデルでは、SQL Serverを言っている：「私はあなたがクラッシュし、再起動回復のためのあなたのトランザクション・ログ・ファイルを使用してと元気です...」（あなたは本当にそこに選択肢がない検索します。ACID特性を、それはすぐに意味をなす必要があります。）「...しかし、クラッシュ/リスタートリカバリの目的で不要になったら、ログファイルを再利用してください。」
SQL Serverは、シンプルリカバリでこのリクエストをリッスンし、クラッシュ/リカバリの再開に必要な情報のみを保持します。データがデータファイルに強化されているため（多かれ少なかれ）SQL Serverが回復できることが確認されると、強化されたデータはログに不要になり、切り捨てのマークが付けられます。つまり、再利用されます。
完全復旧モデル
ではFull Recovery、あなたがいる限り、あなたのログファイルが利用できるか、ログのバックアップによって覆われている、ある特定の時点にあるように、特定の時点に復元することができるようにしたいSQL Serverを語っています。この場合、SQL Serverが単純復旧モデルでログファイルを切り捨てても安全な時点に達すると、それは行われません。代わりに、通常の状況下でログのバックアップをとる（またはログファイルドライブのスペースがなくなる）まで、ログファイルは成長し続け、成長を続けることができます。
シンプルからフルに切り替えるには、落とし穴があります。
ここにはルールと例外があります。長時間実行されるトランザクションについては、以下で詳しく説明します。
ただし、完全復旧モードの注意点は次のとおりです。Full Recoveryモードに切り替えただけで、最初の完全バックアップを実行しない場合、SQL ServerはFull Recoveryモデルへの参加要求を受け入れません。トランザクションログはSimple、完全復旧モデルに切り替えて最初のを取得するまで、引き続き動作しますFull Backup。
ログバックアップなしの完全復旧モデルは不適切です。
それで、それが制御されないログの成長の最も一般的な理由ですか？回答：ログのバックアップなしで完全復旧モードになっています。
これは常に人々に起こります。
なぜこれはよくある間違いですか？
なぜそれが常に起こるのですか？新しいデータベースはそれぞれ、モデルデータベースを見ることで初期復旧モデル設定を取得するためです。
モデルの初期復旧モデル設定は常にですFull Recovery Model-誰かがそれを変更するまで、そして変更しない限り。したがって、「デフォルトの復旧モデル」はと言うことができますFull。多くの人はこれを認識しFull Recovery Modelていないため、ログバックアップなしでデータベースを実行しているため、トランザクションログファイルは必要以上に大きくなります。これが、組織とそのニーズに合わない場合にデフォルトを変更することが重要である理由です）
ログバックアップが少なすぎる完全復旧モデルは不適切です。
また、ログのバックアップを十分に取らないことにより、ここでトラブルに巻き込まれることもあります。
1日にログバックアップをとることは正常に思えるかもしれませんが、リストアに必要なリストアコマンドが少なくなりますが、上記の説明に留意してください。
必要なログバックアップ頻度を確認するにはどうすればよいですか？
次の2つの点に留意して、ログのバックアップ頻度を検討する必要があります。
- 回復の必要性 -これが最初になることを願っています。トランザクションログを格納しているドライブが故障した場合、またはログバックアップに影響する重大な破損が発生した場合、どのくらいのデータが失われる可能性がありますか？その数が10〜15分を超えない場合、10〜15分ごとにログバックアップを取得する必要があります。これで説明は終わりです。
- ログの増加 -その日に簡単に再作成できるために組織がより多くのデータを失うことに問題がない場合、ログバックアップを15分よりはるかに少ない頻度で行うことができます。たぶん、あなたの組織は4時間ごとに大丈夫でしょう。ただし、4時間で生成されるトランザクションの数を確認する必要があります。この4時間でログが大きくなり続けると、ログファイルが大きくなりすぎますか？ログのバックアップに時間がかかりすぎるということですか？
一番の理由2/2：長時間実行トランザクション
（「私の復旧モデルは問題ありません！ログはまだ増え続けています！）
これは、制御されない、制限されないログの増加の原因にもなります。復旧モデルに関係なく、「しかし、私は単純復旧モデルにいる-なぜ私のログがまだ成長しているのか！」
ここでの理由は簡単です。上記で説明したように、SQLがこのトランザクションログを回復目的で使用している場合、トランザクションの開始までさかのぼる必要があります。
時間がかかるトランザクションや多くの変更を行うトランザクションがある場合、ログは、まだ開いているトランザクションにあるか、そのトランザクションが開始されてから開始された変更のチェックポイントで切り捨てることができません。
これは、1つの削除ステートメントで数百万行を削除する大きな削除は1つのトランザクションであり、その削除がすべて完了するまでログは切り捨てられないことを意味します。ではFull Recovery Model、この削除がログに記録されるため、大量のログレコードになる可能性があります。メンテナンス時間中にインデックスの最適化が機能するのと同じこと。また、トランザクション管理が不十分であり、開いているトランザクションを監視および終了しないと、ユーザーとログファイルに大きな損害を与える可能性があることも意味します。
これらの長期実行トランザクションについて何ができますか？
ここで自分を救うことができます：
- メンテナンスや既知の大規模な操作などの最悪のシナリオを考慮して、ログファイルのサイズを適切に設定します。ログファイルを大きくする場合は、Kimberly Trippによるこのガイダンス（および彼女が送信する2つのリンク）を参照してください。ここでは、適切なサイジングが非常に重要です。
- トランザクションの使用状況を監視します。アプリケーションサーバーでトランザクションを開始し、SQL Serverとの長い会話を開始しないでください。
- DMLステートメントで暗黙のトランザクションを監視します。例：
UPDATE TableName Set Col1 = 'New Value'はトランザクションです。私はBEGIN TRANそこに入れませんでしたし、する必要はありません。それはまだ完了したら自動的にコミットする1つのトランザクションです。したがって、多数の行で操作を行う場合は、それらの操作をより管理しやすいチャンクにまとめて、ログに回復する時間を与えることを検討してください。または、それに対処する適切なサイズを検討してください。または、バルクロードウィンドウ中に変化する復旧モデルを調べることもできます。
これら2つの理由はログシッピングにも当てはまりますか？
簡単な答え：はい。以下の長い回答。
質問：「ログシッピングを使用しているため、ログバックアップが自動化されています。なぜトランザクションログの増加が見られるのですか？」
答え：読んでください。
ログ配布とは何ですか？
ログ配布は、その名のとおりです-DRの目的で、トランザクションログのバックアップを別のサーバーに配布しています。いくつかの初期化がありますが、その後のプロセスは非常に簡単です：
- 1つのサーバーでログをバックアップするジョブ、
- そのログバックアップをコピーするジョブ
- 宛先サーバーで（
NORECOVERYまたはのいずれかSTANDBY）リカバリーせずに復元するジョブ。
計画どおりに動作しない場合は、監視して警告するジョブもあります。
場合によっては、ログシッピングの復元を1日1回、3日ごと、または1週間に1回だけ行うことができます。それは結構です。ただし、すべてのジョブ（ログバックアップおよびコピージョブを含む）でこの変更を行うと、ログバックアップを取得するためにずっと待機していることになります。つまり、ログバックアップなしで完全復旧モードになっているため、ログが大幅に増加することになります。また、コピーする大きなログファイルも意味する可能性があります。復元ジョブのスケジュールを変更し、ログのバックアップとコピーをより頻繁に行うようにしてください。そうしないと、この回答で説明されている最初の問題が発生します。
ステータスコードによる一般的なトラブルシューティング
これら2つ以外の理由がありますが、これらは最も一般的です。原因に関係なく、この原因不明のログの増加/切り捨ての不足の理由を分析し、それらが何であるかを確認する方法があります。
sys.databasesカタログビューを照会すると、ログファイルが切り捨て/再利用を待機している理由を説明する情報を表示できます。
log_reuse_wait理由コードのルックアップIDで呼び出される列とlog_reuse_wait_desc、待機理由の説明がある列があります。参照されている書籍のオンライン記事からは、理由の大部分（表示される可能性が高いものと理由を説明できるものがあります。不足しているものは使用されないか、内部使用されます）斜体：
0 =
何も聞こえない..待つべきではない
1 =チェックポイントチェックポイントの
発生を待機しています。これは起こるはずであり、あなたは大丈夫であるはずです-しかし、後で答えや編集のためにここを探すいくつかのケースがあります。
2 =ログバックアップ
ログバックアップが発生するのを待っています。それらをスケジュールしてすぐに発生するか、ここで説明した最初の問題があり、それを修正する方法を知っている
3 =アクティブなバックアップまたは復元
バックアップまたは復元操作がデータベースで実行されています
4 =アクティブトランザクションログをバックアップする前に
（いずれかの方法で- ROLLBACKまたはCOMMIT）完了する必要があるアクティブトランザクションがあります。これが、この回答で説明されている2番目の理由です。
5 =データベースミラーリング
高性能ミラーリングの状況でミラーが遅れているか、ある程度の待ち時間がかかっているか、何らかの理由でミラーリングが一時停止している
6 =レプリケーション
これを引き起こすレプリケーションの問題が発生する可能性があります-ログリーダーエージェントが実行されていない、データベースがレプリケーション用にマークされていると判断したなど、さまざまな理由があります。この理由も確認できます。トランザクションがログリーダーによって消費されているように、適切なタイミングを確認しているので、まったく正常です。
7 =データベーススナップショットの作成データベーススナップショットを作成しています。スナップショットの作成中に
適切な瞬間を見ると、これが表示されます。
8 =ログスキャン
私は、これが永久に実行される問題にまだ遭遇していません。十分に長く頻繁に見ると、これが起こるのを見ることができますが、それは私が見た過度のトランザクションログの成長の原因ではないはずです。
9 = AlwaysOn可用性グループのセカンダリレプリカは、このデータベースのトランザクションログレコードを対応するセカンダリデータベースに適用しています。
まだ最も明確な説明について..
