Oracleローカル書き込み待機およびenq：RO-高速オブジェクト再利用待機イベント説明
Oracle Local Write Wait
AWRで見られる ローカル書き込み待機 そしてenq：RO-高速オブジェクト再利用待機イベント。
1。ローカル書き込み待機説明を待っています
Webでのローカル書き込み待機の説明：
注1：
通常、DBWRは、ディスクから何かを読み取りたいときに、いくつかのバッファを解放する必要があります。このプロセス中に、ローカルバッファ（つまり、セッションによってダーティ/無効化されたブロック）がディスクに書き込まれるのを待つ可能性があります。この間、待機します。として表示されます ローカル書き込み待機 。
注2：
基本的に、「localwrite」待機は、セッションがそのローカル（独自の操作のために書き込みが保留されていることを意味します）writeoperationを待機しているときに発生します（名前が示すように）。これは通常、基盤となるディスクに重大な問題がある場合に発生する可能性があります（たとえば、RAID-05でのメンバーディスクのクラッシュの1つ、またはコントローラーの障害）。そのため、「通常のデータベースではこの待機は見られません！」と言ったかもしれません。これは、（まれに）大きなテーブルを切り捨てているときに、そのテーブルのほとんどのバッファがキャッシュにあるときに表示される場合があります。 TRUNCATEの間、セッションはローカルチェックポイントに到達する必要があり、このプロセスの間、セッションは「ローカル書き込み」待機を待機する場合があります。
基本的に、「ローカル書き込み」待機は、セッションが自身の書き込み操作を待機していることを意味します。通常のシステムではめったに発生しない、ディスクに重大な問題（RAID 5でのディスククラッシュやディスクコントローラーエラーなど）がある場合に発生します。 TRUNCATEに大きなテーブルがあり、そのテーブルがキャッシュにある場合、セッションはMake localcheckpointである必要があります。今回は、セッションはlocalsession待機を待機します。
MOSドキュメント：
切り捨てに時間がかかりすぎる... [ID 334822.1]
この待機イベントについて言及しました。
原因：
一時テーブルが切り捨てられ、複数の並行バッチストリームに再入力されるプロセスでは、この状況が発生する可能性があります。
根本的な問題は、オブジェクトを実際に切り捨てたり削除したりする前に、オブジェクトのダーティバッファをディスクに書き込む必要があることです。これにより、インスタンスの回復可能性が保証され、回復のスタックが回避されます。一見すると、一時テーブルを単純に切り捨ててから、別の用途のために再入力するのは完全に合理的であるように思われます。次に、スループットを向上させるために、同時バッチで一時的なポピュレーション/トランケート操作を実行します。
ただし、dbwrがバッファキャッシュからこれらのダーティブロックバッファをフラッシュするのに忙しいため、非現実的な同時切り捨ては行き詰まります。巨大なCIエンキュー待機が表示されます。同時ストリームでの複数の切り捨て操作は、スループットを完全に強制終了します。これは、大きなバッファーでは特に重要です。
バグ：4147840（非公開）にも議論があり、上記の説明のためにpeoplesoftプロセスがこの動作を引き起こし、onsamll一時テーブルを切り捨てるのではなく削除を実装するように一部のpeoplesoftコードを変更することで修正されたようです。
解決：
9.2.0.5以降では、頻繁に切り捨てられる 'temp'テーブルに、1つのエクステントを占めるようにストレージが定義されていることを確認することも役立つ場合があります。ただし、この回避策は、エクステントがバッファーキャッシュのサイズの50％以下である場合にのみ使用できます。 。非RAC環境では、テーブルは依然としてバッファキャッシュの50％未満である必要がありますが、古いアルゴリズムにフォールバックする前に、テーブルが最大5つのエクステントを持つことができます。
二。Enq：RO-高速オブジェクト再利用待機イベント
待機イベントは主にバグに関連しています。
2.1バグ1：バグ7385253
バグ7385253-遅い切り捨て/ DBWRはROエンキューで高いCPU / CKPTブロックを使用します[ID7385253.8]
影響：
製品 （ 成分 ）。 | Oracleサーバー（Rdbms） |
バージョンの範囲 信じた 影響を受ける | バージョン> = 10、ただし11.2未満 |
バージョン 確認済み 影響を受けているとして | |
影響を受けるプラットフォーム | 汎用（影響を受けるすべて/ほとんどのプラットフォーム） |
修繕：
この問題はで修正されています |
バグの3つのパフォーマンス：
（1） ハング（共有リソースを含む）
（3） 'を待つ enq：RO-オブジェクトの高速再利用 '
DBWRは多くのCPUを使用する可能性があり、オブジェクト再利用キューまたはチェックポイントキューに多数の空きバッファがあるため、kcbo_write_q内またはその周辺でスピンしているように見えます。
場合によっては、CKPTはROエンキューを非常に長い間保持し、waitevent'enq：RO --fastobjectreuse 'で他の操作をブロックします。
これまでに報告された影響を受ける操作は次のとおりです。
-スタンバイデータベースにプロセスを適用する
-統計を収集する
-切り捨て
-テーブルスペースの削除/縮小/変更
注：この修正は、以前は11gに影響を与えないものとして誤ってリストされていました。
バグ自体は11gに存在しますが、他の11gの変更により、重大な症状が見られる可能性は低くなります。つまり、空きバッファがオブジェクトキューに保持されなくなります。
右とバグ解決：
_db_fast_obj_truncate = FALSEの設定<--did not fix the issue
asyn i / oを有効にする<-- customer refused to implement to avoid corruptionsrisk
7287289を適用する<-- did not fix the issue
2.2ドキュメント2
スキーマ/テーブル統計を並行して収集する場合の「enq：RO-fastobjectreuse」の競合[ID762085.1]
症状：
（1）データベースは最近10.2.0.1から10.2.0.4にアップグレードされました。
（2）DBMS_STATSパッケージ（DEGREE> 1）を使用してスキーマ/テーブル統計を並列に収集する場合、「enq：RO-fastobjectreuse」の競合が発生します。
それはまた バグ7385253 この問題を引き起こします。
解決：
1）バッファキャッシュをフラッシュします。
または
2） '_ db_fast_obj_truncate' = FALSEを設定します。これは、バッファキャッシュ内のバッファを無効にする9iの方法に戻ります。
どちらの回避策もデータベースのパフォーマンスに影響を与える可能性があることに注意してください。代わりに、対応するパッチを適用することをお勧めします。
-この二解決dbパフォーマンスには大きな影響があります。適切なものを適用することをお勧めしますパッチ。
2.3ドキュメント3
Bug8544896-高いDBWRCPUで「enq：RO-高速オブジェクト再利用」を待機します[ID8544896.8]
影響：
製品 （ 成分 ）。 | Oracleサーバー（Rdbms） |
バージョンの範囲 信じた 影響を受ける | バージョン> = 10.2.0.4、ただし10.2.0.5未満 |
バージョン 確認済み 影響を受けているとして | |
影響を受けるプラットフォーム | 汎用（影響を受けるすべて/ほとんどのプラットフォーム） |
それは 回帰 に デフォルト したがって、動作：
10.2.0.4で導入された回帰
修繕：
この問題はで修正されています |
この問題は10.2.0.4で導入されました。
セッションは「enq：RO-fastobjectreuse」を待機できますが、DBWRはtruncatetype操作を実行するときに大量のCPUを消費します。
回避策：
（1）切り捨てる前にバッファキャッシュをフラッシュする
または
（2）_db_fast_obj_truncate = FALSEを設定します。
私はここにこれを持っています。二待機中のイベントはすべてです切り捨てる操作関連。
-------------------------------------------------- -------------------------------------------------- ---
著作権、記事の複製は許可されていますが、ソースアドレスをリンクで示す必要があります。そうでない場合、法的責任が調査されます。！
Skype：tianlesoftware
QQ：root @ xxxxx
Eメール： [メール保護]
ブログ： http://www.tianlesoftware.com
Weibo： http://weibo.com/tianlesoftware
ツイッター： http://twitter.com/tianlesoftware
フェイスブック： http://www.facebook.com/tianlesoftware
Linkedin： http://cn.linkedin.com/in/tianlesoftware
-------グループの追加はメモに含める必要がありますオラクル表スペースとデータ・ファイルの関係、それ以外の場合は適用を拒否する--------
DBA1グループ：62697716（フル）DBA2グループ：62697977（フル）DBA3グループ：62697850（フル）
DBAスーパーグループ：63306533（フル）DBA4グループ：83829929 DBA5グループ：142216823
DBA6グループ：158654907 DBA7グループ：172855474 DBA合計グループ：104207940