データ・ページのバッファー・プール管理
バッファー・プール・ページの状況は使用中かそうではないか、およびダーティーかクリーンかで区別されます。
- 使用中 のページとは、現在読み取り中または更新中のページのことです。 ページが更新中の場合、更新者以外はアクセスできません。 しかし、ページが更新中でない場合、多数の同時リーダーがいてもかまいません。
- ダーティー・ページ には、変更されているがまだディスクに書き込まれていないデータが含まれています。
- そのページが最後に参照されてからの経過時間
- 再びページが参照される可能性
- ページに含まれるデータのタイプ
- メモリー内で変更されたページが、ディスクに書き出されていないか
クラッシュの発生時、またはオンライン・バックアップなどのデータベース操作の前には、FLUSH BUFFERPOOLS ステートメントを使用してデータベースのリカバリー・ウィンドウを縮小します。 詳しくは、FLUSH BUFFERPOOLS ステートメントを参照してください。
変更されたページは常に、上書きされる前にディスクに書き出されます。 変更されてディスクに書き出されたページは、スペースが必要になるのでない限りバッファー・プールからは自動的に除去されません。
ページ・クリーナー・エージェント
調整状態の良いシステムでは、通常、変更されたページ、つまりダーティー・ページをディスクに書き込むのはページ・クリーナー・エージェントです。 ページ・クリーナー・エージェントは、バックグラウンド・プロセスとして入出力を実行し、 実際のトランザクション作業をエージェントが実行できることでアプリケーションがより速く稼働できるようにします。 ページ・クリーナー・エージェントは、 他のエージェントの作業と連係しておらず、必要な場合にしか機能しないため、 非同期ページ・クリーナー や非同期バッファー書き込み機能 と呼ばれることもあります。
更新が頻繁に行われるワークロードでパフォーマンスを改善するために、先行ページ・クリーニング を使用可能にすることもできます。この方法では、特定の時点で書き出すダーティー・ページを選択する動作をページ・クリーナーが十分前もって行います。 これは、非同期のデータ・ページ書き込みや索引ページ書き込みの数に比べて データ・ページ書き込みや索引ページ書き込みの数が多いことが スナップショットによって明らかである場合に、特に当てはまります。
図 1 は、バッファー・プールの管理作業をページ・クリーナー・エージェントとデータベース・エージェントの間で共有する方法を示しています。
ページ・クリーニングと高速リカバリー
システムがクラッシュしたときのデータベースのリカバリーは、より多くのページがディスクに書き込まれている方が速やかに行えます。 より多くのページがディスクに書き込まれていれば、データベース・マネージャーは、 データベース・ログ・ファイルからトランザクションを適用することによって再構築できるバッファー・プールの部分より大きな部分を、ディスクから再構築できるからです。
- 最も新しく書き込まれたログ・レコード
- バッファー・プール内で一番古いデータ変更を記述するログ・レコード
ページ・クリーナーはダーティー・ページをディスクに書き込みますが、その際、ダーティー・ページがメモリー内でバッファーに入れられているのが最大で page_age_trgt_mcr 秒間になるようにします。
リカバリー時のログの読み取り時間をできるだけ短くするため、 データベース・システム・モニターを使用して、ページ・クリーニングが実行された回数をトラッキングしてください。 データベースに対して先行ページ・クリーニングを使用可能にしていない場合は、pool_lsn_gap_clns (起動されたバッファー・プール・ログ・スペース・クリーナー) モニター・エレメントがこの情報を提供します。 先行ページ・クリーニングを使用可能にしていた場合は、この条件は発生しないはずで、pool_lsn_gap_clns の値は 0 になります。
log_held_by_dirty_pages モニター・エレメントを使用して、ユーザーが設定したリカバリー基準を満たすだけの十分なページをページ・クリーナーがクリーニングしていないかどうかを判別することができます。 log_held_by_dirty_pages が常に logfilsiz * softmax よりかなり大きくなっている場合は、より多くのページ・クリーナーが必要であるか、または softmax を調整する必要があります。