web-dev-qa-db-ja.com

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

私はやや新しいDBAであり、かなりの量のアクティビティを持つSQL Server 2012インスタンスを管理しています。完全復旧モードで実行しているのは、ポイントインタイムの復旧が必要だからです。

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

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時に行われ、3時間かかることもあります。ログバックアップを毎時間実行するようにスケジュールした場合、ログバックアップが午前5時のバックアップと衝突するとどうなりますか？
sql-serversql-server-2012backuplogs
13
Elijah W. Gagne
  1. バックアップ後にログファイルが縮小しないのはなぜですか？コミットされていないトランザクションがあるからですか？

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

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

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

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

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

enter image description here

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

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

10
Thomas Stringer

対処する主な問題は、ログを1日に1回バックアップすることです。エンジンの動作は、ログファイル内のログレコード（使用済みスペース）は、ログのバックアップが成功した後にのみ削除されることです。このスペースは チェックポイント が発生したときに再利用されますが、データベースが完全/一括ログ復旧の場合、ログレコードは正常にバックアップされた場合にのみ削除されます。

ログバックアップは、フルバックアップと組み合わせて使用​​することを目的としており、フルバックアップ間の定期的な間隔で実行する必要があります。この間隔は任意の期間にすることができますが、私は通常15分ごとにログバックアップを実行しています。間隔は、目標復旧時点（RPO）と、復旧時に失われる可能性のあるデータの量によって異なります。

定期的なログバックアップを実行している場合は、ログファイルスペースを強制的に拡大する前に管理するため、定期的なファイル圧縮を実行する必要はありません。

5
Mike Fal