REDOログに関する検証 その１６
＜ REDOログに関する検証 その１６ ＞ ペンネーム つけまい
— 内部構造を理解し
パフォーマンスの向上に役立てる —
前回は、ラッチ・タイムアウトの検出および、REDOアロケーション・ラッチ、
REDOコピー・ラッチの競合の低減方法などについての解説を行った。
今回は、チェックポイントについての解説を行う。
＊＊＊＊＊＊＊＊ チェックポイント ＝ リカバリの単位 ＊＊＊＊＊＊＊＊＊
１つのトランザクション（コミットまたはロールバック）毎に、
SCN（System Change Number）が割り振られている。Oracleは、このSCNを基に
リカバリを行う。つまり、障害が発生すると、前回のチェックポイントが起き
た時点までさかのぼり、シーケンスに割り振られているSCNを基に、若い番号か
ら順にそのトランザクション処理を忠実に再現してリカバリを行うのである。
この、トランザクション毎に割り振られていくSCNを、ある基準（REDOの情報量
または前回のチェックポイントからの経過時間など）を基に、いくつかの塊に
分けるという一連の処理を総称してチェックポイントと呼ぶ。
したがって、チェックポイントを発生させる間隔が短ければ短いほど、リカバ
リに要する時間も短く済ませることができるのである。ここで、いうリカバリ
とは、インスタンスリカバリのことである。ディスク障害などのときのリカバ
リは、チェックポイントの回数に依存しないので注意してほしい。
＊＊＊＊＊＊＊ チェックポイントを多発させてはいけない ＊＊＊＊＊＊＊＊
前述したように、チェックポイントの間隔が短いと、リカバリに要する時間が
短縮される。しかし、チェックポイントにはパフォーマンスに影響を及ぼして
しまう要素が、数多く含まれている。
チェックポイントが発生すると、現在のデータベース・バッファの内容のうち、
更新されたブロック（ダーティ・ブロック）を全てファイルに掃き出す（通常
は、パフォーマンスに影響を与えない程度に、小出しに書き込みを行う）とい
う作業が発生してしまう（チェックポイントとの整合性を保つため）。
また、この作業のために必要となるダーティ・リストは、本来であれば、ユー
ザのバックグランド・プロセスがLRUリストを検索して作成するものなのだが、
チェックポイント発生時には、この作業をDBWRが行うことになる。
これらの作業のために、DBWRがフル稼動してしまうと、当然のことながら、シ
ステムには通常以上の負荷がかかることになる。
また、この作業が終了するとDBWRはLGWRに処理が終了したことを報告する。す
ると今度は、LGWRが全てのデータファイルのヘッダー情報に存在する
Checkpoint cntやSCNの更新を行う。
もし仮に、データ・ファイルが100個以上存在するシステムであれば、この処理
によるLGWRビジーでさらにシステムを遅延させてしまうことになる。
したがって、いくら障害発生時に備えるとは言え、そのために犠牲となるパフォー
マンスのことを考えれば、チェックポイントを多発させることのメリットより
も、デメリットの方がはるかに大きいに違いない。
なお、LGWRに代わって全てのデータファイルのCheckpoint cntやSCNの更新を行う
プロセスとしてCKPTがある。CKPTは、Oracle7.3までは、初期化パラメータの
checkpoint_processというパラメータで起動するかを決めていたが、Oracle8から
デフォルトで起動するようになった。
次回は、チェックポイントの発生を操作する方法などについての解説を行う予
定である。
以上 秋本番を迎えた茅ヶ崎にて