• ベストアンサー

障害回復(ロールバックとロールフォワード)について

  t0  t1  t2   t3   t4   t5        |           | A s---e   |           |         |           | B s-------------e        |         |           | C  s------------------------|         |           | D       |   s----e    |         |           | E       |    s---------| ※t2はチェックポイント、t5は障害発生 ロールバックとロールフォワードについて教えてください。 (1)BとEについてロールフォワードによる回復が必要とのことですが、障害発生前にトランザクションが終了しており、コミットされているはずなのに、なぜロールフォワードが必要なのでしょうか? (2)Aはチェックポイント前に処理が完了しているため、回復処理は不要とのことですが、BとEが必要でAが不要の違いわかりません。 よろしくお願いします。

質問者が選んだベストアンサー

  • ベストアンサー
  • mitoneko
  • ベストアンサー率58% (469/798)
回答No.2

 障害回復における、チェックポイントとログの位置づけをちゃんと理解しておくことが必要です。  表現は、少々乱暴ですが・・・  まず、データベースは、障害回復のために、総てのデータベース操作に関して、詳細なログを保持します。(このログさえあれば、全操作のやり直しも取消も可能なだけの情報を保持します。障害回復の他にもいろいろな用途に使われるシステムの心臓部に近いです。もちろん、最重要ファイルですので、物理ファイルへの記録も最優先で行われ、さらに、壊れた時のことを考えて複数ファイルにコピーしておくこともあります。ある意味、データベース本体の物理ファイルより重要なファイルです。データ本体なんて、このログさえあればいつでも作り直せますから。)  さて、操作のコミットとはなんでしょうか?実は、コミットすることにより、データベースが保証するのは、単に、「データを確定状態とし、ログを完全な形で確定しまた。」というだけのことなんです。データベースの状態としては、もしかすると、単にメモリー上にあるキャッシュデータを書き換えただけで、実際の物理ファイルへの記録は遅延されているかもしれません。  でも、チェックポイントは違います。総てのデータが最終的な物理ファイルに正しい形で保存されることを保証します。同時に、ログに関しても完全な状態であることを保証します。よって、この時点が、障害回復における起点になります。(障害が起こったと言うことは、物理ファイルがすべてのよりどころです。メモリー上のキャッシュなんて当然吹っ飛んでるのが前提ですから。ちなみに、データベースの物理ファイルのバックアップはチェックポイントの強制的な発生がセットです。でないと、物理ファイルがデータベースの正しい状態を保持している保証が持てないからです。)  総ての障害回復は、この時点のデータベースの状態を原点として行います。  各、トランザクションに関して、詳しく見てみましょう。  総ての前提として、障害が発生した後、回復処理を行うわけですが、データベースは、最初に直近のチェックポイントまで巻き戻されます。これは、中途半端なデータが物理ファイルに残っている可能性が捨てきれないからです。メモリーキャッシュの中身はもうこの時点では解りませんからね。  まず、A。これは、チェックポイント以前にコミット処理まで総て終了しています。従って、物理ファイルに完全な結果が反映されているので、何ら処理の必要はありません。  次に、B。チェックポイント時点では、コミットが完了していなかったと仮定します。(線のずれが微妙で、どっちか判別できないんですが、この図を書いた人としては順番からして、多分そのつもりだったろうと想像します。)データベースは、チェックポイントまで巻き戻されました。でも、ログは残っています。ですから、チェックポイント後のログのデータを元に、この部分の操作をやり直します。この操作をロールフォーワードと呼びます。  次に、C。これは、障害時点でコミットされていません。従って、このトランザクションは、ロールバックを指示されたと解釈するべきです。(障害後に何をするつもりだったかはRDBMSは知りませんからね。コミットする気だったかロールバックする気だったかも解りません。解らないことがあるなら悲観的に物事を考えるのがトランザクションの仕事です。)でも、データベース物理ファイルはチェックポイント時に確定してしまいました。ですから、ログを元に、チェックポイントからさかのぼって操作を取り消します。(逆操作を行うわけです。)これが障害回復におけるロールバックです。この後、このトランザクションに関しては、トランザクションを再実行する必要があります。  次に、D。これは、チェックポイント後にスタートし、障害前にコミットが完了しています。データベースはチェックポイント時点まで巻き戻されていますから、全部の操作のやり直しです。ログは完全に残ってますから、ログを元にロールフォーワードします。  最後にE。チェックポイント後にスタートし、障害時点でコミットされていません。コミットしていませんから、これもロールバックすべきです。でも、データベースはチェックポイントまで巻き戻されています。ということは・・・そう。なんにもする必要はありません。当然、この後、このトランザクションは、再実行する必要があります。(このEは、図の読み方が少し自信ありません。というのは、あなたは、障害前にコミットされていると書いておられるのですが、eマークが図にないように見えるので・・・書き忘れか、文章がミスかどちらか解らないんです。)  以上です。図が、ずれているので、多分そうだろうと言うように読みました。もし、タイミングの読みが間違っているようなら、上の話を基本に考えてみてください。  ちなみに、実際のシステムが、実際に物理ファイルを巻き戻すかを含めて、実装方法は様々です。あくまで考え方と言うことで。

