AlwaysOn可用性グループ2014の使用中にトランザクションログを縮小する
SQL Server 2014可用性グループを単一のセカンダリで非同期モードで実行しています。
すべての可用性グループデータベースの私のログは成長し続け、組み込みの縮小ツールはそれらを一段下げるだけです。
なぜログが増大し続けるのか、または可用性グループデータベースでログの縮小を自動化する方法を見つけるために、一連のトラブルシューティング手順を推奨できますか？
AlwaysOn可用性グループを使用する場合、適切なバックアップをとっても、ログファイルが大きくなり、ログドライブが時間の経過とともにいっぱいになる可能性があります。適切な（縮小）ログファイルサイズを維持するために、次の手法を使用できます。
AlwaysOn構成で、バックアップ優先順位オプションをプライマリレプリカ/サーバーに変更します。データベースはデフォルトで完全復旧モードであるため、少なくとも1つの完全バックアップと1つのトランザクションログバックアップを取ります。プライマリレプリカ上のすべてのデータベースのログファイルを圧縮します。これにより、すべての可用性レプリカの空のログドライブが切り捨てられます。最後に、定期的に適切なバックアップを取るジョブをスケジュールします。これにより、ログファイルを適切なサイズに保つことができます。これが役に立てば幸いです！
定期的にデータベースとログファイルを縮小することはお勧めしません。例外的な場合にのみ、1回限りのアクティビティをお勧めします。データベースファイルを圧縮すると、未使用のスペースが解放され、スペースがファイルシステムに解放されます。これは醜くなり、その結果としてインデックスが完全に断片化する可能性があります。代わりに、推奨されるアプローチは、自動拡張設定を固定サイズに設定するか、デフォルトの10％自動拡張設定をバイトに変更して、予測される数値を確認することです。
SQLが常にオンの場合、ログファイルのサイズに問題がある場合は、常にプライマリレプリカからT-Logバックアップを作成してください。
DBは常時オンなので、ステップ1
- スケジュール済み/優先ノード（レプリカ）でログのバックアップをとります。
- プライマリでデータベースを縮小Node、レプリカがROモードであり、ログファイルが継続するため、サイズとして20％をバッファーとして保持するため成長します。ログの成長のために再びIOを使う必要はありません。
これで、ログファイルの増加をある程度制御できます。
ステップ2 6時間ごとまたは1日に1回、Logbackupsを計画します。これにより、ログがクリアされ、スペースは将来のログに使用できるようになります。
毎月これを監視し、ログファイルが予想以上に大きくなった場合は、手順1を繰り返します（ログバックアップが失敗した可能性があります）。