完全復旧モードでログファイルを圧縮できない理由
302MBのログファイルがあります。
ログファイルをほとんど解放したログバックアップを実行しました（これは、Disk Usage標準レポートで確認できます）
走ろうとすると
DBCC SHRINKFILE (N'AdventureWorks2014_Log' , 0, TRUNCATEONLY)
または
DBCC SHRINKFILE (N'AdventureWorks2014_Log' , 0)
ファイルはまだ302MBと表示されています。
データベースを単純復旧に変更してから、上記のコマンドの1つを実行して完全復旧に戻すことができることを知っています（次に、完全バックアップを実行して、データベースが 疑似単純復旧モードになっていないことを確認します =）
しかし、なぜ完全復旧モードでファイルを圧縮できないのですか？
縮小はあなたがすべきことではないことを知っていますが、私の実際のデータベースでは、誰もトランザクションログをバックアップしたことがないため、30 GBまで成長し、このレベルの成長を防ぐために定期的なログバックアップが導入されました。
しかし、なぜ完全復旧モードでファイルを圧縮できないのですか？
設計どおりに機能しています。何が起こっているのかをもっと理解する必要があるだけなので、どれが適切なアクションであるかを決定できます。
それ、またはあなたは間違った時にそれを縮小しようとしているだけです（以下の私のノート＃7を参照してください）。
まず第一に、「ログファイル」は少し誤った名称です：SQLは、トランザクションログをそのすべての「作業領域」として使用するため、常に非サイズがゼロです。私の経験では、使用しているリカバリモードとデータベースでのアクティビティの種類に応じて、通常、トランログはデータファイルのサイズの10％から25％になると予想しています。データファイルのサイズについては触れなかったので、302MBが大きいかどうか判断できません（正直言って、私にはそれほど大きく聞こえません）。
リカバリモードに関して、ここで重要な質問は次のとおりです。（緊急時に）データベースをリカバリする必要がある場合、「ポイントインタイム」リカバリが必要ですか？または、最新の完全バックアップへの復元で十分ですか？
いくつかの異常な状況（レプリケーション/ CDC /ミラーリング/可用性グループ）は別として、リカバリーモードの選択は、技術的な決定よりもビジネス上の決定に近いものです。どちらのモードでも、SQLサーバーはインプロセストランザクションにトランザクションログを使用します。違いは次のようになります。
- 完全復旧モード：トランザクションが完了すると、トランザクションを実行するまで、トランザクションがtranログに残ります。トランザクションログのバックアップ。これにより、ログが大きくなる傾向があります（ログバックアップを実行する頻度によって異なります）が、災害発生時に「ポイントインタイム」リカバリを実行できることを意味します。最新の完全バックアップを復元して、災害が発生する直前に「ロールフォワード」するためのトランログバックアップ。
- SIMPLEリカバリモード：トランザクションが完了すると、トランザクションログで使用されていたスペースは、後のトランザクションですぐに再利用できます。これにより、トランザクションログファイルは（比較的）小さく保たれますが、災害発生時に選択できるのは、最新の完全バックアップから復元することだけです。
一部の企業では、すべての本番データベースにFULLを使用し、すべてのQA/DEV環境にSIMPLEを使用します。あるいは、レポートやデータ処理に使用されるような特定のデータベースでは、前日の処理を再実行して最新の状態に戻すことができるため、完全なリカバリは必要ありません。しかし、私が言ったように、それはビジネスの意思決定/リスク分析の問題であり、実際には技術的な問題ではありません。
そのため、ポイントインタイムリカバリが必要ない場合は、シンプルモードに切り替え、そのままにします。
ポイントインタイムリカバリが必要な場合は、フルモードに切り替え、ビジネスリスク/リカバリのニーズに応じて、1日を通して定期的なログのバックアップを実行します。 1時間ごとが人気ですが、 一部の人ははるかに頻繁に推奨しています 。
前に触れた最後のポイント：正しいリカバリモードを選択した後も、サイズの大きいログを縮小する必要があるかもしれません。覚えておくべきいくつかのこと：
- ここでも、適切な復旧モデルを選択していることを確認してください
- フルモードで実行している場合は、トランザクションログのバックアップを頻繁に実行していることを確認してください。
- ログの適切なターゲットサイズを選択し、ゼロに縮小しないでください。通常は、データファイルの合計サイズ（または少なくともデータファイル内の使用済みスペース）に基づいてスケーリングします
- VLF size に関するこの重要なアドバイス）を読んで理解してください。これにより、妥当なログサイズを決定するためのより多くのガイダンスが得られるか、ログをそのサイズに取得します。
SHRINKDATABASEは使用せず、常にSHRINKFILEを使用してください- シンプルモードとフルモードの両方で、ログファイルのendが現在アクティブなトランザクションのSQLによって使用されている可能性があります。その場合、必要なだけ縮小されません。数分後にもう一度縮小してください。トランザクションが完了している場合は、2回目にうまくいくはずです。
- フルリカバリモードで特に頑固なtranログを使用して、私は
SHRINKFILEを実行し、その後すぐにトランザクションログバックアップを実行し、直後に別のSHRINKFILEを実行することに成功しました。
「ログバックアップを実行しました」という質問には、1つのバックアップが示されます。まだ行っていない場合は、バックアップをいくつか実行してから、ログを圧縮してみてください。一部のトランザクションが単一のバックアップでクリアされないことは珍しいことではありません。彼らがクリアする前に、私は時々3または4をしました。
その後、DBCC LOGINFOを実行して、VLFファイルがどのように見えるかを確認します。 を読むことができます。なぜ仮想ログファイルが必ずしも順番に割り当てられないのですか？ VLFについてもう少し
SQL Serverのトランザクションログファイルについて知っておくべきことは、循環的に書き込まれるということです。これは物事を単純化しすぎて、仮想ログファイル（実際に内部でどのように処理されるか）のような詳細を省きますが、それは現実の合理的な複製です。
データベースを作成し、100 MBのトランザクションログファイルを作成するとします。トランザクションはファイルの最初から書き込まれます。次に、50 MBのトランザクションアクティビティがあるとします。これで、100 MBのトランザクションログの最初の50 MBが使用されます。次に、トランザクションログのバックアップを取ります。これで、トランザクションログのスペースがほとんど使用されなくなりました。実際には、すべてを（再）使用できます。しかし、ログを20 MBに縮小しようとするとどうなるでしょうか。それは（おおよそ）50 MBに縮小されます。
これは、ログのアクティブな部分がたまたまその50 MBのマーク付近にあり、SQL Serverがログを現在アクティブな場所を超えて縮小しないためです。カセットテープの再生ヘッドのようなものだと考えてください。SQLServerは、既に巻き取りリールにあるテープでは何もできません/できません。
これが、トランザクションログの圧縮が2段階のプロセスになることが多い理由です。最初のバックアップと圧縮（再生ヘッドの後にすべての空のテープを切り落とす）を実行し、次にトランザクションアクティビティを生成して、SQL Serverが強制的にラップバックするようにします。ログファイルの先頭まで（テープを巻き戻し）、最後にanotherバックアップを実行して圧縮します（空のテープを切り取って、目的のサイズにします）。
ログの再利用（つまり縮小）を妨げる可能性のある他のいくつかの状況areがあることに注意してください。通常、log_reuse_wait_descのmaster.sys.databases列を見ると理由がわかります。トランザクションレプリケーション、データベースミラーリング、およびAlwaysOn可用性グループが一般的な原因です。
完全復旧モデルを使用している場合は、定義上、トランザクションログバックアップが必要です。それらが必要ない場合は、完全復旧モデルを使用しても意味がありません。
あなたはあなたのやり方で縮小することを余儀なくされていません。さらに、パフォーマンスが低下します。
トランザクションログのバックアップを取ることをお勧めします。その後、フルが必要か、シンプルリカバリモデルに移動できるかを決定します。
また、おそらくdm_exec_sessionsを使用してアクティブなトランザクションをチェックし、インデックスの断片化レベルを調べて、縮小に役立たない構成があるかどうかを確認できます。