第7回 続々・バッファキャッシュ関連の待機イベントとパフォーマンス統計情報を読み解く：しばちょう先生の試して納得！DBAへの道（改）（7）（2/3 ページ）

[柴田長，日本オラクル株式会社]

演習3：バッファキャッシュのサイズよりも大きな表の全レコードを読み込んだ後のバッファキャッシュの状態を確認

　「SYS」ユーザーでV$BHビューへアクセスし、表TBS39_BIGのデータブロックのキャッシュの状態を確認します。

$ sqlplus /nolog
SQL>
/* バッファキャッシュ上にキャッシュされているオブジェクトとサイズの確認 */
connect / as sysdba
col OWNER for a8
col OBJECT_NAME for a24
select OWNER, OBJECT_NAME, count(*) "BUFFERS", count(*)*8/1024 "MB"
  from V$BH, DBA_OBJECTS
 where OBJD = DATA_OBJECT_ID and OWNER = 'TRY' and V$BH.STATUS != 'free'
 group by OWNER, rollup(OBJECT_NAME)
 order by 4 ;
OWNER    OBJECT_NAME                 BUFFERS         MB
-------- ------------------------ ---------- ----------
TRY                                        1   .0078125
TRY      TAB39_BIG                         1   .0078125

　いかがでしょうか。ゼロではありませんでしたが、1ブロック（8KB）しかバッファキャッシュ上にキャッシュされていませんので、リファレンス・マニュアルに記載されている内容が証明されたということでしょう。おそらく、このキャッシュされている1ブロックは、実際のレコードが格納されているデータブロックではなく、表セグメントを構成するブロックの構成情報を管理しているブロックであると予想されます。この辺りにご興味のある方は、ぜひとも私と直接会話しましょう！

演習4：バッファキャッシュのサイズよりも大きな表の全レコードを読み込んだ際に発生する待機イベントを確認

　演習2のクエリを実行した際に、events 10046のSQLトレースを取得した結果を幾つかの待機イベントのキーワードでgrepして発生回数をカウントした結果が次です。

$ cat orcl_ora_7943.trc | grep "db file" | wc -l
2
$ cat orcl_ora_7943.trc | grep "direct path read" | wc -l
349
$ cat orcl_ora_7943.trc | grep "direct path read" | cut -d " " -f13 | sed -e "s/cnt=//" | awk '{m+=$1} END{print m;}'
21928
$ expr 21928 \* 8 \/ 1024
171

　繰り返しになりますが、シングルブロック読み込み時の待機イベント「db file sequential read」とマルチブロック読み込み時の待機イベント「db file scattered read」は、いずれもディスクからバッファキャッシュ上への読み込みを示していましたが、バッファキャッシュのサイズよりも大きな表の全レコードを読み込んだ際には、これらの待機イベントは合計「2回」しか発生していませんね。

　代わりに「349回」と多く発生している待機イベントは「direct path read」でした。はい、この待機イベントこそ、バッファキャッシュをバイパスしてディスクからデータブロックを読み込んだ際に発生するかもしれない待機イベントとなります。「かもしれない」と表現した理由はちょいと解説が難しいので、より高度な知識が欲しい方へのTipsとなります。ご興味があれば次を読んでみてくださいね。

　バッファキャッシュをバイパスしてディスクからマルチブロックを読み込む場合には、待機イベント「db file scattered read」は発生しません。代わりに待機イベント「direct path read」が発生しますが、これが少し厄介な奴です。というのも、待機イベント「db file scattered read」はマルチブロック読み込みをした場合には必ず発生しますが、待機イベント「direct path read」は発生しないことがあります。これはリファレンスマニュアルにもちょっと分かりづらい記載がある通り、そういうものなのです。

ダイレクト・パス処理中に、データはデータベース・ファイルに非同期的に読み取られます。セッションのある段階で、ディスクに対する未処理の非同期I/Oの処理をすべて完了しておく必要があります。この処理は、ダイレクト読取り中に未処理のロード要求(1つのロード要求が複数のI/Oで構成されることもある)を格納するためのスロットがなくなった場合にも必要になることがあります。

　よって、events10046のSQLトレースで待機イベントdirect path readが発生した際のブロック数を合計しても、171MB（＝21,928[Blocks]×8[KB]）にしかならず、表TAB39_BIGのセグメントサイズの208MBには達していませんね。