これが私のシナリオです。Log4Netからのレコードを(MSMQ経由で)保持するテーブルを持つデータベースがあり、それをLoggingと呼びましょう。dbのリカバリモードはSimpleに設定されています。トランザクションログは気にせず、ロールオーバーできます。
sp_spaceusedのデータを使用して、特定のサイズのしきい値に達したかどうかを判断するジョブがあります。しきい値を超えた場合、サイズをそのしきい値のxパーセントに下げるために削除する必要のある行数を決定します。(余談ですが、行数と平均サイズの概算を取得するためにexec sp_spaceusedを使用していますが、それが最善の方法であるとは確信していません。しかし、それは別の問題です。 MyLogTable
)TRUE
次に、基本的にこれを行うsprocへの呼び出しをループすることにより、削除をチャンク化しようとします(たとえば、一度に5000)。
DELETE TOP (@RowsToDelete) FROM [dbo].[MyLogTable]
削除する必要があるものを削除するまで。
問題は次のとおりです。削除する行がたくさんある場合、トランザクションログファイルがいっぱいになります。走ることで成長するのを見ることができます
dbcc sqlperf (logspace)
私が困惑しているのは、ジョブが失敗すると、削除されたすべての行がロールバックされることです。言い換えると、すべてのチャンクが(どういうわけか)暗黙のトランザクションでラップされているように見えます。
暗黙のトランザクションを明示的にオフに設定し、各DELETEステートメントをBEGINおよびCOMMIT TRANでラップしようとしましたが、役に立ちませんでした。削除されたチャンクがすべて成功するか、まったく成功しません。
簡単な答えは、ログファイルを、削除する可能性のある最大数のレコードを処理するのに十分な大きさにすることですが、それでも、これが単一のトランザクションとして扱われるのはなぜですか。
簡単なことを見逃してしまったら申し訳ありませんが、ログファイルの増加やリカバリモードなどに関する投稿をたくさん見てきましたが、これがわかりません。
もう1つ、ジョブが失敗すると、ログファイルは約95〜100%の状態でしばらくの間、ドロップバックする前に保持されます。しかし、私が実行した場合
checkpoint
dbcc dropcleanbuffers
使用率は約5%に戻ります。
TIA。