write】さてさて、待ちイベントの検証も大詰めを迎えました。待ちイベントの最上位に来ていました。大きく設定してその効果を確認してみました。すると、待ちイベントの発生回数が下がり、待ち時間も減少していることが確認できましたね。待ちイベントが発生したのかおさえておきましょう。書き込めない状況が発生していることをあらわしています。これは前回の検証でも明らかになっています。増やせば待ちが解消したのですから。役割を整理しましょう。ログファイルに書き出す前に一時的にメモリ上に格納します。更新情報はたまるし、でもオンラインREDOログファイルにはまだ書き込めていないし、、、、という状況になる場合があります。出てしまうことが考えられます。ログファイルへの書き出しをスムーズにしてあげるという方法です。ログファイルへの書き出しがスムーズかどうかはどうやって判断すればよいのでしょうか。判断材料があると便利なのですが。書き込む際に発生する待ちイベント。REDOログファイルへの書き込みが滞っているかどうかを判断することができそうです。REDOログファイルへの書き込みで遅延が発生していると考えてよいでしょう。ログファイルへの書き込み量を減らす。無駄なインデックスを減らす。ログファイルを書き込み速度が高速なディスクへ配置する。I/O競合が発生しないようにホットファイルとは分ける。ログファイル関連の配置でよく言われていることです。内部の待ちイベントとどのように関連しているのか理解していただけたでしょうか?さて、次は前回の最後に少し触れた待ちイベントを見てみましょう。下記は、前回の説明文です。プロセスの書き込み処理の終了を待つ待ちイベント。サイズを変更する前でも後でも、大して発生していません。問題になるような待ちイベントではないように思われます。これは処理のパターンで大きく変わってきます。同じ環境で上記とは異なった処理をシミュレートしてみましょう。その結果、以下のような待ちイベントが出てきました。前回見てきた処理と、上記でシミュレートした処理の大きな違いは、前者はバッチ系の処理であったのに対し、後者はOLTP系の処理だった点です。簡単に違いを整理すると次のようになります。10セッションポイントは、OLTP系の処理で毎回commitしている点です。ファイルへ完全に書き込む必要があります。書き込めなければ処理が先に進まないのでここで待ちが発生します。自分自身が更新した処理の結果なので他の誰かにまたされているというわけではありません。自分以外のcommit待ちで待たされると待ちイベントとしてカウントされます。大きな違いをひとつ明確にしておきましょう。ともに待ちイベントではありますが、待たされているプロセスが異なります。発生する状況を間単に整理しておくと以下のようになります。処理が実施されデータが更新される。更新情報が記録される。処理が実施されデータが更新される。更新情報が記録される。