Problem mit einem Trigger

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

Hallo,

ich habe einen Trigger geschrieben der bei einem Update auf eine Tabelle das SQL-Statement in eine Tabelle schreiben soll.

create or replace trigger audit_table
before update on sysadm.ps_er_installation
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
insert into audit_table SELECT SQL_TEXT, address, PIECE, sysdate FROM v$sqltext_with_newlines
where ADDRESS =
(SELECT sql_address FROM v$session where audsid =
(select sessionid from aud$ where to_char(timestamp#, ‚dd.mm.yyyy HH24:MI‘) = to_char(sysdate, ‚dd.mm.yyyy HH24:MI‘) )); # zu Testzwecken Zeitraum erweitert
commit;
END ;
/

wenn ich ein Update auf die Tabelle mache und dann bekomme ich auch genau das Statement was ich auf die Tabelle abgesetzt habe.

Aber der Trigger selbst schreibt nichts…

Was fehlt, oder was ist falsch ?

Grüße

Chris

#2

Hi,
ich würde vermuten, dass die Audit Information erst nach dem Update weggeschrieben wird, eventuell sogar mit ein wenig Verzögerung. Also wäre ein after Statement Trigger ein Versuch Wert.

Aber warum um Himmelswillen willst du so etwas tun?
Auditing von Oracle ist ne feine Sache
Auditing per Trigger … na gut muss manchmal sein?
Aber Auditing per Trigger, der dann auf die Auditing Tabellen von Oracle zugreift?

Da bin ich Neugierig, was für einen Sinn das macht.

Jens

#3

Hi,

ich habe es auch mit einem after-Trigger versucht, ist das gleiche…

das ich über den Umweg der aud$ Tabelle die Session raussuche die aktuell das Statement abgesetzt hat, ist die einzige Lösung die ich gefunden habe. Ich muß viellecht noch dazu sagen das es sich um eine 8i Datenbank handelt.

Wenn du eine Lösung kennst - immer her damit

Grüße

cHris

#4

nur die SID??
hi Chris

moment: du treibst den ganzen aufwand, nur um an die sid deiner sesseion zu kommen??

was ist gegen folgendes statement auszusetzen?

select sid
from v$session
where audsid = userenv(‚sessionid‘);

hintergrund: das auditing verwendet eine eigene sessionid. diese wird extra in der v$session eingetragen (audsid). zusätzlich steht diese sessionid auch in der benutzerumgebung, die man mit der userenv-funktion abfragen kann. das ganze klappt wunderbar unter oracle 8.1.7.4 (habs gerade getestet).

lg
erwin

#5

Hi

select sid
from v$session
where audsid = userenv(‚sessionid‘);

Das funktioniert aber nicht immer, z.B. nicht, wenn die Session ein Dbms_job job ist (und vielleicht auch nicht in autonomen Transactionen?). Daher würde ich dies bevorzugen:

select * from v$session where sid = ( select sid from v$mystat where rownum=1 )

Das hat mir bisher immer das geliefert, was ich haben wollte.

Hab ich mir aber auch nicht selbst ausgedacht: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::…

Jens

#6

hi,

ich brauche das Statement das abgesetzt wurde.

Die Anweisung selbst funktioniert ja auch nur das der Trigger nicht schreibt.

Grüße

Chris

#7

grundsatzproblem
hi chris

vermutung: du lässt den trigger in einer autonomen transaktion laufen. ich bin jetzt nicht ganz sicher, was oracle da genau macht, vermute aber, dass oracle da intern eine eigene session dafür verwendet. sonst wäre es ja auch nicht möglich, ein seperates commit abzusetzen. insofern wird dein statement einfach nichts liefern. ergo: der trigger funktioniert perfekt - die grundannahme ist nur falsch.

aber wie schon erwähnt: das audit von oracle ist wirklich ok und genau für sowas gedacht. und vor allem, das funkioniert…

wenn es aber unbedingt ein trigger sein soll: ich würde den trigger nicht in einer seperaten transaktion laufen lassen, sondern in einem normalen trigger die gewünschten daten laden und in einer asynchronen prozedur wegschreiben. sollte klappen.

zum beweis: schreibe einfach mal einen statischen text im trigger weg - dann weisst du wenigstens, ob der trigger wirklich funktioniert oder nicht.

lg
erwin