REDO ログ・ファイル
REDO ログとは、データベースに対して行なった操作を REDO(再実行) するためのログ＝作業履歴情報で REDO ログ・エントリ*1の集まりである。(REDO のアトミックな単位をチェンジベクターと呼ぶことがある。Redo Change Vecotor：直訳すると「変更の軌跡」)
REDO ログ・ファイルは、その REDO ログを保存しているファイルでオンライン REDO ログ・ファイルと
履歴のバックアップであるアーカイブ REDO ログ・ファイルに区別される。
ある時点の全体バックアップとバックアップ以降の REDO ログを保存したファイルが保管されていれば
データベースを任意の過去の状態にリカバリすることができる。もし REDO ログがひとまわりしていなければ
アーカイブ REDO ログが無くてもよい。
つまり REDO ログ・ファイルはバックアップしたファイルと同じ価値があり、
耐障害における最重要ファイルと言い換えることができる。
しかし REDO ログ・ファイルはその性格上から過去の SQL を閲覧したいという特別な要件がない限りは、
一旦書き込まれた情報は再度読み込まれることがほとんどない。(※)
(※) おそらく一番身近なところで利用されている例は クラッシュ・リカバリ である。
しかし、インスタンスのバックグラウンドプロセス が自動的に行なっている
作業なので使われていることも意識されていない。
REDO ログの書き込み処理はトランザクションの応答速度に直結している
これはトランザクションの COMMIT 処理において REDO ログの内容を REDO ログ・ファイルに書き込みし、
その書き込み処理が正常に完了するまでは COMMIT の応答がユーザーに戻ってこないからである。(※)
(※) Oracle 10g R2 からは応答性能を高めるため REDO ログ・ファイルへの書き込みが完了する前に
応答を戻すことができる COMMIT のオプションが追加されている。
これはリカバリにおけるリスクと引き換えに応答性能を速くするということである。
何度も同じ状態を再現実行できるバッチ処理などに向いている。
例) COMMIT WRITE BATCH NOWAIT
REDO ログの保管先
REDO には 「REDO 'セグメント'」という論理単位で管理されていない。REDO ログエントリを保存する先は 表領域（データブロック）ではなく、直にファイルである。Oracle における
オブジェクトのほとんどが データブロック というオラクルの
最小論理単位による管理枠に収められているが、REDO ログは異なる。
REDO ログの書き込み処理 (LGWR) に対しては、バッファを使用した遅延書き込みを行なうと電源断によってデータを損失する
ことになるため、データベースライタ (DBWR) のような書き込み処理とは異なるチューニングが施されている。
さらに制御ファイルのようにミラーリングすることができる機能も組み込まれていることからも重要性がわかる。
REDO ログの書き込みタイミング
REDO ログは REDO ログ・ファイルへの書き込みがボトルネックにならないよう、また、
データの損失を最小限にするために非常に小さな単位で書き込み処理が実行される。
REDO が書き込まれる条件 (Oracle 10g：将来変更される可能性あり）
- REDO バッファの 1/3 以上を消費
- COMMIT 時 (サーバープロセス経由)
- ダーティバッファの書き込み処理時 (DBWn 経由)
- 前回の書き込みから 3 秒経過時
REDO ログ・ファイルの保存先
インスタンスが稼動中にはシーケンシャルに書き込むだけのファイルであるために RAID5 に配置せずに
独立したディスクに配置するように書かれている。しかし、比較的に安価に RAID が構築でき、ドライブ 1 台あたり 2 テラバイトも一般化し、大容量化も激しい。省スペースな筐体とディスク容量の余りすぎによって一般的な案件では、この指標の実現は一層難しくなっているように思う。
REDO ログ・ファイルは複数のメンバにより多重化して使用するのが一般的。
アーカイブログ運用している場合には、グループが一巡する間にアーカイバプロセスによって REDO ログ・ファイルがアーカイブ(コピー)される。
REDO ログ・グループの追加
REDO ログ・グループを追加した場合、そのグループ番号とスイッチの順序には関係ないので注意！(10g)
カレントの次のスイッチでは追加したグループがカレントとなる。
グループ番号の大小は関係ないのです。(再起動してもその順番は変わらない)
そのため、カレント位置を見誤ると、次の REDO ログ・グループが同一ディスクに配置されるような事になる。
追加するタイミングをよく考える。(TPOでは ログスイッチをかけるのもあり)
┌→ SELECT * FROM V$LOG ;
└─ ALTER SYSTEM SWITCH LOGFILE ;
…
ALTER DATABASE ADD LOGFILE 〜 ;
オンライン REDO ログの手動アーカイブ
補足
現行の REDO ログ以前のログも含む 使用可能なすべてのスレッド (※)のアーカイブを実施し、アーカイブが完了するまでカーソルが復帰しない。(アーカイブはサーバープロセスによる処理らしい)
ALTER SYSTEM ARCHIVE LOG CURRENT ;
(※) アーカイバプロセスに処理が移った REDO ログが 「使用可能なすべてのスレッド」に含まれるかが判断できなかった。
オンライン REDO ログのアーカイブ処理の完了によりカーソルが復帰するだけで、アーカイバプロセスが処理中のものもすべてがアーカイブ済と限らない。という外部ベンダによる資料もネットで見たので大きなサイズの REDO ログファイルを使用している場合には心に留めておくが必要がありそうな内容である。
この作業 (ALTER SYSTEM ARCHIVE LOG CURRENT) は ARC でなくサーバープロセスの仕事らしいのであるが、
アーカイバプロセスとサーバープロセスが連携していれば済む話ではないのかな？・・・よくわかりません。(バージョンにより異なる可能性もある)
アーカイブ作業の登録を行い、即座に復帰する。(実際のアーカイブはアーカイバプロセスによる処理)
ALTER SYSTEM ARCHIVE LOG ALL;
参考：インスタンスとプロセス
関連事項
