16.20 - ロックと同時並行性 - Teradata Database - Teradata Vantage NewSQL Engine

Teradata Vantage™ SQLデータ操作言語

Product
Teradata Database
Teradata Vantage NewSQL Engine
Release Number
16.20
Release Date
2019年3月
Content Type
プログラミング リファレンス
Publication ID
B035-1146-162K-JPN
Language
日本語 (日本)

SELECTサブクエリー操作に対して設定されたロックは、セッションの分離レベル、AccessLockForUncomRead DBS制御フィールドの設定、および、SELECT操作やMERGEリクエストのなかにサブクエリーが埋め込まれているかどうかによって異なります。

トランザクションの分離レベル DBS制御AccessLockForUncomReadフィールド設定 外部SELECTと通常のSELECTサブクエリー操作におけるデフォルト値のロック重大度 MERGEリクエスト内に埋め込まれているSELECT操作のデフォルトのロック重大度
SERIALIZABLE FALSE READ READ
TRUE READ
READ UNCOMMITTED FALSE READ
TRUE ACCESS
MERGEリクエストは、ユーザーまたはシステムによって設定されるロック レベルの影響も受けます。MERGEリクエストのデフォルトのロックは、以下のようになります。
  • ターゲット テーブルにテーブル レベルのWRITEロックを設定します。ロード分離テーブルでの非同時分離マージの場合、マージ操作によりターゲット テーブルにEXCLUSIVEロックが設定されます。
  • 状況、およびLOCKINGリクエスト修飾子を指定しているかどうかに応じて、ソース テーブルにREADロックまたはACCESSロックを設定します。

以下の事例は、これらのロック レベルの影響を示しています。

事例1

クエリー計画は、手順1と手順2にターゲット テーブルt1のテーブルレベルの書き込みロックが含まれています。

     MERGE INTO t1
     USING (SELECT a2, b2, c2
            FROM t2
            WHERE a2 = 1) AS source (a2, b2, c2)
       ON a1 = a2
     WHEN MATCHED THEN
       UPDATE SET b1 = b2
     WHEN NOT MATCHED THEN
       INSERT (a2, b2, c2);

EXPLAINは、t1の書き込みロックを示します。

事例2

配列処理環境でMERGEリクエストを実行する場合は、ロックの考慮事項が重要になります。MERGEリクエストが適切に記述されていない場合、トランザクション デッドロックが発生する可能性があります。詳細は、<Teradata® CLI V2リファレンス-メインフレーム接続システム、B035-2417>または<Teradata® Call-Level Interface Version 2リファレンス - ワークステーション接続システム、B035-2418>を参照してください。<Teradata Vantage™ SQLリクエストおよびトランザクション処理、B035-1142>も参照してください。

この事例は、不適切な記述によってデッドロックが発生する例です。この事例では、BTEQコマンド.REPEAT 2 PACK 100に指定されたとおりに、2つの異なるセッションで同じリクエストがそれぞれ1回繰り返されます。セッションは、ANSIトランザクションの意味構造で実行されるので、t1に対するロックは、COMMITリクエストが正常に処理されるまで解除できません。

番号1025と1026という2つのセッションがあるとします。また、セッション1026が先に実行されるとします。セッション1026では、ターゲット テーブルt1にテーブル レベルの書き込みロックを設定し、MERGEリクエストの実行を完了します。ただし、セッション1026は、セッション1025が完了するまでターゲット テーブルt1のロックを解除できません。これは、両方のセッションが完了するまでそのトランザクションがコミットされないためです。

セッション1026でt1にテーブル レベルの書き込みロックが設定されたため、セッション1025はそのトランザクションを完了できません。これは、両方のセッションがもう一方のセッションがロックを解除するのを待つというデッドロックの典型的な例であり、両方のリクエストがハングします。

     .SET SESSION TRANSACTION ANSI 
     .SET SESSIONS 2
     .LOGON nbmps05/ob,ob
     .IMPORT INDICDATA file = ./recind.data
     .REPEAT 2 
     USING (c3 INTEGER)
     MERGE INTO t1
     USING (SELECT a2, b2, c2
            FROM t2
            WHERE a2 = 1) AS source (a2, b2, c2)
       ON a1 = a2 AND c1 =:c3
     WHEN MATCHED THEN
       UPDATE SET b1 = b2
     WHEN NOT MATCHED THEN
       INSERT (a2, b2, c2);
     .REPEAT 20
     COMMIT;
この事例で発生するデッドロックを回避する方法は2つあります。
  • アプリケーションを設計し直す。
  • Teradataセッション モードで既存のアプリケーションを実行し、トランザクションを終了するCOMMITリクエストの問題を回避する。

関連トピック

  • <Teradata Vantage™ SQLデータ定義言語 - 詳細トピック、B035-1184>の「SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL」
  • Teradata Vantage™ SQLリクエストおよびトランザクション処理、B035-1142
  • Teradata Vantage™ - データベース ユーティリティ、B035-1102