大規模なトランザクションログを切り捨てる代替戦略はありますか？ （> 200gb）

Question

私は同様の質問に対してもう1つの答えをしようとしていますが、トランザクションログを切り捨てるのが200GBであるログと20GB近辺で見た多くの例のログが異なるかどうか尋ねたいと思っていましたか？

その他の質問は20GBのトランザクションログを取り、1MBに減らします.10倍のサイズのトランザクションログでは戦略は異なりますか？

Answer 1

「ログの切り詰め」はあいまいな用語です。 DBCC SHRINKFILEを使用してトランザクションログのLDFファイルを縮小すると仮定しています。

いいえ、プロセスは大きく異なりません。

注意：トランザクションログが使用されるため、必要なサイズに縮小するには、ログファイルを2倍に縮小する必要があります。

1. 目的のデータベースに対して実行DBCC LOGINFO、あなたは、トランザクション・ログ内の各VLF（仮想ログファイル）を参照してくださいよ。ステータスが2のものはすべてアクティブでログバックアップを待っています。ログバックアップを行わずにDBCC SHRINKFILEを実行すると、Statusが2の最大StartOffset + FileSizeが最小サイズになります。

2. トランザクションログのバックアップを実行すると、VLF現在使用されているステータスは2のままです。まだ使用されているので、まだアクティブです。私が知る限り、最大のFSeqNoを持つDBCC LOGINFOにリストされているVLFは、現在使用されているVLFです。つまり、LOG BACKUPを実行してすぐにDBCC SHRINKFILEを実行した場合、最小サイズは最大FSeqNoを持つVLFのStartingOffset + Filesizeになります。 VLFがいっぱいになるのを待つ必要があり、ログバックアップでこのVLFが非アクティブとマークされる前に、サーバーは新しいVLFに切り替わり、DBCC SHRINKFILEを小さくすることができます。

ので、ログファイルを縮小するための最善の戦略は次のとおりです。

1. なぜ間違っているといったかを把握するために、データベースとの活動を分析します。
2. 使用状況に基づいて、トランザクションログの最適なサイズを決定します。
3. バックアップログを実行します。
4. DBCC SHRINKFILEを実行します。
5. ログファイルを縮小する量を決定します。
6. ログファイルのサイズが正しい場合は、完了です。
7. それ以外の場合は、DBCC LOGINFOを監視して、VLFが新しいVLFにファイルの前にロールオーバーしたことを確認します。あなたは＃6をスピードアップするためにトランザクション・ログ・データを生成する必要がある場合3.

から

Goでは、インデックスが再構築実行することを検討します。

＃1 &＃2は、サーバーを正しく管理している場合にのみ可能です。将来的にサーバーを再訪する必要がありますが、将来問題が発生するのを防ぐためには不可欠です。

シンプルリカバリモードを実行していないと仮定しています。シンプルリカバリを使用しているデータベースの200GBトランザクションログは比較的ありそうにないためです。万一単純なリカバリを実行している可能性がある場合は、上記のBACKUP LOGをCHECKPOINTコマンドに置き換えることができます。