待機イベント→キャッシュされているブロック競合の頻度を確認。空きリスト競合は、ブロック競合に現れるために指標としています。***”)の待機イベント→インスタンス間でキャッシュの要求、転送によるブロック競合を確認。時間が短くなる結果となりました。引き続き、ブロックの競合、グローバルキャッシュの競合で発生する待機イベントが、少ないのに実行時間が長くなってしまう現象を検証結果から見ていきましょう。検証の前提、パターンは、バックナンバーを参照してください。***”)の待機イベント先に、REDOログファイル関連の待機イベントを説明します。待機イベントREDOレコードをログバッファからREDOログファイルに書き込もうとして待ちになっている状態です。複数のREDOログファイルメンバへの書き込みは、パラレルで書き込まれます。待機イベントログバッファにデータを書き込む速度が、ログライタープロセスによる書出し速度を上回るため、ログバッファ内の領域を確保しようとして待ちになっている状態です。待機イベントREDOレコードをREDOログファイルから読み取る際に待ちになっている状態です。REDOログを再利用しようとしてログスイッチが待ちになっている状態です。待機イベントが、両ノードにて発生しています。内部的に、REDOレコードをREDOログファイルから読み取る際に待機イベントが発生しているようです。待機イベントが発生しています。待機イベントが発生しています。buffer”初期化パラメータで確保したログバッファーの領域が少なかったと考えられます。待機イベントが発生しています。(1)と比較すると、待機回数が増えて、平均の待機時間が少なっています。前回までの検証結果からすると、ブロックの競合、グローバルキャッシュの競合が、待機イベントの統計として現れているので、実行時間は長くなる結果となっています。待機イベントが発生し、両ノード共に待機時間が、大きくなっています。ブロック競合が少ないのに、実行時間が長くなってしまった理由の一つと考えられます。頻繁にログスイッチが、発生して待機イベントとして現れているようです。検証では、同時SQL(INSERT)で負荷をかけているので、REDOレコードが多く生成され、結果としてREDOログファイルのサイズが小さかったと考えられます。待機イベントが、両ノードにて発生しています。内部的に、REDOレコードをREDOログファイルから読み取る際に待機イベントが発生しているようです。2(テーブル作成時にStorage句を調整)は、グローバルキャッシュの競合に関連する待機イベントが少ないのに、実行時間が長いという検証結果となりました。この理由は、インスタンス間でのグローバルキャッシュの競合が少なくてもREDOレコードの生成、REDOログへの書き込みが頻繁に発生していることから、REDOログ関連の待機イベントによって実行時間が長くなっていたと検証結果から考えられます。buffer”)や、REDOログファイルのサイズの見直す必要があるかもしれません。FREELIST管理で作成したテーブルは、Storage句のパラメータを調整することにより、ブロック競合を軽減することができます。繰り返しになりますが、パラメータの値の決定にはテーブルへの同時アクセス数や、同時アクセスインスタンス数の把握が必要です。FREELIST管理よりも効率良く処理される結果となっています。今日は、ここまで来週は、本連載のまとめとして最終回を予定しています。間、お付き合いください。reserved.トップページ企業概要プライバシーポリシ。