jolyyne
質問者

お礼

mitonekoさん、早速のご回答ありがとうございます。 > 次に、B。チェックポイント時点では、コミットが完了していなかったと仮定します。(線のずれが微妙で、どっちか判別できないんですが、この図を書いた人としては順番からして、多分そのつもりだったろうと想像します。) ずれて見えていましたか。すみません。私のPCではちゃんと見えてたので。申し訳ないです。その通りです。 >Eは、図の読み方が少し自信ありません。というのは、あなたは、障害前にコミットされていると書いておられるのですが、eマークが図にないように見えるので・・・書き忘れか、文章がミスかどちらか解らないんです。) 重ねがさねすみません。文章のミスです。 「BとEについて・・」と書いていますが、「BとDについて・・」が正しいです。 非常にわかりやすい解説をありがとうございます。 コミット直前のログの書き出しと、チェックポイントとの役割についてようやく理解できました。 ここが理解できてなかったので、図のそれぞれのパターンでの対応の違いが理解できませんでした。ありがとうございました。

全文を見る
すると、全ての回答が全文表示されます。

その他の回答 (1)

  • Kazma_hk
  • ベストアンサー率26% (115/428)
回答No.1

ロールバックとロールフォワードの違いですね。 ロールバックはトランザクションが完了する前に障害が起きた場合にトランザクション開始時点に戻すこと。 ロールフォワードは、チェックポイント時点に戻すことです。 チェックポイントとはいわゆるセーブポイントです。 セーブポイントまで戻るということはそのほかのデータに関してもチェックポイント時点まで戻ってしまいます。 Aはチェックポイントt2時点でデータが確定しているためロールフォワードの意味がありません。t5からt2に戻っても変化がないためです。 B,Eに関しては、t2時点で変更はないですが、t2からt5までの間にデータの変更があるため、t2時点まで戻さないと他のデータとの整合性がなくなってしまうため必要となります。

jolyyne
質問者

お礼

Kazma_hkさん ご回答ありがとうございます。 ロールバック、ロールフォワード、それぞれの具体的な役割のイメージがやっと頭の中でできました。 ありがとうございました。

全文を見る
すると、全ての回答が全文表示されます。

