ConsumeモードのSELECTリクエストでの特別なロックの問題について
consumeモードのSELECT操作にはいくつかのロックの問題があります。このトピックでは、キュー テーブルに対するSELECTリクエストでの最も重要なロックの問題について説明します。
- キュー テーブルに対するconsumeモードSELECT操作へのデフォルト ロック割当ての重要度は、行ハッシュ レベルでのWRITEです。
このロック割当ての重要度を下げることはできません。
- INSERT…SELECT AND CONSUME操作のターゲット テーブルに対するconsumeモードSELECT操作へのデフォルト ロック割当ての重要度は、テーブル レベルでのWRITEです。
LOCKINGリクエスト修飾子を指定することはできますが、SELECT AND CONSUME操作の振舞いには何の影響もありません。システムは依然として同じ順序で行を検索し、テーブルが空のときは問合わせは遅延状態になります。
- システムは、キュー テーブルの消費される行が少なくとも1つなければ、そのテーブルの行ハッシュ レベルのWRITEロックをconsumeモードSELECT操作に付与しません。他のすべてのSQLリクエストではシステムはリクエストを受け取った時点でロックを付与するという点で、この操作の場合は異なります。
対象のキュー テーブルに行が挿入されると、直ちに以下のことが起こります。
- システムは、待ち行列内の最初の行ハッシュのWRITEロックを付与する。
- トランザクションの処理が再開する。
- 待ち行列が空になるまで行が消費される。
- Teradataセッション モードでの複数リクエスト トランザクションに含めることができるconsumeモードSELECTリクエストは、すべてのconsumeモードSELECTリクエストを明示的なBEGIN TRANSACTIONリクエストとEND TRANSACTIONリクエストの間に置かない限り、1つのみです。
例えば、次のTeradataセッション モードの複数リクエスト トランザクションは有効です。
BEGIN TRANSACTION; SELECT AND CONSUME TOP 1 * FROM myqueue; SELECT AND CONSUME TOP 1 * FROM myqueue; SELECT AND CONSUME TOP 1 * FROM myqueue; END TRANSACTION;
以下のconsumeモードSELECTリクエストもTeradataセッション モードで有効ですが、それぞれが個別の暗黙的なトランザクションになっています(トランザクション、リクエスト、および文を参照)。
SELECT AND CONSUME TOP 1 col_1_qits, qsn FROM myqueue; SELECT AND CONSUME TOP 1 col_1_qits, USER, CURRENT_TIMESTAMP FROM myqueue; SELECT AND CONSUME TOP 1 * FROM myqueue;
- ANSIセッション モードでconsumeモードSELECT文を指定する場合は、特に考慮すべきことはありません。ただし、COMMITリクエストまたはROLLBACKリクエストを実行することによって、ANSIセッション モード トランザクションを終了する必要があることは覚えておいてください。
SELECT AND CONSUMEリクエストは、トランザクションをCOMMITリクエストで終了するか、ROLLBACKリクエストで終了するかが問題になる、唯一のSELECTリクエストです。
次に示すのは、ANSIセッション モードでの有効な例です。この例では、2つのconsumeモードSELECTリクエストを指定しています。
SELECT AND CONSUME TOP 1 * FROM myqueue; SELECT AND CONSUME TOP 1 * FROM myqueue; COMMIT;
ROLLBACKリクエストを実行依頼する場合、トランザクションが開始してから現在のセッションで行なったすべての作業はロールバックして、その作業は消失します。
- consumeモードSELECTリクエストはTeradataセッション モード トランザクションの可能な限り始めのほうに置き、他のデータベース リソースとの競合を回避する必要があります。
- SELECT AND CONSUMEリクエストを発行するときは、以下のことはしないようにしてください。
- 明示的なトランザクション内でSELECT AND CONSUMEリクエストをコーディングする。
- トランザクション内にSELECT AND CONSUMEリクエストを多数コーディングする。特にSELECT AND CONSUMEリクエストの対象と同じキュー テーブルに対して行なわれるDELETEおよびUPDATE操作がある場合。
システムがキュー テーブルに対してSELECT AND CONSUME操作を実行するときに、同じキュー テーブルに対して削除や更新の操作を行なうたびに行収集操作も実行することになるので、パフォーマンスに影響を与えます。
- 行をキュー テーブルから消費することに基づいて実行されるアクションは、その同じキュー テーブルに対するCONSUMEモードのSELECT操作と同じトランザクション内に指定する必要があります。これにより、行の消費とそのキュー テーブルに対して実行されるアクションとが共にコミットされるので、そのキュー テーブルの行またはアクションが失われないことが保証されます。
アクションを起こさない場合は、SELECT AND CONSUMEリクエストをトランザクション内の唯一のリクエストになるように分離する必要があります。
- トランザクション内のSELECT AND CONSUMEリクエストの数が制限の2 210を超えると、Teradata Databaseはそのトランザクションをアボートします。
- 次に示す文は、SELECT AND CONSUME文と同じキュー テーブルを同じ複文リクエスト内で操作する場合はコーディングできません。
- DELETE
- MERGE
- UPDATE
- キュー テーブルに対するDELETEおよびUPDATE操作を多数コーディングするとパフォーマンスに悪影響を及ぼすので、避ける必要があります。
- キュー テーブルでのDELETE、MERGE、またはUPDATE操作は、パフォーマンスを低下させるため、例外的な状況に限定してください。重要な要素はそのような操作をコーディングする数ではなく、そのような操作が実行される頻度です。例えば、ほとんど発生しない例外的な状況の場合にだけ多数のDELETE、MERGE、またはUPDATE操作が実行されるアプリケーションを実行する場合には、この指針を無視できます。
それ以外の場合には、結果としてパフォーマンスが低下する可能性があるために、DELETE、MERGE、およびUPDATEは控えめに、そして頻繁に実行しない操作に限定してコーディングしてください。
このような勧告をする理由は、キュー テーブルに対するUPDATE、MERGE、およびDELETE操作は、同じ操作でもキュー テーブル以外のテーブルに対して行なう場合に比べてコストがかかることにあります。これは、これらのいずれの操作でも、該当するPE上にFIFOキャッシュを再作成するためにフル テーブル スキャンが行なわれるからです。
- Teradata DatabaseはTeradata Dynamic Workload Managerソフトウェアを使用して、キュー テーブルに対するすべての延期したリクエスト(遅延状態のトランザクション)を管理します。システムが遅延consumeモード リクエストの管理に使用する上では、Teradata Dynamic Workload Managerクライアント アプリケーション ソフトウェアを有効にする必要はありません。
キュー テーブルに対する多数のさまざまなリクエストは、遅延consumeモード クエリーだけでなくすべてのクエリーを最適に管理するTeradata動的ワークロード管理ソフトウェアの能力に悪影響を与えることになるので、この2つの機能のそれぞれの使い方を最適化する必要があります。
- 遅延状態のセッションがPE上のセッション数の20パーセントを超えると、システムは要求元にエラーの応答を返します。セッションの数がデフォルト値の120に設定されているとすると、遅延状態のセッションのしきい値数は24になります。
- SELECT AND CONSUMEリクエストは、同じトランザクション内で待ち行列テーブルに挿入された行を消費させることができます。