ログバックアップ操作を正常に実行するために、データベースログファイルが存在するディスクに使用可能な追加のスペースを残す必要がありますか？
ログファイルをサイジングして、それらが存在するドライブ全体を均等に分割し、使用可能なスペースを残さない場合でも、ログバックアップは引き続き正常に実行できますか？複数のデータベースがあり、データベースごとに1つのログファイルがあります。
ドライブの空き領域を残さない、つまりすべてをログファイルに割り当てるのは良い習慣ですか？ （この場合、ドライブはログファイル専用であり、データとOSは独自のパーティションにあります。）
ログ自体が不足しないことを前提として、ログファイルが存在するドライブに空き容量がない場合、SQL Serverに技術的な問題はありません、未使用、VLFエントリ。
ログの空き容量が不足すると、問題を解決するまでトランザクションをコミットできません。ドライブ全体がログファイルによって消費されている場合、実行できるonlyアクションは、別のドライブのログファイルをデータベースに追加することです。ログファイルを積極的に管理し、neverがログ領域を使い果たした場合、考えていることを行うことを技術的に禁止することはできません。
そうは言っても、利用可能なドライブ領域をすべて消費するようにログファイルのサイズを変更することはお勧めしません：
- Windowsは、ディスクの空き容量が不足していることに不満を抱きます。
- ログ領域が不足していて、ほぼ確実にある時点で、新しいログファイルを追加するまでデータベースにアクセスできない場合。
- ディスク容量はどれくらいかかりますか？ SQL Server Enterprise Editionライセンスの価格や、ダウンタイムによるビジネスへの潜在的なコストに比べて、ほとんど何もありません。 ドライブに空き容量を少し残しておく理由を自分に問いかけてください。
bigintの代わりにintを使用したり、smallintを使用したりするなど、間違ったデータ型の使用を推奨しているとは限りません。未使用のディスク領域は安価ですが、データベース内で使用される領域の内部は、@ SolomonRutzkyで簡潔に概説されている理由により、プレミアムコストと見なす必要があります こちら =。
コメントで、ディスクがいっぱいになるまでログが大きくなることと、その後ディスクがいっぱいになるほとんど空のログですでにディスクがいっぱいになっていることの間に違いは見られないと述べました。想定は正しいです。どちらのイベントでも、サーバーは次のエラーを返します。
メッセージ9002、レベル17、状態2、行22
'LOG_BACKUP'により、データベース '<database_name>'のトランザクションログがいっぱいです。
ただし、SANを使用している場合は、ドライブを最大サイズ、たとえば10TBでシンプロビジョニングできます。推定「正しい」初期サイズ、たとえば1GBでログファイルを作成し、増加を1GBに設定します（または 意味をなす ）。その後、必要以上のSANディスク領域を使用しなくなりますが、SANを関与させる必要なくログファイルを拡張する余地があります。管理者。Win-Win。
私の回答の以前のバージョンでは、次の誤った情報を述べました：
ログファイルを追加するだけでプライマリデータファイルが変更され、ログへの書き込みが必要になるため、ログ領域が既に不足しているときにログファイルを追加することは不可能です。鶏と卵のようなものです。
かなり広範囲にわたるテストを行った結果、既存のログファイルの容量が不足した後、新しいログファイルを正常に追加できました。これがどのように機能するかを示すブログ投稿を SQLServerScience.com に書いた。新しいログファイルを追加するために必要なアクションは次のとおりです。
- ディスク上に新しいファイルを物理的に作成する
- 新しいVLF構造をファイルに書き込む
- 既存のログファイルの更新-この目的のためだけに、既存のログファイルに事前に割り当てられた十分なスペースが必要です。他の目的には使用できません。
- 新しく作成されたログファイルを反映するようにプライマリmdfを更新する。
上記は、SQL Server 2008 R2およびSQL Server 2016で検証されています。
ログのバックアップによってログファイルのサイズが変更されることはありません。そのドライブにスペースが必要になる唯一の理由は、ログをそこにバックアップしていた場合です（これは、家の鍵を入れておくのと同じような悪い考えです）同じ鍵リング上のバックアップ）。しかし、少し異なる質問です。ログファイルがどれも大きくならないことを期待していますか？少なくとも少しスペースを残すと、異常に増加しているログファイルを処理できるカナリア時間が確保されます。スペースが残っていないため、ログファイルを拡張する必要があるとすぐにダウンします。