
write complete waits - 日本エクセム株式会社 Oracle待機イベント情報
目次[非表示]
- 1.基本情報
- 2.待機パラメータと待機時間
- 3.チェックポイントとソリューション
- 3.1.低速I/Oサブシステム
- 3.2.DBWRの負荷があまりにも多い場合
- 4.豆知識
基本情報
サーバプロセスがDBWRプロセスによってディスクに記録されているブロックを変更しようとする場合には、変更が終わるまで待たなければならず、待っている間write complete waitsイベントを待機します。
write complete waits待機は、buffer busy waits待機と同様にbuffer lock競合による待機に分類することができる。DBWRはダーティバッファをディスクに記録している間、バッファのbuffer lockを排他的に獲得します。この時、バッファを読んだり、変更したい他のプロセスは、この作業が終わるのを待って、write complete waitsイベントを待機することになります。
write complete waits待機が普遍的に表示される場合は、アプリケーションの問題というよりはDBWRのパフォーマンスの問題である可能性が非常に高くなります。サーバプロセスがディスクに書き込まれているバッファを読み取る確率が、実際には高くないのに、これによる待機を経ることはDBWRがダーティバッファを記録する時間が過度に長いことを意味します。DBWRの性能が遅い理由は、色々ありますが、ほとんどは、次のカテゴリに入ります。
待機パラメータと待機時間
待機パラメータ
write complete waitsイベントの待ち行列は次と等しい。
待機時間
1秒
チェックポイントとソリューション
低速I/Oサブシステム
free buffer waits#低速のI/Oサブシステムを参照してください。
DBWRの負荷があまりにも多い場合
頻繁にチェックポイントが発生した場合、DBWRの活動量が過度に多くなって、これにより、DBWRのパフォーマンスが低下することになります。DBWRのパフォーマンスの低下は、システムの全体的なパフォーマンスの低下に直結します。 FAST_START_MTTR_TARGET値を過度に小さくすると、頻繁に増分チェックポイント(Incremental Checkingpoint)作業が発生することになります。 REDOログ・ファイルのサイズが小さすぎる場合、頻繁にログファイルのスイッチ(log file switch)が発生することになって、これにより、チェックポイント処理が増加します。Parallel Queryによりdirect path readが発生した場合には、truncate、drop、hot backup時にもチェックポイントが発生します。もし、I/Oシステムのパフォーマンスの問題がないのに、write complete waits待機が表示される場合DBWRに余計な負荷を与える要素がないか調べる必要があります。
間接的にDBWRのパフォーマンスを向上させる方法として、複数のバッファプール(multiple buffer pool)を適切に使用することも推奨されています。システムで一般的によく使用されるオブジェクトは、Defaultバッファを使用し、それよりは程度が低いが比較的定期的に使用されるオブジェクトは、Keepバッファプールに常に常駐させます。最後に、使用頻度が少ないオブジェクトは、Recycleバッファプールを使用します。Keepバッファプールに常駐されたオブジェクトは、比較的、ディスクに記録されている頻度が低くなってこれによりwrite complete waits待機回数が減ることになります。加えて、KeepバッファプールとRecycleバッファプールは、それぞれ別のcache buffers lru chainラッチを使用するため、ラッチの競合を減少させる効果もあるのです。複数のバッファプールはDBWRの性能とは直接の関係はありませんが、バッファ・キャッシュの効率を高めることで、メモリに常駐するデータが不必要にディスクに書き込まれる頻度を下げ、これによりwrite complete waits待機が発生する確率を下げます。
オラクル8i以前はwrite complete waits待機の主犯でwrite batch sizeが挙げられました。 write batch sizeが大きいDBWRが記録される時間が長くなって、これによる待機が発生するようになるのですが、8i以降では、write batch sizeによるパフォーマンスの問題は消えました。
豆知識
FAST_START_MTTR_TARGETと書込み完了待ち
FAST_START_MTTR_TARGETを変更しながら余分なチェックポイントがwrite complete waits待機とパフォーマンスにどのような影響を与えるかをテストしてみましょう。テストシナリオは次のとおりです。
FAST_START_MTTR_TARGET=1の値を与えて、非常に頻繁にチェックポイントが発生するようにした場合、V$ SYSTEM_EVENTを通じて確認し、スタンバイ現状とV$ SYSSTATを介して確認したチェックポイント関連の統計値は、以下の通りです。
FAST_START_MTTR_TARGET=600の値を与えてチェックポイントの頻度を減らした場合、V$ SYSTEM_EVENTを通じて確認し、スタンバイ現状とV$ SYSSTATを介して確認したチェックポイント関連の統計値は、以下の通りです。
上記のテストの結果を見ると、FAST_START_MTTR_TARGET=600の場合、増分チェックポイントの回数を減らすFAST_START_MTTR_TARGET=1の場合に比べて、write complete waits待機が大幅に減少するだけでなく、その他のすべての待機現象も全体的に少なく発生すること確認することができます。V$ SYSSTATビューでチェックポイント関連の統計値を検索してみると、頻繁にチェックポイント処理が待機時間の差をインポートされたことが分かります。もしシステム全体のデータの変更が非常に多くのチェックポイントによる負荷が生じると判断した場合、増分チェックポイントの周期を増やすことが問題を解決することができます。しかし、この場合に回復(Recovery)に多くの時間がかかる場合があることに注意しましょう。