1. Oracleデータベースでの データベースバッファキャッシュの 競合について 鈴木 健介

2. 本資料について Oracle で発生する待機のうち、データベースバッファキャッシュの 競合に着目して、どのような場合にどのような待機が発生するか、 考察した資料である。 なお、本資料の記述は下記のマニュアルを参照している。 ・概要 ・リファレンス ・データベース管理者ガイド ・パフォーマンス・チューニング・ガイド

3. アーキテクチャのおさらい SGA サーバプロセス DBWR ・データへのアクセスは原則的に DB バッファを経由して行われる。 データファイル Shared pool, Log buffer など その他領域 Database buffer

4. 発生しうるI/Oのパターン １．キャッシュ read ( サーバプロセス , DBWR) ２．キャッシュ write ( サーバプロセス、 DBWR) ３．ディスク read-> キャッシュ write （サーバプロセス ) キャッシュ上に目的のデータブロックがなかった場合。 ディスクからデータを読み込み、キャッシュ上に載せる。 ４．キャッシュ read-> ディスク write(DBWR) ダーティバッファ（更新が行われたブロック ) の書き出し 。 各処理が同時発生した場合にどのような競合が発生するか考察する。 それぞれ同一データブロックの場合、異なるデータブロックの場合、 双方について考える。

5. 前提条件 ・バージョンは 10.2.0 を想定する。 ・表ロック、行ロックなどの論理的な競合は発生していないものとする ・バッファキャッシュを介さない I/O については扱わない。 ( ダイレクトインサートなど ) ・レアケースの競合は網羅しきれないので、ここでは無視する （バッファキャッシュのチェイン競合など）

6. 同一データブロックでの競合 １．バッファ read ( サーバプロセス , DBWR) ２．バッファ write ( サーバプロセス、 DBWR) ３．ディスク read-> バッファ write （サーバプロセス ) ４．バッファ read-> ディスク write-> バッファ write(DBWR) ○ ：競合が発生しないケース X: 起きえないケース (*1) 同時にバッファにないブロックを参照するケースでは、 いずれかのプロセスがパターン３を担当する。競合としては、 パターン１とパターン３の競合と同じになる。

7. 同一データブロックでの競合：ケースA プロセス a: バッファ read または write プロセス b: バッファ write プロセス a がプロセス b の完了を待機する。 ・プロセス a 待機イベント： buffer busy waits 待機時間：メモリ write にかかる時間 ・プロセス b 待機イベント：特になし

8. 同一データブロックでの競合：ケースB プロセス a: バッファ read または write プロセス b: ディスク read-> バッファ write プロセス a がプロセス b の完了を待機する。 ・プロセス a 待機イベント： buffer busy waits 待機時間：ディスク read+ メモリ write にかかる時間 ・プロセス b 待機イベント： db file sequential read, db file scattered read 待機時間：ディスク read にかかる時間

9. 同一データブロックでの競合：ケースC プロセス a ：バッファ write プロセス b ：バッファ read-> ディスク write-> バッファ write プロセス b(DBWR) がダーティバッファの書き出しを行っている最中に プロセス a がバッファの変更を行おうとするケース。 プロセス a がプロセス b の完了を待機する。 ・プロセス a 待機イベント： buffer busy waits 待機時間：ディスク write+ メモリ write にかかる時間 ・プロセス b 待機イベント： db file parallel write 待機時間：ディスク write にかかる時間

10. 同一データブロックでの競合：ポイント ・競合しているときの待機時間は、ディスク I/O も含めて バッファの変更に必要な時間だけである。 例えば、変更されたブロックがトランザクションの持続期間中 ロックされている、ということはない。 ・ buffer busy waits にもその理由はいろいろある。 一応、待機イベントのパラメータで理由が数値コードで 示されているが、その意味するところは非公開情報であることが多い。 ・ buffer busy waits が発生したら、 他のプロセスの待機イベントにも着目することが必要。

11. buffer busy waitsを解消するには？ ・ 1 データブロックに格納されている行数を減らす。 - pctfree を増やす - ブロックサイズを減らす。 データの格納効率が落ちるというデメリットがある。 ・待たせている側のボトルネックを解消する。 ディスク I/O がネックになっている場合には、データファイルの分散や DBWR プロセスを増やすなどの対処ができる。

12. 異なるデータブロックでの競合 １．バッファ read ( サーバプロセス , DBWR) ２．バッファ write ( サーバプロセス、 DBWR) ３．ディスク read-> バッファ write （サーバプロセス ) ４．バッファ read-> ディスク write-> バッファ write(DBWR) ○ ：競合が発生しないケース X: 起きえないケース 異なるデータブロックでは、ケース B の特殊なケースを除いて、 原則としてロックによる競合は発生せず、 ディスク I/O の競合のみが発生する。

13. 異なるデータブロックでの競合： ケースA プロセス a ：ディスク read-> バッファ write プロセス b ：ディスク read-> バッファ write ロックによりお互いを待機させることはない。 ただし、ディスク read が同時発生するので、対象ファイルが 同一ディスク上にある場合は、処理が遅延する可能性がある。 ・プロセス a 待機イベント： db file sequential read, db file scattered read 待機時間：ディスク read にかかる時間 ・プロセス b 待機イベント： db file sequential read, db file scattered read 待機時間：ディスク read にかかる時間

14. 異なるデータブロックでの競合： ケースB1 プロセス a ：ディスク read-> バッファ write プロセス b ：バッファ read-> ディスク write-> バッファ write 多くの場合、こちらのケースになる。 ロックによりお互いを待機させることはない。 ただし、ディスク read,write が同時発生するので、対象ファイルが 同一ディスク上にある場合は、処理が遅延する可能性がある。 ・プロセス a 待機イベント： db file sequential read, db file scattered read 待機時間：ディスク read にかかる時間 ・プロセス b 待機イベント： db file parallel write 待機時間：ディスク write にかかる時間

15. 異なるデータブロックでの競合： ケースB2 プロセス a ：ディスク read-> バッファ write プロセス b ：バッファ read-> ディスク write-> バッファ write プロセス a がブロックをバッファに乗せるときに、空きバッファが 見つからない場合に起こるケース。 プロセス b の作業を待機し、バッファが再利用可能になるのを待つ。 このケースが頻発する場合は、データベースバッファキャッシュの 容量を増やすか、 DBWR の数を増やすなどの対処が必要となる。 ・プロセス a 待機イベント： free buffer waits 待機時間：ディスク write にかかる時間 ・プロセス b 待機イベント： db file parallel write 待機時間：ディスク write にかかる時間

16. 異なるデータブロックでの競合： ケースC プロセス a ：バッファ read-> ディスク write-> バッファ write プロセス b ：バッファ read-> ディスク write-> バッファ write DBWR を複数起動させているときに発生するケース。 ロックによりお互いを待機させることはない。 ただし、ディスク write が同時発生するので、対象ファイルが 同一ディスク上にある場合は、処理が遅延する可能性がある。 ・プロセス a 待機イベント： db file parallel write 待機時間：ディスク write にかかる時間 ・プロセス b 待機イベント： db file parallel write 待機時間：ディスク write にかかる時間

17. まとめ 本資料では、 Oracle のパフォーマンスのうち、データベースバッファの 競合に着目して、起きうるパターンを網羅的に考察した。 当然のことながら、本資料の範囲はデータベースのパフォーマンスの 一部であるため、実際のチューニングにはその他の要素も含めて 総合的に判断することが必要である。