SQLログファイルのサイズを最適に維持する方法

私はやや新しいDBAであり、かなりの量のアクティビティがあるSQL Server 2012インスタンスを管理しています。ポイントインタイムリカバリが必要なため、フルリカバリモードで実行しています。

現在、私は毎日午前5時にデータベースとログの完全バックアップを取っています。一部のログファイルは最大300 GBに膨らみ、バックアップを取ってもサイズは小さくなりません。次のようなものを実行することで、サイズを小さくすることができます。

BACKUP LOG db1 TO DISK = '\\server\share\db1_log1.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log2.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log3.trn';
DBCC ShrinkFile([db1_log], 0);

バックアップファイルのLSNを確認すると、次のようなものが表示されます。

RESTORE headeronly FROM DISK = N'\\server\share\db1_log1.trn'
FirstLSN:  15781000014686200001
SecondLSN: 15802000000665000001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log2.trn'
FirstLSN:  15802000000665000001
SecondLSN: 15805000000004100001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log3.trn'
FirstLSN:  15805000000004100001
SecondLSN: 15808000000004200001

ログファイルを縮小してログチェーンを破壊しているとは思わない。これを読んで、これらの圧縮されたログファイルは再成長する必要があるため、パフォーマンスが低下していると思います。

質問：

1. バックアップ後にログファイルが縮小しないのはなぜですか？コミットされていないトランザクションがあるためですか？
2. 最初は、午前5時のバックアップごとにログファイルを圧縮する必要があると考えていました。それがパフォーマンスにどのように悪いかを読んだ後、私は今、日中数時間ごとに定期的なログのバックアップをとる必要があると信じています。あれは正しいですか？
3. データベース/ログの通常のフルバックアップは毎日午前5:00に行われ、時には3時間かかります。ログバックアップを1時間ごとに実行するようにスケジュールした場合、ログバックアップが午前5時のバックアップと衝突するとどうなりますか？

1. バックアップ後にログファイルが縮小しないのはなぜですか？コミットされていないトランザクションがあるためですか？

実際のNTFSログファイルはトランザクションログバックアップから「縮小」しませんが、トランザクションログ内のVLF（仮想ログファイル）は再利用のためにマークされます（これらはバックアップされ、メディアに保存されるため）発生するトランザクションログの使用。トランザクションログをバックアップしていない場合、または頻繁にバックアップしていない場合、利用可能なVLFがなくなり、追加のトランザクションログエントリに対応するためにトランザクションログが大きくなります（自動拡張が設定されている場合）。

2.最初は、午前5時のバックアップごとにログファイルを圧縮する必要があると考えていました。それがパフォーマンスにどのように悪いかを読んだ後、私は今、日中数時間ごとに定期的なログのバックアップをとる必要があると信じています。あれは正しいですか？

定期的およびスケジュールされたファイルの縮小はお勧めできません。必要なスペースを再利用する必要がある場合にのみ、DBCC SHINKFILE。また、トランザクションログを継続的に成長させると、データベースの回復などの他のことを妨げる可能性があります。トランザクションログ内のVLFが多すぎる（トランザクションログがわずかなストレージの増分によってのみ増大する場合の一般的な問題）と、データベースを回復するための時間が必要以上に長くなる可能性があります。

3.データベース/ログの通常のフルバックアップは毎日午前5時に行われ、時には3時間かかります。ログバックアップを1時間ごとに実行するようにスケジュールした場合、ログバックアップが午前5時のバックアップと衝突するとどうなりますか？

何も起こりません。これは完全に合法的な操作です。以下のMSDNのグラフを参照してください。黒い点がある場合、これら2つの操作は同時には発生しません。ご覧のとおり、データベースのバックアップとトランザクションログは同時に許可されます。

ここでのポイントは、トランザクションログをより頻繁にバックアップする必要があることです。トランザクションログをより頻繁にバックアップしないことで発生する可能性がある問題は、NTFSファイルの増加だけではありません。ストレージ障害が発生し、トランザクションログが失われた場合、最後のトランザクションログバックアップの時点までしか復元できません。トランザクションログが失われた場合、ログの末尾をバックアップして、障害のポイントインタイムに復元することはできません。あなたの場合、24時間分のデータを失う可能性があります。しかし、たとえば30分ごとにトランザクションログをバックアップすると、最大データ損失は30分になります。その場合、トランザクションログがなくなっており、完全バックアップと完全なログチェーンがある場合は、最後のログバックアップに復元できます。

トランザクションログの切り捨てに関するTechNetドキュメント

対処する主な問題は、ログを1日に1回バックアップすることです。エンジンの動作は、ログファイル内のログレコード（使用済みスペース）は、ログバックアップが正常に行われた後にのみ削除されるということです。このスペースは、チェックポイントがが発生すると回収されますが、データベースがフル/バルクログリカバリの場合、ログレコードはバックアップが正常に行われた場合にのみ削除されます。

ログバックアップは、完全バックアップと組み合わせて使用​​することを目的としており、完全バックアップの間に定期的に実行する必要があります。この間隔は任意の期間に設定できますが、通常は15分ごとにログバックアップを実行しています。間隔は、Recovery Point Objective（RPO）と、回復時に失われる可能性のあるデータの量に依存します。

定期的なログバックアップを実行している場合、ログファイルの容量を強制的に増やす前に管理するため、定期的なファイルの縮小を実行する必要はありません。

以前と同じ問題が発生しました。ログファイルは常に増加しますが、毎晩データベースのフルバックアップを使用します。だからここに私の解決策があります：

1. 現在のログファイルをバックアップします。

2. データベースをシンプルリカバリに設定する

   • 完全復旧の場合->ログファイルはコミットされたトランザクションを削除せず、データを再配置するだけです-> Shinkファイルはあまり影響しません->逆も同様です。

3. ログファイルを1 MB以下にする（それはあなた次第です）

4. データベースを完全復旧に戻します。

それが助けになることを願って

フォントラン