KENスクールブログ | パソコン教室・パソコン講座なら個別指導のKENスクール

BLOGKENスクールブログ

  1. KENスクール TOP >
  2. KENスクールブログ > プログラム > Oracleデータベース REDOとUNDOのアーキテクチャー

プログラム

Oracleデータベース REDOとUNDOのアーキテクチャー

Oracleデータベース管理を学ぶ上で、データの整合性の維持や保護において重要なREDOとUNDOの理解が必要になります。REDOとUNDOは名前が似ており混同しやすいので、両者の違いとそれぞれのアーキテクチャーをご紹介します。

REDOとUNDOの違い

REDOとは、「以前の更新をもう一度行う」という意味です。
UNDOとは、「更新したものを取り消す」という意味です。

REDOにはREDOログが必要になります。
REDOログは、1つ1つの更新履歴のことです。
データベースに登録されている、リカバリ(修復)が必要なデータの修復作業の為に利用されます。

UNDOにはUNDOレコードが必要になります。
UNDOレコードは、更新前のデータそのものです。
データベースに登録されているデータの更新情報を取り消す為に利用されます。

REDOとUNDOのイメージ

まず、REDOログによるリカバリ作業と、UNDOレコードによる更新取り消し作業のイメージを掴み易くするために、以下の例を想像してみてください。

1. 記憶喪失になった人がいたとします。
あなたはこの人の記憶を取り戻させるために、何をすればよいでしょうか。
…この人の最後の記憶から現在に向かって、時系列に沿ってその人に関わる情報を伝えると思います。

2. あなたはRPGゲームをしています。
ゲームの進行が気に入らなかったため、セーブせずにやり直すことにしました。
前回セーブした時点からやり直すためには、どんな情報が必要でしょうか。
…当然、前回セーブした時点のデータが必要だと思います。

1.の例では、(記憶の)「リカバリ(修復)作業」、
2.の例では、(ゲーム進行の)「更新情報の取り消し」を行っています。

データベースにおけるデータのリカバリ作業や更新取り消し作業も、同じような情報が必要になります。
これらの機能に絡めて言うと、1.の「記憶喪失になった人」は、『リカバリ(回復)が必要なデータ』であり、「その人に関する情報」は、『更新履歴情報(=REDOログ)』です。
このように、REDOログを使って過去のデータを最新の状態にすることを『ロールフォワード』といいます。

2.の「RPGゲーム」は、「更新作業を行うデータ」であり、「前回セーブした時点のデータ」は、『更新前のデータそのもの』(=UNDOレコード)です。
このように、UNDOレコードを使って更新情報を取り消すことを『ロールバック』といいます。

つまりリカバリ(修復)には、更新履歴情報(=REDOログ)が必要であり、更新情報の取り消しには、更新前のデータ(=UNDOレコード)が必要であるということです。なんとなくイメージは掴んで頂けたでしょうか。

それでは、REDO、UNDOのアーキテクチャーがどのようになっているのかを紹介します。

REDOのアーキテクチャー

電源障害やハードウェア障害などでインスタンス(メモリとバックグラウンドプロセス)が異常終了した場合は、再起動時に自動リカバリされます(インスタンスリカバリ)。物理ディスクが破損した場合はユーザが明示的にリカバリを実行します(メディアリカバリ)。
インスタンスリカバリやメディアリカバリの際にREDOログが必要になります。

REDOログは、Oracleデータベースを構成するファイルの1つ「REDOログファイル」に格納されますが、このファイルがないとリカバリ作業が出来なくなりますので、冗長化する為にREDOログファイルを「メンバー」と「REDOロググループ」というもので構成します。
1つ以上のメンバーで構成される「REDOロググループ」というファイルグループ単位で、メンバーそれぞれに同じ内容のREDOレコードを格納します。
「REDOロググループ」はREDOログファイル内に2つ以上構成し、REDOロググループが容量いっぱいになると循環的にREDOロググループが切り替わる仕組み(ログスイッチ)で運用します。その際、同じレコードが書き込まれたメンバーは、ディスク障害による全滅を防ぐために異なるディスク上に配置します。

また、ARCHIVELOGモードという設定をしていると、ログスイッチが1周して古いREDOログが上書きされる際、そのREDOログを使ったリカバリ作業が出来なくならないようにするために、長期的なREDOログを溜めておくためのファイル「アーカイブREDOログファイル」に保存します。

このようにして、REDOログの損失によるリカバリ不可のリスクを減らすアーキテクチャーになっています。

UNDOのアーキテクチャー

データの更新作業を取り消すロールバック作業や、データの整合性を維持する為にデータへの検索処理に対してある時点のデータを検索開始後に、実行された処理があったとしても検索開始時のデータを返す「読み取り一貫性」の保証、時間軸を移動して過去の状態のデータを表示したり過去の状態にリカバリするためのフラッシュバック機能を実行するためにはUNDOレコードが必要になります。

UNDOレコードは、UNDO表領域という領域のUNDOセグメントに格納され、容量がいっぱいになったら古いUNDOレコードに上書きしていきます。
基本的に処理中のトランザクション1つに対しUNDOセグメント1つを使うように動作します。UNDOセグメントはトランザクションが完了すれば基本不要になるので上書き可能になります。
上書きを防ぐために格納したデータの保存期間や、領域の自動拡張を有効にする設定もあります。

REDOとUNDOのまとめ

このように、REDOとUNDOは混同しやすいですが内容や目的、アーキテクチャーが異なります。
REDOとUNDOのデータの違いを表にまとめましたので、確認しておきましょう。

  REDOデータ UNDOデータ
内容 変更を再現する為のデータ 変更前のデータ
目的 インスタンスリカバリ、メディアリカバリ 読み取り一貫性の保証、ロールバック、フラッシュバック
格納場所 REDOログファイル UNDOセグメント
保護の対象 データの損失 一貫性のない読み取り
アーカイブ 必要(アーカイブREDOログファイル) 不要(トランザクション完了後には上書き可能になる。)

この記事に関連する講座

人気の資格を合格サポートで完全カバー!

詳しくはこちら