Enq: CI – contention

System Typeのロックによる待機現象の中には競合によって発生した言うよりは、特定のタスクを処理する過程で、他の先行タスクが終わることを保証する過程で発生するものがあります。先に議論したenq：TC – contentionも代表的な場合であるが、PQを実行する先行タスクとしてチェックポイント処理が完了するのを待っている過程で、待機が発生します。

enq：CI – contentionイベント待ちも似たような場合に該当します。 Oracleは、特定のテーブルをTruncateする前に、バッファキャッシュに積載されているテーブルのデータのダーティバッファのチェックポイント処理を実行する必要があります。もしTruncate実行時に障害が発生した場合でも、後に回復が可能でなければならないからです。 Truncateを実行したサーバプロセスは、Truncate作業が終わるまで待機しなければならのに、しばしばenq：CI – contention待機現象に観察されます。

チェック・ポイント、ログ・スイッチ（log switch）、シャットダウン（Shutdown）などの作業を呼び出すことをOracleでは、Cross Instance Functionと呼びます。合計11個のCross Instance Functionが定義されており、（Oracle8.0まで）、Functionごとにcall、parameter、queue、returnという4つの段階ごとにロックを獲得しなければなりません。この時のロックをCIロックと呼び、CIロックを獲得するために待っている間enq：CI – contentionイベントを待機することになります。 CIロックは、その名前とは異なり、RACなどのマルチノード（Multi Node）環境だけでなく、シングルノード（Single Node）環境で共通して使用されます。

enq：CI – contentionは競合によって発生することがないので、ほとんどの状況では、パフォーマンスの問題と直結していません。しかし、チェックポイントに関連するいくつかの操作（Drop、Truncateなど）では、チェックポイント自体の性能に問題が発生した場合enq：CI – contention待機による性能低下がしばしば発生します。特に、同時に複数のセッションがTruncateを実行する場合、余分なチェックポイントによって、システムのパフォーマンスが極度に低下する現象が発生することがあります。

P1：Enqueue情報
P2：opcode
P3：type

enqueue待機イベントと同一です。最大3秒まで待ちます。もしCIロックを獲得する場合獲得するまで待機します。

解決方法の一つは、Oracle 10g R2へのアップグレードすることです。 10g R2では、オブジェクトのチェックポイント（Object Checkpoint）アルゴリズムが大きく改善されて、これによるパフォーマンスの問題の多くが解決されます。実際には、Oracle 9iや10g R1からCIロック競合が発生した状況を、Oracle 10g R2で再現すると、ほとんどの問題が解消されたことが確認できます。

Truncateと関連して、頻繁に観察される待機現象がもう一つありますが、それはenq：RO – fast object reuse待機現象です。 TruncateやDropのようにオブジェクトが使用する領域（セグメント）を削除する作業は、CKPTとDBWRによって実際に削除が行われるまで待たされますが、これまでenq：RO – fast object reuseイベントを待機することになります。 ROロックは、Oracle 10gからオブジェクトを削除する時、オブジェクトの情報を削除した後、再利用する作業を同期するために主に使用されているとみられ、残念ながら具体的かつ公式に記述された文書を保存するのが難しいのです。 ROロックは、基本的に競合による性能低下現象が生じることはないのですが、バグによる性能低下現象が報告されているので、必要な場合は、メタリンクなどを介して情報を探さなければなりません。