スムーズに実行するためや、データの整合性を保つために必要な内部的なロックが働くために発生しています。処理速度を低下させることがあり、さらに特定の処理だけではなくデータベース全体のパフォーマンスを低下させる場合もあります。今週は次なる待ちイベントへ向かいましょう。難敵はまだまだいます。解析され必要なデータをバッファ・キャッシュ上で探し当てるところまでやってきました。データがすべてメモリ上に存在すればそれに越したことはありませんが、世の中そんなに甘くはありません。ストレージからデータを読み込む羽目になります。今回の待ちイベントも皆さんご存知ではないでしょうか。これらの待ちイベントが発生している様子を見てみましょう。調べることでもわかります。トレースを見ていきます。そのほうが具体的な発生状況が見えてくると思いますので。発生することが前提なので、一旦、バッファ・キャッシュをクリアしておきましょう。トレースをセットします。実行してトレースを取得します。指定されたディレクトリに出力されます。selected.トレースを取ったら設定は元に戻しておきましょう。altered.さて、どんなトレースが取れているでしょうか。以下に、対象のSQLの部分を抜き出してみました。-----------------------------------------------------最初のほうに今回狙った待ちイベントが出ていますね。部分を細かく見てみます。待ちが発生しています。どちらが複数ブロック読み込んだときの待ちイベントかはこれで確認できましたね。気をつけたいのは、V$SYSTEM_EVENTなどのでこれらの待ちイベントをチェックしているときです。ボトルネックにより、インデックス検索などのシングルブロックへのアクセスが遅くなることが良くあります。大きくなることがあるので(名前の問題もありますが)こちらを全件検索の待ちイベントだと勘違いしてしまうことがあります。|------------------------------------------------------------------------------ということで、実は全件検索でした。インデックス検索による待ちイベント」でもない。単独ブロック読み込みによる待ちイベント」ということです。同じ解説はどこかしらで見かけているはずなのですが、しばらくチューニングの現場から離れていると皆さん忘れてしまうことが多いようです。来週もこのイベントをもう少し見ていきましょう。reserved.トップページ企業概要プライバシーポリシ。