read by other session

概要

　read by other session待機イベントは、buffer busy waits待機ベントと同じくバッファ・ロック競合と関連があります。read by other session待機イベントが発生する状況は以下の通りです。

• ディスクから読込んだブロックをバッファ・キャッシュにキャッシュしようとするプロセスAは、該当ブロックに対してバッファ・ロックを排他ロック・モードで獲得します。
• 同じブロックを読もうとするプロセスBは、該当ブロックに対してバッファ・ロックを共有ロック・モードで獲得しようとします。
  プロセスAがバッファ・ロックを排他ロック・モードで獲得したままブロックを読んでいるので、このプロセスBはプロセスAの作業が終わるまで待機しなければなりません。
• プロセスAがブロックをディスクからメモリーに読込むまでプロセスBはread by other session待機イベントで待機します。

　read by other session待機イベントはOracle10gで追加されたものであり、 Oracle9iでのbuffer busy waits待機イベントがこれに該当します。

待機パラメータと待機時間

待機パラメータ

read by other session待機イベントの待機パラメータは以下の通りです。

• P1 ： ファイル番号
• P2 ： ブロック番号
• P3 ： ブロック・クラス

​​​​​​​
待機時間

最大1秒まで待機します。

チェックポイントと解決策

　read by other session待機イベントは、ブロックをディスクからメモリーに読込む際に発生します。
　従って、待機時間がそれほど長くなければ特に問題にはなりません。もし、read by other session待機イベントの待機時間がかなり長い場合は、SQLチューニングなどにより物理I/Oの作業量を減らさなければなりません。また、同時に多くのプロセスが同一ブロックをアクセスしないようにアプリケーションの修正も考慮する必要があります。

　また、read by other session待機とともにdb file sequential read、db file scattered read待機のようなI/O待機現象がいつも同時に発生することに注目しなければなりません。なぜなら、read by other session待機はその性質上、常に物理I/Oとともに発生するからです。しかし、read by other session待機が発生した同一環境でも、データが既にバッファ・キャッシュにキャッシュされている場合には物理I/Oは発生しないので、当然read by other session待機及びdb file sequential read、db file scattered read待機現象も自然に発生しないようになります。

豆知識

　read by other session待機イベントは、Oracle9iでのbuffer busy waitsがOracle10gでは待機イベント名が変更されただけであるため、buffer busy waits待機イベント(公開予定)の豆知識をご参照ください。

分析事例

非効率なSQLによるバッファ・ロック待機現象(9iまで)

　read by other session待機イベントは、Oracle9iでのbuffer busy waitsがOracle10gでは待機イベント名が変更されただけであるため、ここでは、9iでのbuffer busy waits待機イベントの分析事例を紹介することでread by other session待機イベン現象を確認します。

　MaxGaugeの「セッション・リスト」画面で、ある時間帯でbuffer busy waits(id 130)待機イベントでの待機によりSQLの実行時間が50秒以上のセッションが発見されました。

　グラフを見ると、1つのセッションはdb file sequential read待機イベントで待機しながらブロックをバッファ・キャッシュにロードしていますが、これと同じSQL文を実行しているセッションは該当ブロックがロードされるまでbuffer busy waits待機イベントで待機していることが分かります。

下図の「アクティブ・セッション」と「session logical reads」、「physical reads」、「buffer busy waits」の推移グラフを比較してみると、buffer busy waits待機イベントが発生した時点でI/Oの増加が確認できます。

次の画面でMaxGaugeの「セッション・リスト」画面で buffer busy waits待機イベントで待機しているセッションを検索してみると、
同じSQL文を実行しているセッションのファイル番号とブロック番号を確認した結果、多数のファイルとブロックに渡ってbuffer busy waits待機イベントで待機していることが確認できます。

結論

　同じSQL文を同時に実行する場合、同じファイルとブロックに対して同時アクセスすることになるので buffer busy waits待機イベントが発生します。

　つまり、これはホット・ブロックの問題ではなく同時にSQL問合せを実行したためであり、SQL文をチューニングすることによって同時実行におけるI/O競合を最小化しなければなりません。

　従って、まずはSQLチューニングが必要で、チューニングの目標は最小限のI/Oで問い合わせの結果を得ることです。SQLチューニング後、同じブロックへのアクセスでbuffer busy waits待機イベントで待機するようであればホット・ブロック問題を疑ってみましょう。