Interessanter Beitrag, aber:
1. sollte man seine Oracle-Lizenzbedingungen ganz genau studieren.
Wenn man Oracle zusammen mit SAP erworben hat, gibt es da oft recht restriktive Einschränkungen, was man mit der Lizenz alles darf.
2. ist noch die Frage, was SAP dazu sagt, wenn der Kunde auf DB-Ebene eigene Trigger definiert.
Damit kann man ja auch katastrophale Laufzeiten oder gar Daten-Inkonsistenzen ... erzeugen.
In einem Produktivsystem würde ich jedenfalls die Finger davon lassen.
3. kennt Oracle natürlich den SAP-User und -Mandanten nicht.
Man kann zwar protokollieren, was geändert wurde, aber man will ja in der Regel auch wissen, wer (mit welcher Transaktion usw.)
Um ganz sicher zuordnen zu können, wer was geändert hat, muss also der Trigger den Applikationsserver und die Prozess-ID des Applikationsserver-Betriebssystems kennen, per RFC einen Reconnect an das SAP-System machen und einen Funktionsbaustein im SAP aufrufen, der für den passenden Prozess die nötigen Infos liefert (User, Mandant, laufendes Programm...)
Wenn Oracle die Prozess-ID nicht kennt, muss man halt vom Applikationsserver die Informationen samtlicher SAP-Workprozesse (s. SM50) holen, um dann daraus abzulesen, welcher Workprozess gerade einen Update auf Tabelle XYZ macht... Viel Spaß dabei.
(Wenn zum Zeitpunkt der Änderung sonst nicht viel im System los war, kommt man evtl. auch per Synchronisation mit den in Transaktion STAD verfügbaren Informationen weiter.)
Frank