ARIESでクラッシュした後、コミットされていないトランザクションがやり直しではなくロールバックするのはなぜですか？
トランザクション内のすべてのアクションは、先行書き込みロギングを使用するARIESのようなクラッシュリカバリアルゴリズムでべき等であるため、コミットされていないトランザクション中にクラッシュ後にロールバックして、トランザクション全体を単にやり直すのではなく、一貫した状態に戻すのはなぜですか？
このようにしてトランザクションを完了し、元に戻す処理を行う必要はありません。
コミュニティウィキの回答 -編集して投稿を追加してください：
一般的に言って、コミットされていないトランザクションが実際に必要なすべてを完了したという保証はありません。
BankAから100ドルを引き出したが、BankBにお金を預けていないトランザクションは、コミットされていないトランザクションです。これらの2つのプロセス間でクラッシュが発生した場合、他の計算や更新を伴う可能性のあるトランザクションのデポジット部分に到達しなかったため、何をやり直すかを判断する方法はありません。
外部アプリケーションはコードでトランザクションを開始し、そのトランザクション内でいくつかの更新、挿入、および削除を実行します。そのトランザクションの途中で、サーバーがクラッシュします。さて、データベースがクラッシュするまでに発生したすべての更新を再生して強化できたとしても、アプリケーションはロジックのどこで再起動するかをどのように知るのでしょうか。
完全に元に戻すには、最初から外部アプリケーションを起動するだけです。クラッシュリカバリ中にコミットされていないトランザクションを処理するための絶対的に安全な方法は、発生したことがないかのようにロールバックすることです。
Atomicity-トランザクションは多くの場合、複数のステートメントで構成されます。 Atomicityは、各トランザクションが単一の「ユニット」として扱われることを保証します。これは、完全に成功するか、完全に失敗します。トランザクションを構成するステートメントのいずれかが完了しなかった場合、トランザクション全体が失敗し、データベースは変更されません。アトミックシステムは、停電、エラー、クラッシュなど、あらゆる状況でアトミック性を保証する必要があります。
適切に実装されたARIESでは、クラッシュリカバリはチェックポイント（マスターレコードに保存されている）から開始され、チェックポイント以降にコミットされたトランザクションと失敗したトランザクションを特定し、すべてのアクションをやり直してから、失敗したトランザクションの影響を元に戻す必要があります。 Remus Rusanuによる ARIESアルゴリズムの回復フェーズ中にDBMSがクラッシュするとどうなりますか？ の回答を参照してください。
また、クラッシュ時には「メモリ（RAM）に保存されているコンテンツが破損または失われたと見なされる」ため、ロールバックする必要があることに注意してください。ディスクに書き込まれたものだけが有効/安定しています。
これは、定義上、コミットされていないトランザクションですべてのログが書き出されていないにもかかわらず、ログに関連するダーティページがディスクにフラッシュされている可能性があるためです。したがって、これらの変更を元に戻す必要があります。変更を元に戻すには、最初にやり直す必要があります。