SQL Server 2008のログファイルは、単純なリカバリでも非常に大きくなります
SQL Server 2008には、Recovery modelがSimpleに設定されているデータベースがあります。
定期的に、大きなテーブルで大きな更新を実行します（更新する行数は1500万行）。これを実現するために、実行に2時間以上かかるストアドプロシージャを実行します。ストアドプロシージャの実行が終了すると、ログファイルは37 GBに増加しました。これは、リカバリモデルが単純であり、私たちはしませんストアドプロシージャでトランザクションを明示的に開始するためです（安全のために更新する前にDBの完全バックアップを作成してください）
また、ログファイルを縮小すると1MBに戻ります
ログファイルが37GB大きくなるのを防ぐにすることは可能ですか？
ありがとうございました
私も同様の問題を抱えていました。数百万の古いレコードを削除する必要がありました。ログファイルの使用可能な領域が小さすぎるため、約30分後に削除が失敗しました。一度に500,000レコードのみを削除するように削除ステートメントを変更することで、これを解決しました。これで問題は解決しました。
その知識をあなたのケースに適用すること。 1つの大きな更新ではなく、いくつかの小さな更新を実行できますか？これは、ストアドプロシージャに「begintransaction」ステートメントと「commit」ステートメントを明示的に追加することで実行できます。ストアドプロシージャの最初と最後のステートメントに加えて、100万行後にコミットを発行し、より新しいトランザクションを開始できます。更新のたびにコミットを行わないのは、パフォーマンスが大幅に低下するためです。別のオプションは、ストアドプロシージャを特定の量に制限してそれを数回呼び出すか、データのさまざまな部分で機能する同様のストアドプロシージャを作成することです。
トランザクション境界を明示的に使用していないため、トランザクション分離レベルをコミットされていない読み取りに設定することができます。 here。 を参照してください。処理が高速化される可能性があると思いますが、トランザクションログに大きな影響を与えるとは思われません。分離レベルをコミットされていない読み取りに設定することにより、ダーティ読み取りを有効にすることに注意してください。
また、ログの増加を最小限に抑えるために、操作を分割することをお勧めします。 auto_shrinkを有効にしない限り、SQL Serverはログを自動的に縮小しません。これにより、パフォーマンスに大きな問題が発生する可能性があります。
AFAIK、自動縮小は30分ごとにのみ実行されます。ストアドプロシージャが終了してからどれくらいの期間、ログファイルを確認していますか？また、このサーバーにはいくつのデータベースがありますか？自動縮小はラウンドロビンベースで機能し、この特定のデータベースにアクセスするのに時間がかかる場合があります。