2016-10-21 5 views
0

更新後にトリガーを持つテーブル(T1)があります。このトリガは、いくつかの値を探し、それは誰もがなぜ知っているん...他のテーブル(T2)トリガーを使用してテーブルを更新するとロックされます

CREATE OR REPLACE TRIGGER t1_AIR AFTER UPDATE ON t1 FOR EACH ROW 

DECLARE 
    PRAGMA AUTONOMOUS_TRANSACTION; 
    v_dF1  DATE; 
    v_dF2  DATE; 
    v_nDays  NUMBER; 
    v_cReg  VARCHAR2(50); 

BEGIN 

IF :NEW.BN_BE_ESTADO not in ('PEN', 'ERR', 'BAJ') THEN 

    v_nDays := F_GET_PARAM(NULL, NULL, 'X_DAYS'); 

    PCK_AUX.PR_GET_F1(:NEW.F_A, v_dF1, v_cReg); 
    PCK_AUX.PR_GET_F2(:NEW.F_A, v_dF2); 

    UPDATE T2 
    SET F_F1 = TRUNC(v_dF1), 
     F_F2 = TRUNC(v_dF2), 
     F_F_END = PCK_AUX.FU_GET_F_END(v_dF2+1, v_nDays), 
     F_N_REG = v_cReg 
    WHERE F_ID = :NEW.F_B; 

END IF; 

EXCEPTION 
     WHEN OTHERS THEN 
     NULL;     
END; 

しかし、私はそれが両方の表(t1とt2)でロックを発生さT1を更新を更新します?あなたがテーブルを更新すると、行シェア(RM)と行排他モード(RX)で行レベル(TX)ロックとテーブルロックが取得されているすべての

+2

t1のトリガーがt2を更新します。あなたはt1のアップデートと同じ状況にあり、その後にt2の明示的なアップデートが続きます – Aleksej

+0

しかし、t1は多くのアプリケーションによって更新されています。私はそれがトリガーでもっと簡単だと思いました... – igandea

+0

どのようなタイプのロックが作成されますか? – ibre5041

答えて

3

感謝。

行レベルのロックがあるので、他のセッションは更新される行を変更できませんでした。 DMLステートメント(あなたのケースではupdate)が進行中の間に、異なるモードのテーブルロックが変更からテーブル構造を保護するためにあります。

したがって、更新中の行はtable 1 and table 2と表のロックの両方でロックされ、行の共有と行の排他モードで保持されます。

あなたのトリガーについて、少し...

autonomous transactionプラグマがあるのはなぜ?たとえば、メイントランザクションが成功するかどうかをコミットする必要がある状況を記録するためにそのトリガを使用していない限り、このプラグマは本当に必要ありません。 @William Robertsonがautonomous transactionを使用している場合は、この自律型トランザクションをコミットする必要があります。そうでないとORA-06519が発生します。

when others then nullステートメントの再利用については、生成される可能性のある例外を隠すのではなく、再発生する方がよいでしょう。

関連する問題