Statspackとは Statspack設定 statspackでの情報収集 statspackレポートの出力 便利スクリプト Oracleチューニング講座 第18章　チェックポイントのチューニングを学ぶ 本章ではチェックポイントのチューニングについて復習します。 チェックポイントは、データベース・バッファ・キャッシュ内の全ての変更済みブロックをディスクに書き込む処理を行います。チェックポイントが多発するとディスク書き込みによる負荷が高くなり、パフォーマンスに影響が出る可能性があるため、チェックポイント発生頻度のチューニング方法について説明します。 チェックポイントの頻度 (1)チェックポイントのチューニング チェックポイントは、主に以下の場合に発生します。 ■以前のチェックポイントから、オンラインREDOログ・ファイルのサイズのうちの90％が使われた場合 ■ALTER SYSTEM CHECKPOINT文が実行された場合 ■初期化パラメータによる設定 　このパラメータにつきましては、次章の「第19章　チェックポイントに影響するパラメータの紹介」で詳しく説明 　します。 また、チェックポイントが発生すると、以下のことが行われます。 ■DBWnプロセスによる、全ての変更済みブロックのディスク書込み ■CKPTプロセスによる、データファイル・ヘッダーと制御ファイルの更新 チェックポイントの頻度による影響については、以下が挙げられます。 ■インスタンス障害時の回復時間の短縮 　インスタンス回復は、チェックポイント以降の変更履歴を必要とするため、チェックポイントを頻繁に発生させ 　るとインスタンス回復時間を短縮できます。 ■パフォーマンス低下 　DBWnプロセスやCKPTプロセスによる大量のディスク書込みが発生するため、チェックポイント時のパフォー 　マンスは低下します。 つまり頻度が高いとインスタンス回復時間は短縮できますが、パフォーマンスの低下が見込まれるため、共に適切な発生頻度にチューニングする必要があります。 チェックポイントの頻度はシステムの要件に合わせて様々です。 チェックポイントは大量の書込みを行うので、パフォーマンスを優先させる場合はあまり多発させるべきではありませんが、データベース・バッファ・キャッシュが非常に大きく更新処理が頻繁に行われるようなOLTPシステムの場合では、チェックポイントの回数が少ないと1回のチェックポイント時の負荷が高すぎる可能性があります。 このような場合は、チェックポイントの頻度を増加することを検討する必要があります。 チェックポイント時の負荷の調査については、チェックポイント発生時の負荷をOSコマンドなどを使用して確認したり、チェックポイントが開始してから終了するまでの時間に注意するなどで行います。 頻度の調整は基本的にはREDOサイズを調整します。これは上記でも説明している通り、チェックポイントの発生が以前のチェックポイントから、オンラインREDOログ・ファイルのサイズのうちの90％が使われた場合だからです。 条件によってどれぐらいでREDOログ・ファイルをスイッチさせるかは難しいですが、20分に1回程度が目安です。また、更新が頻繁なシステムの場合は5分に1回程度という事例もあります。 (2)チェックポイントの確認 インスタンス起動後のチェックポイント数は、V$SYSSTATビューのDBWR checkpointsで確認できます。 また、LOG_CHECKPOINTS_TO_ALERTパラメータをTRUEに設定すると、アラート（alert.log）ファイルにチェックポイントの開始・終了時間が書込まれます。このパラメータはTRUEに設定しておくことをお薦めします。 以下の表1にLOG_CHECKPOINTS_TO_ALERTパラメータの設定概要を記します。 表1 LOG_CHECKPOINTS_TO_ALERTパラメータ 概要 チェックポイントの情報をアラート・ファイルに書込むかどうか設定 構文 LOG_CHECKPOINTS_TO_ALERT = TRUE | FALSE デフォルト FALSE 変更の可/不可 可：ALTER SYSTEM 以下にV$SYSSTATビューを使用して、チェックポイントが発生した回数の確認例を記載します。 例）チェックポイントが何回発生したか確認する SQL> SELECT name,value FROM v$sysstat 2 WHERE name = 'DBWR checkpoints'; NAME VALUE -------------------- -------- DBWR checkpoints 7 NOTE ： オンラインREDOログ・ファイルのサイズはチェックポイントの頻度に大きな影響を与えます。 (3)チェックポイントの待機イベント チェックポイントに関連する待機イベントを以下の表2に示します。 特にlog file switch (checkpoint incomplete)が問題となっているケースが多いので注意してください。 表2：チェックポイントに関連する待機イベント イベント名 説明 db file single write チェックポイント時のヘッダー書込みに関連する待機。一般的にデータ・ファイルの数が非常に多い環境で発生する。 write complete waits サーバー・プロセスがアクセスしようとしたブロックが、DBWRプロセスによって書出し中だったときに発生する待機。DBWRの書出し遅延によって発生する場合がある。チェックポイント中に発生しやすいため、待機が長い場合はチェックポイントの頻度を調整する。 log file switch (checkpoint incomplete) チェックポイントが完了していないため、まだリカバリに必要なオンラインREDOログ・ファイルをLGWRが上書きしなければならなくなった際に発生する待機。チェックポイントが完了するまで上書きを待機する。通常、REDOログ・ファイルのサイズが小さすぎるか、ログ・ファイルのグループ数が少なすぎるために発生する。 log file switch(checkpoint incomplete)が発生するとアラート・ファイルに「Checkpoint not complete」というメッセージが出力されます。 チェックポイントによるLGWRの待機について、以下の図1で説明します。 図1：チェックポイントによるLGWRの待機 　 ファイル・サイズの90％が使用され、 チェックポイントが発生している状態です。 現在チェックポイント処理実行中で、 DBWnが前回のチェックポイント以降 の修正内容をデータ・ファイルに 書込む処理を行います。 チェックポイント処理実行中にLGWRがREDOレコードを書込み、 既存ファイルを使い切ります。 その後LGWRはオンラインREDOログ・ ファイルを上書きしようとしますが、 インスタンス障害からの回復に必要 なログがあるため、DBWｎによるそのログ の書き込みが終了するまで上書きできず LGWRは待機することになります。   図1のようなケースでは、チェックポイントの頻度が少なく、次回のチェックポイント時にDBWｎが書き込む変更履歴が多いために、LGWRが書き込みを待機するとパフォーマンス低下に繋がります。 チェックポイントによってパフォーマンスが低下しない為に、本章で記した内容を役立てていただければと思います。 以上でチェックポイントのチューニングについての説明は終了です。 次章では、チェックポイントに影響するパラメータについて紹介します。 　　　　　　　　　　　　　　　　　　　　　　　第19章　チェックポイントに影響するパラメータの紹介