SSJ Tech Lab - Oracle Database テクニカルラボ

REDOログ概要

対応バージョン

Oracle Database 10.1 - 12.1

2015-03-16記事を概要と操作に分割、項目の詳細化と補足

2015-01-31記事公開

REDOログの概要について記載します。
REDOログの追加などの操作については以下を参照して下さい。
REDOログ操作

REDOログ概要

REDOログ・ファイル

REDOログ・ファイルはRMANリカバリやインスタンスリカバリに使用するログ・ファイルです。
REDOログ・ファイルには、REDOレコードが書き込まれます。
REDOレコードにはデータベースに対するすべての変更が記録され、記録されたデータはリカバリに使用できます。
データのコミット(確定)はREDOログ・ファイルに書かれた時点で行われ、データファイルへの書き込みを待たずにコミットされます。つまり、データファイルにデータがない状態でもREDOログファイルにデータがあれば、整合性を確保できるため、その時点でデータが確定されます。

REDOログ・ファイルの循環

REDOログ・ファイルは同じファイルを循環方式(繰り返し再利用する方法)で使用します。ログが循環されて次のログが使用開始されることをログスイッチといいます。

以下の条件により再利用できるようになります。

アーカイブが使用禁止になっている場合(データベースがNOARCHIVELOGモードのとき)
一杯になったREDOログ・ファイルは、そこに記録された変更がデータファイルに書き込まれた後に使用可能になります。
アーカイブが有効の場合(データベースがARCHIVELOGモードのとき)
記録された変更がデータファイルに書き込まれ、さらにそのファイルがアーカイブされた後、一杯になったREDOログ・ファイルをLGWRで使用できるようになります。

REDOログ・ファイルのグループ

REDOログ・ファイルは、REDOログを循環させて使用するために、2つ以上のREDOログ・ファイルから構成されます。(2グループ以上で循環を行う)
グループ数が2であると、1つのREDOログ・グループが破損した場合にデータベースの稼働を続けることが出来ない為、基本は3~4グループ以上で構成します。
また、REDOログが多く発生し、ファイルの循環が早かった場合などに、グループ数が少ないことでログスイッチ待機の発生が懸念されます。

REDOログ・ファイルのメンバー

REDOログ・ファイルはグループごとに冗長構成をとることができます。メンバーは慣例的に2メンバー以上で構成することが多くなります。
別のディスクに配置することで、一つのメンバーがディスク障害やブロック破損などにより破損した場合に、データベースの整合性が保つことが出来ます。(Oracleが搭載されるストレージの殆どはRAIDによる冗長化を使用していることが殆どのため、そのような場合は論理破損やRAIDの再構成時のブロック破損など二重障害に対する対応となります。)

アーカイブ・REDOログ・ファイル(古いREDOログを保存したファイル)

アーカイブログモードで運用している場合、REDOログはログ・ファイルの循環時にアーカイブ・REDOログ・ファイルを生成します。アーカイブ・REDOログ・ファイルには循環時にそれまでREDOログ・ファイルに書かれたREDOレコードが記録されています。(RMANなどを使用したデータベース・リカバリに使用されます。)
アーカイブログ・REDOログ・ファイルがない場合、データベース・リカバリ時にバックアップした地点までしか戻すことができません。その後の変更がREDOレコードに順番に記録されているためです。

REDOログのパフォーマンス影響

循環による再利用などに時間がかかり、REDOログの書込み待ちが発生する場合は、データベースに待機時間が発生し、データベースがその間、更新に対して停止(ハングのような)状態となります。

このような書き込み待ちなどがある為、REDOログのディスクI/O速度、スイッチ頻度、グループ数、サイズの決定はパフォーマンスに影響を及ぼします。

RAC(Realtime Application Clusters)環境でのREDOログ

Oracle Databaseを構成する各インスタンスに専用にREDOログが割り当てられます。
例えば2ノードRAC(Real Application Cluster)の場合、3つのグループを2つのメンバーで作成する場合
3グループ * 2メンバー * 2インスタンス = 12ファイルの構成となります。

各インスタンスに割り振られたREDOログは、インスタンス障害後のインスタンスリカバリにも使用されます。