SQL Serverトランザクションログの最大ファイルサイズ
いくつかのデータベースがあり、すべてSimpleリカバリモードです。ログファイルのサイズに関する以前の懸念があり、Management StudioのShrinkタスクを使用してそれらすべてを縮小しました。また、ログの自動拡張が最大サイズ1024 MBになるように設定しました。ログファイルが1024 MBになるまで、必要に応じて拡大し続けることを期待しています。この時点で2つの質問があります。
- この制限に達すると、ログファイルはどうなりますか？
- 小さい上限を設定することによる影響はありますか（1024 MBではなく100 MBなど）？
1日に2回実行されるバックアップメンテナンスプランもあり、ログは自動的に（縮小ではなく）切り捨てられることに注意してください。
トランザクション中にログファイルのサイズが上限に達し、自動拡張できない場合、トランザクションはコミットできず、SQLでエラーが発生します。ログファイルは、CHECKPOINT操作間のトランザクションを処理するのに十分なサイズである必要があります。下限を設定すると、大きなトランザクション（ワークロードに依存）が原因で問題が発生する可能性が高くなります。
正常な自動拡張パラメーターが設定されていると仮定すると、ログファイルは必要なサイズまで自然に大きくなります（TomTomが示唆したように、自動拡張がそこに到達するのを待つよりも、適切なサイズで開始する方がよいことに注意してください。その間）。通常、シンプルモードのログファイルを縮小する必要があるのは、最近、ある種のバルクトランザクションを実行したためにログファイルが通常必要なサイズよりもはるかに大きくなり、他のスペースのためにそのスペースを再利用する必要がある場合のみです。使用する。
ログファイルを頻繁に圧縮する必要がある場合は、システムに領域を追加するか、その領域を必要とする他のサービスを別のサーバーに移動する必要があります。
この制限に達すると、ログファイルはどうなりますか？
あなたは困っています。トランザクションは失敗します。これは、負荷を処理する準備ができていない可能性が高いシステムでの1 GBのロールバックです。文字列には想定された時間が経過します。
上限を小さく設定した場合（1024 MBではなく100 MBなど）の影響はありますか？
早くスペースが足りなくなります。特定の操作が失敗する可能性があることを意味します。
データベースがどのくらい小さいのか確認してください。
- 常に最大サイズに事前割り当てし、
- 彼らが呼吸する余裕があることを確認してください。
ここではシンプルでは動作しませんが、15分間隔で500 mbを実行しているデータベース（50分ごとにバックアップします）を使用しており、txログは時折ETLジョブ用に400 GBです。ファイルの増加によるトラブルやパフォーマンスの低下（および、発生したrel内部の断片化）と比較すると、文字通りセントがかかります。 Autogrowは「ローエンドの小規模データベース」にのみ適しています。
1日に2回実行されるバックアップメンテナンスプランもあり、ログは自動的に切り捨てられる（縮小ではなく）ことに注意してください。
シンプルなrevcoveryモードでは、すべてのチェックポイントでほとんど切り捨てられます。構成した内容を確認します。