Wenn Sie die 10g Enterprise Edition haben, sollten Sie sich Oracle's Fine-Grained Auditing ansehen. Es ist definitiv besser als selbst zu rollen.
Aber wenn Sie eine niedrigere Version haben oder FGA aus irgendeinem Grund nicht nach Ihrem Geschmack ist, gehen Sie wie folgt vor. Das Wichtigste ist:Erstellen Sie für jede Anwendungstabelle eine separate Audit-Tabelle .
Ich weiß, das ist nicht das, was Sie hören möchten, weil es nicht zu der Tabellenstruktur passt, die Sie oben skizziert haben. Aber das Speichern einer Zeile mit ALTEN und NEUEN Werten für jede Spalte, die von einer Aktualisierung betroffen ist, ist eine wirklich schlechte Idee:
- Es skaliert nicht (eine einzelne Aktualisierung, die zehn Spalten berührt, erzeugt zehn Einfügungen)
- Was ist, wenn Sie einen Datensatz einfügen?
- Es ist völlig mühsam, den Status einer Aufzeichnung zu einem bestimmten Zeitpunkt zusammenzustellen
Haben Sie also für jede Anwendungstabelle eine Audit-Tabelle mit identischer Struktur. Das bedeutet, dass CHANGED_TIMESTAMP und CHANGED_USER in die Anwendungstabelle aufgenommen werden, aber das ist keine schlechte Sache.
Schließlich, und Sie wissen, wohin das führt, haben Sie einen Trigger für jede Tabelle, der einen ganzen Datensatz mit nur den :NEW-Werten in die Audit-Tabelle einfügt. Der Trigger sollte bei INSERT und UPDATE ausgelöst werden. Dies gibt die vollständige Geschichte, es ist einfach genug, zwei Versionen der Aufzeichnung zu unterscheiden. Für ein DELETE fügen Sie einen Audit-Datensatz ein, bei dem nur der Primärschlüssel ausgefüllt und alle anderen Spalten leer sind.
Ihr Einwand wird sein, dass Sie zu viele Tabellen und zu viele Spalten haben, um all diese Objekte zu implementieren. Aber es ist einfach genug, die Tabelle zu generieren und DDL-Anweisungen aus dem Datenwörterbuch (user_tables, user_tab_columns) auszulösen.
