Aries アルゴリズムは、分析フェーズ後に元に戻すトランザクションを既に知っている場合、元に戻す前にやり直しを適用するのはなぜですか?
ディスクにフラッシュされたデータがクラッシュ時にトランザクションを元に戻すことと同じではない可能性があることを考えると、Lsn番号と一貫性を維持することに関係があることを私は知っています(ダーティのため)ページ)、しかし、この質問に対する「正式な」回答は見つかりません(少なくとも私が理解できるものは1つです)。
トランザクションがコミットされても、バッファにフラッシュされていないページが存在する可能性があるためです。ARIES はバッファ マネージャでno-forceを使用します。やり直すと、トランザクション テーブルとダーティ ページ テーブルがクラッシュ時の状態に戻ります。これにより、成功したトランザクションを安定したストレージに反映できます。
元に戻すパスを実行する前に、データベースの一貫性を確保するために、やり直しパスですべての履歴クラッシュを繰り返す必要があります。
リカバリ アルゴリズム ARIESは、DBMS の原子性と耐久性を確保するために、次の 3 つのパスを実行します。
UNDO データ ログは論理的ですが、REDO データ ログは物理的です。
aries が何であるかはわかりませんが、他のデータベースと同じであると仮定します。
いくつかのベース バックアップから開始して、REDO ログが適用されます。これは基本的に、バックアップ後、クラッシュが適用される前に発生したすべてのデータ変更ステートメントを意味します。そうしないと、最後のバックアップ以降に発生したすべてが失われます。
それが完了すると、未完了のトランザクションはすべてロールバックされます。これは、それらのトランザクションを取得して完了する人がいないためです。
どのトランザクションを元に戻す必要があるかを正確に把握するために、失敗時の状態に戻す必要があります。頭に浮かぶのは、失敗の連続です。クラッシュから回復するときの正確な障害。回復中に、ログにアクションを書き込みます。プロセスの回復中に失敗した場合は、ログ内のすべての操作を REDO します (最後の試行中に書き込まれた UNDO 操作も含まれます!!)。
特殊なケースや特殊なケースの特殊なケースを処理する必要がないため、単純なアルゴリズムを提供します。リカバリ中にクラッシュが発生した後、リカバリ中にクラッシュがなかったかのように同じ状態に戻ることが保証されています。
レコードレベルのロックをサポートしていない場合は、勝者トランザクションのみをやり直す選択的やり直しを使用できます。それ以外の場合は、元に戻す前に履歴を繰り返す(すべてやり直す)ことをお勧めします
ARIES の目標の 1 つは単純化です。やり直しの後の取り消しは必要ないかもしれませんが、やり直しの前に取り消しを行うより複雑なスキームよりも、アルゴリズムの正しさをより明確にします。
リドゥとアンドゥの間に実際に何が行われたかを考えることができます。終了したログによると、やり直しは履歴を繰り返しています。対照的に、元に戻すとは、新しい CLR ログ レコードを作成することです。システムがクラッシュすると、コミットされていない xacts に関する記録がログに記録されます。元に戻さないと、CLR ログ レコードが存在しないため、不整合が発生します。