enq: TC – contention - 日本エクセム株式会社 Oracle待機イベント情報

基本情報

　人為的なチェックポイントを実行する作業の一部は、TCロック（Thread Checkpoint Lock、あるいはTablespace Checkpoint Lock）を獲得しなければなりません。TCロックを獲得する過程で競合が発生した場合enq：TC – contentionイベントを待機することになります。

　TCロックを獲得する過程は以下の通りです。

1）サーバープロセスが優先TCロックをXモードで獲得します。

2）サーバプロセスは、獲得したTCロックをSSXモードに変更し、同時にCKPTプロセスがSSモードでは、ロックを獲得します。 CKPTはロックを獲得してチェックポイント処理を実行することになります。

3）サーバプロセスは、再びTCロックをXモードで獲得しようとしますが、そのロックがCKPTによって解放されるまで待機することになります。この時の待機イベントがenq：TC – contentionです。

4）チェックポイント処理が完了すると、CKPTプロセスはTCのロックを解除して、サーバプロセスは、TCロックを獲得することにより、チェックポイント処理が終わったことを知ることになります。

　enq：TC – contention待機は、複数のプロセスによって競合が発生していなくても、観察になるという点で、ロック競合による他の待機現象とは区別されます。待機現象は、競合にのみ発生する可能性のあるものもありますが、競合が発生していなくても、特定の操作が完了するのを単に待っている場合もあるということを理解する必要があります。

　チェックポイントが発生する場合は非常に多様ですが、すべての場合でTCロックによる待機が発生するわけではなく、サーバプロセスによって誘発されたチェックポイントの操作を同期させる過程でのみ発生します。 enq：TC – contention待機が発生する代表的な事例は、以下の通りです。

Parallel Query

　Parallel Query（以下PQ）でチェックポイントが発生する理由は、スレーブセッション（Slave Session）によるdirect path readになります。direct path readは、バッファキャッシュを介さずに、データファイルを直接読むことを言います。オラクルは、次のような三つの場合にdirect path read（またはphysical read direct方式の読み取り）を使用します。

・メモリ領域でソート操作を完了することができないとき、一時的セグメント（Temp Segment）領域に情報を保存し、
　読みの過程でdirect path write、direct path readが発生します。このときの待機イベントは、
　direct path read temp、direct path write tempイベントで観察されます。

・スレーブセッションがデータをスキャンするために、データファイルを直接読み込むときdirect path readを使用します。
　このときの待機イベントは、direct path readイベントで観察されます。

・I/Oシステムのパフォーマンスの低下により、ブロックを十分に速い速度で読み込まないと判断されると、
　Oracleはその場しのぎでdirect path readを使用します。

　スレーブセッションがdirect path readを実行する対象がデータファイルと呼ばれることに注意しましょう。データファイルから直接データを読み取る場合、SGAを経由していないため、現在SGAにあるブロックとデータファイル内のブロックの間にバージョンの不一致現象が起こることがあります。このような現象を防止するために、Oracleは、データファイルのdirect path readを実行する前に、チェックポイントを実行する必要があります。コーディネーターのセッション（Coordinate Session）は、スレーブセッションを起動する前に、direct path readを実行するオブジェクトに対して、セグメントレベルのチェックポイントを求めるようになって、チェックポイント処理が完了するまでenq：TC – contentionイベントを待機します。コーディネーターセッションでは、enq：TC – contention待機が目撃され、スレーブセッションでは、direct path read待機が目撃されることに注意しましょう。TCロック競合現象の文を関連サイトなどで検索すると、ハイブリッド（Hybrid）システム、すなわち、OLTPとDSSが混用されて使用されるシステムで多く発生すること出てきますが、その理由はPQの実行にあります。

テーブルスペースホットバックアップ（Tablespace Hot backup）

　ALTER TABLESPACE … BEGIN BACKUPを実行すると、Oracleは、テーブルスペース内に属するすべてのデータファイルのダーティブロックをディスクに記録（Checkpoint）ことになりますが、この過程でenq：TC -contention待機を経過します。

　TCロック競合によるパフォーマンスの問題は、待機そのものではなく、人為的なチェックポイントを実行することにあります。例えば、ハイブリッドシステムで毎秒数百回以上のトランザクションが発生する状況で毎秒数回以上のPQを実行すると仮定しましょう。 PQを実行するたびに、チェックポイントが発生するようになります。チェックポイントが不要に多く行われる場合DBWRにボトルネックが生じ、さまざまなパフォーマンスの問題を引き起こすことになります。このような点を考慮すると、PQは、そのシステムと業務を考慮して、必要な場合にのみ使用するようにする必要があります。ただし、PQによるチェックポイントは、PQが実行されるオブジェクトにのみ実行されるという点で、一般的なチェックポイントではなく、負荷が少なくなります。

　PQを適切に使用すると、大容量のデータを高速で処理することができ、特にSGAを経由しないため、バッファキャッシュに大量のデータを上げることから来る副作用を避けることができるという長所があります。しかし、enq：TC – contention待機からわかるように、不要なチェックポイントを誘発し、かえってシステム全体の性能に悪影響をもたらすこともなります。したがって、必ず必要な業務にのみPQを使用する必要があります。

待機パラメータと待機時間

待機パラメータ

P1：Enqueue情報
P2：Checkpoint ID
P3：0

待機時間

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