✔ Oracle: Transaktionsverhalten von Triggern

[sceppi]

Hallo,
ich habe eine allgmeine Verständnisfrage:
Beispiel:
Eine Anwendung verändert Daten in einer Tabelle und löst dabei einen Trigger aus. Die Veränderung der Daten über die Anwendung läuft selber in einer Transaktion. Ist der Trigger und die vom Trigger verwendeten Proceduren mit in der Transaktion eingeschlossen? Soll heißen, erfolgt ein Rollback, werden da auch die Änderungen des Triggers(Proceduren) verworfen?
Gleiche Frage gilt auch dafür, was passiert, wenn eine Trigger-Procedur ein eigenes Transaktionmanament hat:
Angenommen im Trigger gibt es einen Fehler -> Rollback für die Transaktion im Trigger::: Betrifft dass dann auch die Änderung der DB durch die Anwendung und deren Änderung wird auch zurückgefahren, also geschachtelt?
MfG
sceppi

 

[planb2000]

Hallo Sceppi,

sehr interassantes Thema!

Dazu mal ein Zitat aus meinem schlauen Buch:

Transaktionssteuerung:
---------------------------------
Sämtliche SQL-Befehle für die Transaktionssteuerung können in einem Trigger KEINESFALLS zur Anwendung kommen. Auch wenn die Möglichkeit besteht, eienen derart fehlerhaften Trigger in der Datenbank zu speichern, so erhält man spätestens bei der Ausführung bzw. beim automatischen Aufruf desselben eine entsprechende Fehlermeldung. Dies betrifft also COMMIT, ROLLBACK, SAVEPOINT und SET TRANSACTION. Dies wirkt sich auch auf die im Trigger aufgerufenen Module aus, d.h., diese können auch keine Transaktionsbefehle enthalten.

Ich denke das wenn man Trigger verwendet um komplexe Regeln umzusetzen, werden jedoch keine Transaktionen mit Triggern DIRKET umsetzbar sein. Sicher gibt es einen WEg das zu umgehen den sollte man aber nicht nutzen.

Ich hoffe das hilft.

Grüße

 

[sceppi]

Danke für die Hilfe,
das ist genau die Info, die ich gebraucht habe.
MfG
sceppi

 

[Exceptionfault]

In Triggern können sehr wohl Statements wie COMMIT oder ROLLBACK oder ähnliches vorkommen. Die Transaktion die dann in diesem Trigger läuft ist eine sogenannte autonome Transaktion und läuft unabhängig von der Transaktion der User Session. Beispiel:

-- Tabelle in die unser Trigger schreiben soll
SQL> CREATE TABLE TEST ( ID NUMBER, INSDATE DATE );

Table created.

-- Tabelle in die wir schreiben, und auf der unser Trigger liegt
SQL> CREATE TABLE TEST2( ID NUMBER );

Table created.

-- "normaler Trigger" insertet, wenn wenn wir auch inserten
SQL> CREATE TRIGGER INS_ON_TEST 
	BEFORE INSERT ON TEST2 FOR EACH ROW
BEGIN	
  INSERT INTO TEST VALUES( :new.ID, SYSDATE );
END;
/

SQL> INSERT INTO TEST2 VALUES ( 1 );

1 row created.

SQL> SELECT * FROM TEST;

             ID INSDATE
--------------- -------------------
              1 08.07.2008 11:27:53
              
1 row selected.

-- hat geklappt, unser Trigger hat einen Satz erzeugt
SQL> ROLLBACK; 

Rollback complete.

SQL> SELECT * FROM TEST;

no rows selected

-- wunderbar, auch der Insert unseres Triggers ist nach dem 
-- Rollback wieder weg

-- ein etwas anderer Trigger mit COMMIT und dem dubiosen "PRAGMA..."
SQL> CREATE OR REPLACE TRIGGER INS_ON_TEST 
	BEFORE INSERT ON TEST2 FOR EACH ROW
DECLARE
	PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN	
  INSERT INTO TEST VALUES( :new.ID, SYSDATE );
  COMMIT;
END;
/

SQL> INSERT INTO TEST2 VALUES ( 1 );

1 row created.

SQL> SELECT * FROM TEST;

             ID INSDATE
--------------- -------------------
              1 08.07.2008 11:30:17

1 row selected.

SQL> ROLLBACK; 

Rollback complete.

-- siehe da: nach dem Rollback sind unsere Daten noch da:
SQL> SELECT * FROM TEST;

             ID INSDATE
--------------- -------------------
              1 08.07.2008 11:30:17

1 row selected.

Solche Trigger sind also ideal um z.B. Protokollierung durchzuführen. Wenn man in jedem Fall wissen möchte was ein User getan hat, auch wenn er es eigentlich wieder rückgängig gemacht hat.