4日前に、ユーザーが400,000,000行のテーブルで以下のコマンドを実行しました。それはまだ実行中で、ログファイルのサイズは増加しています。
delete from [table-name]
このテーブルには、チェックが有効になっていない外部キー制約があり、他のテーブルに行が存在しないことがわかっています。
データベースは、「Is Read Committed Snapshot On」を有効にして、シンプルリカバリモードで実行されています。
これが数時間実行された後、ログファイル用のディスク領域が不足していたため、kill sessionコマンドを発行しました。システムが引き続き機能できるように、別のログファイルを追加しました。
ログファイルは増加を続けており、statusonlyでkillセッションを実行すると、次のメッセージが返されます。
SPID 123: transaction rollback in progress. Estimated rollback completion: 0%. Estimated time remaining: 0 seconds.
このクエリをロールバックするために何をすべきかについて途方に暮れており、何が起こっているのかを理解しているだけですが、誰かが私が見ることができるものを提案できますか?
このクエリをロールバックするために何をすべきかについて途方に暮れており、何が起こっているのかを理解しているだけですが、誰かが私が見ることができるものを提案できますか?
DELETE FROM [Some400MRowTable]
高いです。削除したすべての行がログに記録されます。また、セッションを終了すると、巨大なトランザクションはロールバックする必要があり、さらにコストがかかります。したがって、通常は待機するだけで、最終的にはロールバックします。別の方法は、バックアップから復元することです。
これが理由の1つであることに注意してください Accelerated database recovery は、Azure SQL DatabaseとSQL Server 2019で追加されました。これにより、ロールバックコストが、トランザクション。
ロールバックはシングルスレッドなので、長い時間がかかりますが、4日間は長いようですが、元の削除にどれくらい時間がかかるかわかりません。 Jes Schultz Borland( link )から:
トランザクションが操作を実行するために行またはテーブルをロックする必要がある場合、そのロックを再度取得する必要があり、他のプロセスがそのオブジェクトを使用している可能性があります。また、ロールバックはほとんどがシングルスレッドであることを考慮してください。トランザクションが最初に4つのコアを使用して実行され、ロールバックが1つだけを使用するようになった場合、さらに時間がかかります。
これを想像してみてください。あなたは1万段の階段を登ることにしました。階段9,999に到達し、登りを完了しないことにしました。自分が一番下のステップに到達することを望むことはできません。元に戻る必要があります。しかし、今、あなたは疲れています–そして、これをシングルスレッドで実行する必要があります。片足で階段を後ろに下る必要があることを想像してみてください。
BradCの回答によると、SQL Serverを再起動すると、トランザクションログの読み取り中にロールバックが続行されます。バックアップ/リカバリ計画によっては、バックアップからの復元が最適なオプションになる場合があります。
したがって、削除は強制終了する前に「数時間」だけ実行され、「ロールバック」は4日間実行されていますか?
それは私が通常期待する時間をはるかに過ぎているので、ここに私がお勧めするものがあります:
再起動で問題が解決した場合は問題ありません。そうでない場合でも、バックアップからの復元を行うだけで問題はありません。
幸運を。
DELETEの代わりにTRUNCATE TABLEを使用することを考えましたか?その行数が多いテーブル内のすべての行を削除しようとしている場合は、TRUNCATE TABLEの方が適している可能性があります。 DELETEよりも速く実行されます。ただし、使用すると、必要に応じてロールバックできない場合があることも理解しています。 TRUNCATE TABLEを使用しているときのロールバックについて私が間違っている場合、私よりも賢い他の人が私を修正できます。