ストアドプロシージャ内の複数のステートメントでテーブルをロックする

Question

私は、Teradataトランザクションでスナップショット分離に相当するものを実装しようとしています。 Oracleはこの種の分離をサポートしていますが、Teradataは（少なくとも私が認識しているバージョン14以前ではありません）。目標は、テーブルの内容を削除し、それをすべて再読み込みして他のユーザーがテーブルからの読み書きを禁止するプロシージャを作成することです。

私の理解によれば、オプティマイザは要求内のさまざまなテーブルロックについてすべて知ることができるbegin requestステートメントを見つけました。

私は以下の手順を書いていますが、.NETアプリケーションでスレッドロックをテストしていれば簡単に確実にデバッグする方法はわかりません（ブレークポイントの設定や他のスレッドの監視が簡単です）。 Teradataでは、私がここに書いたものが、プロシージャーの期間だけ正しくmydb.destinationtableをロックするかどうかはわかりません。これは正しいです？

編集：私は手順が機能することを追加します。 DELETE/INSERTを実行している間にSELECTを正しく実行できるだけです。

replace procedure mydb.myproc() 
begin 
    begin request 

    locking mydb.destinationtable for exclusive 
    delete mydb.destinationtable; 

    locking mydb.destinationtable for exclusive 
    insert into mydb.destinationtable 
    select * from mydb.sourcetable; 

    end request; 
end; 

Answer 1

BEGIN REQUEST/END REQUEST F9を使用して、SQLアシスタントの両方の要求を提出同じであるいわゆるマルチ書要求（MSR）を作成します。

計画はF9でこれを実行して表示するには：

EXPLAIN 
locking mydb.destinationtable for exclusive 
delete mydb.destinationtable; 

insert into mydb.destinationtable 
select * from mydb.sourcetable; 

やBTEQ中：

EXPLAIN 
locking mydb.destinationtable for exclusive 
delete mydb.destinationtable 
;insert into mydb.destinationtable 
select * from mydb.sourcetable; 

はところで、第二ロックが冗長です。

しかし、。削除& InsSelを1つのトランザクションとして実行すると、両方とも一時的にジャーナリングされます。 多くはの要求よりも遅いです。

が

-- no BEGIN/END REQUEST 
insert into mydb.destinationtable_2 
select * from mydb.sourcetable; 

-- there's just a short dictionary lock 
-- all requests against the view submitted before the replace use the old data 
-- and all submitted after the new data 
replace view myview as 
select * from mydb.destinationtable_2; 

delete from mydb.destinationtable_1; 

今、あなたのSPのみ1 & 2（ベースを切り替えるためのロジックを必要とします：

これを行うには、より一般的な方法は、ビューのないテーブルの上にターゲット表とベースのアクセスの2つのコピーを使用することですon table [not] empty）