はてなブックマーク

共有プール・ラッチが空き領域を探すために空きリストをスキャンして適切なチャンクを割り当てる作業を保護するなら、ライブラリ・キャッシュ・ラッチはSQLを実行するためにライブラリ・キャッシュメモリー領域を探索して管理する全ての作業を保護します。 ライブラリ・キャッシュ・ラッチはCPUカウントより大きい素数中一番小さい数だけ子ラッチを持ちます。 ライブラリ・キャッシュ・ラッチを獲得する中で競合が発生すると、latch:library cache待機イベントを待機します。ライブラリ・キャッシュ・ラッチ競合は主に次のような場合に発生します。 ハード解析やソフト解析が多過ぎる場合 バージョン・カウントが高い場合 SGA領域のページ・アウトが発生する場合 共有プール・ラッチ競合が主にハード解析による空きリストの探索によって発生するように、ライブラリ・キャッシュ・ラッチ競合の最も重要な原因もハード解析にあ

1.概要 特定ブロックにアクセスする際プロセスは該当ブロックに対してバッファ・ロックを獲得します。特定ブロックを変更する際も、該当ブロックに対してバッファ・ロックを排他モードで獲得します。また、特定ブロックに対しては読取時バッファ・ロックを共有ロックモードで獲得します。 もしプロセスAがブロックXに対してバッファ・ロックを獲得している状態で、プロセスBが同一のブロックに対してアクセスをした場合バッファ・ロックを獲得できない為待機します。その時、発生する待機イベントがbuffer busy waits待機イベントです。 buffer busy waits待機イベントが最も多く確認されるのは、同時に複数のプロセスが同一のブロックに対してインサートやアップデートをする場合です。インサートやアップデートの作業は該当ブロックに対してバッファ・ロックを排他モードで獲得することを要求します。複数のプロセ

バッファ・キャッシュを使うためハッシュ・チェーンを探索したり変更を加えようとするセッションは、 必ずそのチェーンを管理しているcache buffers chainsラッチ(以降、CBCラッチ)を獲得しなければなりません。 このラッチを獲得する時に、競合が発生するとlatch:cache buffers chains待機イベントで待機します。 Oracle9i以降からは読み取り専用を保護するため、チェーンを探索する場合にはCBCラッチを 共有モードで獲得し、競合を減らせるようになっています。これには一つ注意すべきことがあります。 理論的にはSELECT文が同時に発行された場合は、CBCラッチを共有できるため、 CBCラッチ競合が発生してはいけませんが、実際テストをしてみるとラッチ競合は相変らず発生します。 その理由は、バッファ・ロックと関連があります。読み取り専用で作業を行うために共有モー

ユーザー・プロセスがコミットまたはロールバックを行うと、サーバー・プロセスはLGWRへ要求を送ります。 LGWRはREDOバッファの一番最後に記録された部分からコミットした部分までの全REDOエントリをREDOログ・ファイルへ 書込みます。この動作が行われた回数は、redo synch writesの統計で確認することができます。 サーバー・プロセスはコミットを実行した後、LGWRが正常にREDOエントリを書きだすまで待ちますが、 この時、log file sync待機イベントで待機します。 つまり、ログ・バッファとファイルの同期化を行う間、 LGWRプロセスはREDOエントリがREDOログ・ファイルへ書込みを完了するまで log parallel write待機イベントで待機し、サーバー・プロセスはlog file sync待機イベントで待機します。 サーバー・プロセスでは2つの理由でl