差分表示

OracleのREDOログ周りの知識メモ(ログスイッチなど)
//parent=Oracle
&include_htmlfile(oracle/redolog,http://kamoland.com/oracle/);
*REDOログ周りのメカニズム (Oracle)

REDOログは，一言でいうと「データベースに対して行った変更の履歴」です．

もしデータベースが破損してしまった場合は，このREDOログが修復の手がかりになるため，
障害からのリカバリにおいて，非常に重要な役割を果たします．

この文書では，私がOracle Master試験(9i DBA II)の勉強を行った時にまとめた，
自分なりのREDOログ解釈について記述しています．
そう見当はずれなことは書いていないと思いますが，鵜呑みにはしないでください．

----


**REDOログの基礎
***更新処理
更新時は，以下の処理を行います．

+更新後情報をREDOログバッファとデータベースバッファ，更新前情報をUNDO領域に書き込む [サーバプロセス?]
+Commit要求が発生すると，REDOログバッファの内容を，REDOログファイルに書き込む．
(これは，Commit要求以外でも起こります) [LGWR]

このように，

-データベースバッファ
-UNDO領域 (データベースバッファ割り当て)
-REDOログファイル

への書き込みを繰り返します．
''REDOログファイルだけが''「ファイル」であることに注意してください．
その他はメモリ上で済む操作です．
I/Oをできるだけ減らそうという設計意図が，窺えます．

とは言え，LGWRのI/O頻度はトランザクション単位という高頻度なので，
LGWRの動きが，パフォーマンス上かなり効いてきそうです．

REDOログファイルは，順番に追記してゆくというシーケンシャルアクセスなので，ディスク使用の競合がなければ
(そのディスクをREDOログファイルで占有できれば)，
ヘッドのシークにかかる時間を最小限に抑えられます．
REDOログファイルは，独立した専用のディスクに配置するのが望ましいということになります．

REDOログファイルへの書き出し以外はメモリ上の処理で完結する，というのが理想ですが，
実際にはデータベースバッファのサイズには限界があるので，
適宜データファイルへの書き出しが発生します [DBWR]．以下のタイミングです．

+使用済みバッファがしきい値に達したとき
+サーバプロセスが要求する数のバッファを確保できないとき
+タイムアウト発生時
+チェックポイント発生時

1,2はそのものの理由．3はよくわからん．

4は，REDOとデータファイルを同期化するために必要です．
チェックポイント発生時にはデータファイルヘッダのSCNが更新されますが，
ヘッダだけでなく内容もそのSCN時点のものになっていないと変ですわな．
----


***REDOログファイルが一杯になったとき
更新処理を繰り返して，LGWRがガシガシ書き込んでいくうちに，
REDOログファイルが一杯になってしまいます．このときは，以下の動作が行われます．

+REDOログファイルが一杯になると，チェックポイントが発生する [LGWR]
+チェックポイントが発生すると，以下の処理を行う
++データベースバッファの内容を，データファイルへ書き出す [DBWn]
++使用するREDOログファイルを，グループ1から2へ変更する (ログスイッチ) [LGWR]
++全データファイルヘッダと制御ファイルのSCNを更新する．制御ファイルのログ順序番号を+1する [CKPT]

これにより，LGWRは新しいREDOログファイルを使えるようになります．

なおARCHIVELOGモード運用の場合は，すかさずARCnが起動して，
これまで使っていたREDOログファイルを別ファイルにバックアップしてくれます．

2-iii.について補足すると，制御ファイルのログ順序番号が+1されるというのは，
REDOログファイルが切り替わるのだから良いとして，SCN更新とは何か？．．．

通常は，各データファイルがヘッダに持っているSCNは，てんでばらばらに増加してゆきます．
一般には，データファイルごとに更新の発生頻度は異なるので，
データベースバッファからの書き出しの発生タイミングもばらばらだから，当然です．

しかし，このチェックポイントのタイミングでは，
一旦全てのデータファイルのSCNを統一し，そのSCNを制御ファイルに記録します．

全てのデータファイルのSCNが統一されていて，制御ファイルの値と一致しているという状態
(同期状態)は，
Oracleがデータベースをオープンするための必須条件です．
この状態にする行為をリカバリと呼びます．

では，なぜREDOログが一杯になったタイミングで，チェックポイントを行う必要があるのか？
という疑問があるのですが，これはよくわかりません．

各アーカイブログファイルについて，適用結果のSCNがデータファイルごとに違っているという状態だと，
リカバリ処理がかなり複雑になるように思うので，そのあたりかなと想像しています．
----


**REDOログファイルへの書き込みタイミング
前述の更新処理では，以下のように書きました．

+更新後情報をREDOログバッファとデータベースバッファ，更新前情報をUNDO領域に書き込む [サーバプロセス?]
+Commit要求が発生すると，REDOログバッファの内容を，REDOログファイルに書き込む．
(これは，''Commit要求以外でも''起こります) [LGWR]

この，Commit要求以外の書き込みタイミングについて，検討します．以下になります．

+REDOログバッファの3分の1がいっぱいになったとき
+タイムアウト(3秒)の発生時
+1MBのREDOレコードがあるとき
+DBWnが使用済みバッファをデータファイルに書き出す前
+トランザクションがコミットされた場合

まず，5.ですが，これにより，Commitされたトランザクションはリカバリが保証されることになります．
(ちなみに，未Commitのトランザクションは，リカバリ対象でない)

1〜3は，数字の根拠はよくわかりませんが，未Commitであっても適宜ファイルに吐き出すということでしょう．
なぜか？バッファがあふれることを警戒しているのか？

4もよくわかりません．更新後情報がデータベースバッファにあろうとデータファイルにあろうと，
LGWRの処理には無関係に思えてしまいます．

あと，1〜4で，未CommitのトランザクションをREDOログファイルに書き込んでも問題ないのか？
という気がしますが，これはREDOレコードにコミット情報を持っているので，
これで判断しているのかな？

とまあ，色々不明点があります．実際に使う分には問題ないのですが，
試験勉強の場合は何か理屈をつけて覚えようとする
(そうでもしないととても覚えられん．．．)ので，気になります．

© 2023 KMIソフトウェア