関連するQ&A

  • ロールバックとロールフォワード(データベーススペシャリスト試験)

      t0  t1  t2   t3   t4   t5         |           | A s---e  |           |         |           | B s-------------e       |         |           | C s------------------------|         |           | D       |   s----e   |         |           | E       |   s---------| 図がずれていたらごめんなさい。 A~Eはトランザクション sはトランザクション開始 eはコミット t0~t5は時間を表していて 時間t2でチェックポイント 時間t5で障害が発生したとします。 参考書によると復旧時に CとEはロールバックを行い、 BとDはロールフォワードを行うとあります。 B、C、Dはわかるのですが Eにロールバックが必要な理由がわかりません Eを再び実行するためにはデータは トランザクションを開始したt3時点の状態であればよいはずです。 そしてチェックポイント(=t2)の状態はt3と同じなので、 Eの更新前ファイルを使ってデータをロールバックする必要はないように思えます。 どこで間違っているでしょうか。。。

  • チェックポイントとロールバックのタイミングについて。

    下記のパターンの際に、transaction logファイルに書き込まれるのか否かを教えて下さい。 A:チェックポイントをまたがったトランザクションで完了後にシステム障害が発生した場合。 =>私の認識では、ロールフォワードによって、データベースとtransaction logファイルにデータが書き込まれる。と考えているのですが、正しいでしょうか? B:チェックポイントを一度も通らずに、トランザクションが完了。完了後にシステム障害が発生。 =>Aと同じですか? C:トランザクション実行中にシステム障害が発生した場合。 =>ロールバックされて、transaction logファイルにのみ書き込まれて、データベースには書き込まれない。というのは正しいでしょうか? よろしくお願いします^^

  • ロールバックとチェックポイント関連で質問です。

    下記のパターンの際に、transaction logファイルに書き込まれるのか否かを教えて下さい。 A:チェックポイントをまたがったトランザクションで完了後にシステム障害が発生した場合。 =>私の認識では、ロールフォワードによって、データベースとtransaction logファイルにデータが書き込まれる。と考えているのですが、正しいでしょうか? B:チェックポイントを一度も通らずに、トランザクションが完了。完了後にシステム障害が発生。 =>Aと同じですか? C:トランザクション実行中にシステム障害が発生した場合。 =>ロールバックされて、transaction logファイルにのみ書き込まれて、データベースには書き込まれない。というのは正しいでしょうか? よろしくお願いします^^

  • ロールバックできず困っています。

    1.テーブルAに、新たに列を追加したテーブルBを作成。 ↓ 2.テーブルAのデータをテーブルBにコピー。 ↓ 3.テーブルAを削除。 ↓ 4.テーブルBの名前をテーブルAに変更。 という一連の処理があります。 これらの処理でエラーが発生した場合、処理実行前の状態に戻したいのですが、ロールバックできずに消されるはずだった不要なテーブルが残ってしまいます。 何か方法はありますか?よろしくお願いします。

  • MySQLでロールバックできない!

    JDBCでMySQLに接続し、ロールバック/コミットしたいのですが、以下の例外が発生してロールバックできません。 java.sql.SQLException: General error: Warning: Some non-transactional changed tables couldn't be rolled back 同じコードで、PostgreSQLでは問題なく動作します。 MySQLはDBMSとして自動コミットになっているとのことですが、JDBCからロールバックしたいときはどうすれば良いのでしょうか? 有名な問題なのかもしれませんが、回避策が見つけられませんでした。 ご回答、よろしくお願いします。

    • ベストアンサー
    • Java
  • トランザクションを張って対話型でのコミット・ロール

    トランザクションを張って更新処理を行った後に、 ユーザの「はい」「いいえ」ボタンによって、 トランザクションのコミットとロールバックを切り替えることは可能でしょうか。 処理の流れは以下の様になります。 1.データ更新前の値を取得 2.トランザクションの開始 3.データ更新 4.データ更新前の値とデータ更新後の値を比較して、   差分がある場合は確認メッセージを表示する。 5.確認メッセージで「はい」がクリックされた場合はコミットする。 6.確認メッセージで「いいえ」がクリックされた場合はロールバックする。 実装方法はどのようでも構いません。 どなたかご教授ください。

  • PLSQlでのロールバック

    以下の様な処理をしたいのですがうまくいきません。 ・カーソルc_infoで取得した人数分、処理を行いたい。 ・ある1人が異常終了した場合は、その人の処理を全てロールバック  した後、次の人に進む。 begin for r_info in c_info loop begin 処理A  処理B  処理C exception  rollback; end; end loop exception end; こういう風に組んだのですが、 ある一人が処理Cで異常終了した時、その人の処理A,処理B がコミットされてしまっています。 どのようにすればよいでしょうか? ご教授ください。

  • トランザクションのネストについて

    トランザクションのネストについて お世話になります。 今、ストアドの中でストアドを実行するようなSQLを作成しているのですが、 このときのトランザクション処理について教えていただきたいです。 簡単な流れとしましては Aトランザクション開始(大枠のストアド) ↓ 処理a  ↓  Bトランザクション開始  ↓  (Aストアドの中のストアド実行)  ↓  Bコミット  ↓ 処理b ↓ Aコミット といった感じなのですが、BストアドでコミットするとBストアドをCALLする前の処理aが コミットされてしまいます。 ここはBはBだけでコミットされてほしいのです。 独自で調べた限りでは、「トランザクションのネストはMySQLではできない」ということらしいのですが、 こういった場合、どのようにしたらよいのでしょうか。 もし方法があれば、ご教示のほどお願い致します。 -環境- [DB MySQL 5.0] [OS Windows XP]

    • ベストアンサー
    • MySQL
  • なぜtry{}catch(){}の中?

    DBへの更新を行う際に 私は try{ トランザクションスタート 処理 コミット }catch(Exception e){ ロールバック } の書き方をしていますが トランザクションスタート try{ 処理 コミット }catch(Exception e){ ロールバック } の書き方をしている人がいたので try{}catch(){}の中に トランザクションスタートを入れて下さいと伝えたところ なぜ?try{}catch(){}の中に入れるのか聞かれたのですが 答えられませんでした。 ネットにて色々なソースコードをみても try{}catch(){}の中に書かれているのでそういうモノとして 覚えているのですが、なぜ中なのでしょうか?

    • ベストアンサー
    • PHP
  • データベースの質問です。下記の四択について、どうい

    データベースの質問です。下記の四択について、どういうものか根拠を教えて下さい システム障害発生時には,データベースの整合性を保ち,かつ,最新の データベース状態に復旧する必要がある。このために,DBMSがトランザクション のコミット処理完了とみなすタイミングとして,適切なものはどれか。  ア アプリケーションの更新命令完了時点  イ チェックポイント処理完了時点  ウ ログバッファへのコミット情報書込み完了時点  エ ログファイルへのコミット情報書出し完了時点