Werden die Audit Daten in Tabellen der Datenbank geschrieben, also im Standard Auditing nach AUD$ und im Fine Grained Auditing nach FGA_LOG$, können beide Basistabellen verschoben werden. Sie können sowohl gemeinsam in ein Tablespace oder auch in unterschiedliche Tablespaces verschoben werden. Selbstverständlich sollten die Tablespaces, in die die Audit Daten dann geschrieben werden, über ausreichend Speicherplatz verfügen. Da vorhandene Audit Daten zum Verschieben umkopiert werden, sollte das Verschieben zu Zeiten geringer Auslastung der Datenbank stattfinden. Der folgende Aufruf verschiebt die Tabelle AUD$ einschließlich der darin enthaltenen Daten aus dem Tablespace SYSTEM in das Tablespace TS_AUD_DATA.

DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(
   audit_trail_type            => AUDIT_TRAIL_AUD_STD, 
   audit_trail_location_value  => 'TS_AUD_DATA');

Wird der Parameter AUDIT_TRAIL_TYPE auf AUDIT_TRAIL_FGA_STD gesetzt, wird nur die Tabelle FGA_LOG$ verschoben, steht der Parameter auf AUDIT_TRAIL_DB_STD werden beide Tabellen, AUD$ und FGA_LOG$, in das gleiche Tablespace verschoben.

Die Prozedur SET_AUDIT_TRAIL_LOCATION wird auch dazu verwendet, den Speicherort für die Audit Daten zu verändern, wenn diese in Dateien des Betriebssystems geschrieben werden. Es wird dabei danach unterschieden, in welchem Format die Dateien vorliegen: Steht der Parameter AUDIT_TRAIL auf OS und befinden sich die Audit Daten in Dateien im Oracle proprietären Format, wird AUDIT_TRAIL_TYPE auf AUDIT_TRAIL_OS gesetzt und für den Parameter AUDIT_TRAIL_LOCATION_VALUE ein gültiger Pfadname angegeben.

DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(
   audit_trail_type            => AUDIT_TRAIL_OS, 
   audit_trail_location_value  => '/opt/oracle/aud_data');

Befinden sich die AUDIT Daten in XML Dateien, setzt man den Parameter AUDIT_TRAIL_TYPE der Prozedur SET_AUDIT_TRAIL_LOCATION auf AUDIT_TRAIL_XML. Auch ein gemeinsames Verschieben ist möglich, wenn man AUDIT_TRAIL_TYPE auf AUDIT_TRAIL_FILES setzt. Diese Möglichkeit wird man nur dann nutzen, wenn man für das normale Auditing einen anderen AUDIT_TRAIL Parameter verwendet als für das Fine Grained Auditing - wenn also der eine Parameter zum Beispiel auf OS steht und der andere auf DBMS_FGA.XML + DBMS_FGA.EXTENDED.

Mit der Prozedur DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY kann man die Anzahl der Sätze festlegen, die bei dem Löschen von Audit Daten in den Tabellen AUD$ und FGA_LOG$ bei einem Löschvorgang gelöscht werden (s.u.). Werden Audit Daten in Dateien des Betriebssystems geschrieben, kann entweder die maximale Größe der Dateien festgelegt werden, oder die maximale Anzahl von Tagen, die diese Dateien verwendet werden. Wird die Größe oder die Anzahl der Tage erreicht, legt Oracle automatisch eine neue Datei an und schreibt die danach anfallenden Audit Informationen in die neue Datei. Das erlaubt dem DBA, die alte Datei etwa auf ein Bandlaufwerk zu sichern und anschließend zu löschen, und verhindert so, dass die Audit Daten den kompletten Speicherplatz auf dem Speichermedium füllen.

Folgender Befehl legt zum Beispiel fest, dass eine Datei mit Audit Daten maximal 500 MegaByte Größe zur Verfügung steht. Die Anweisung gilt in diesem Fall für alle Audit Daten Dateien unabhängig von ihrem Format. Die Größenangabe erfolgt in KByte.

DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
   audit_trail_type            => AUDIT_TRAIL_FILES,
   audit_trail_property        => OS_FILE_MAX_SIZE,
   audit_trail_property_value  => 512000);

Auch diese Prozedur kann über die entsprechenden Parameter differenziert mit den Oracle proprietären Dateien und den Dateien im XML Format umgehen.

Unabhängig davon, ob Audit Daten in der Datenbank oder in Betriebssystemdateien gespeichert werden, müssen sie irgendwann gelöscht werden, damit sie den verfügbaren Speicherplatz nicht füllen. In der Regel bedeutet das jedoch nicht, dass sie endgültig gelöscht werden, sondern vielmehr, dass sie nach einer Sicherung gelöscht werden. Aber auch wenn das Produkt Audit Vault im Einsatz ist, können die lokalen Audit Daten nach dem übertragen in den Audit Vault Server gelöscht werden.

Das folgende Skript führt zum Löschen der in der Datenbanktabelle AUD$ gespeicherten Audit Einträge, die länger zurückliegen als 2 Tage. Nur vor dem ersten Löschen und nur sofern das Auditing in die Datenbank - also nicht in Dateien des Betriebssystems - erfolgt, muss die Prozedur INIT_CLEANUP verwendet werden. Sie baut die für das Löschen benötigte Infrastruktur auf. Das heißt in dem Beispiel, wenn die Tabelle AUD$ nicht bereits aus dem Tablespace SYSTEM ausgelagert wurde, wird die Tabelle in das Tablespace SYSAUX verschoben. Ausserdem wird ein Löschintervall angegeben, nach dem automatisch gelöscht wird. Das Löschintervall wird in Stunden angegeben. Das Setzen des Zeitstempels und seine Verwendung in der Prozedur CLEAN_AUDIT_TRAIL verhindert, dass alle Audit Einträge gelöscht werden.

BEGIN
  DBMS_AUDIT_MGMT.INIT_CLEANUP(
   audit_trail_type         => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
   default_cleanup_interval => 48);                                 -- Löschintervall ist alle 2 Tage
  DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP(
   audit_trail_type         => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
   last_archive_time        => to_timestamp(sysdate-(2)));          -- älter als 2 Tage
  DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
   audit_trail_type         => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
   use_last_arch_timestamp  => true);
END;
/

DBMS_AUDIT_MGMT stellt neben den hier beispielhaft gezeigten Prozeduren Möglichkeiten bereit, Löschintervalle zu modifizieren, Dateien mit Audit Daten auf der Betriebssystemebene zu verschieben und zu löschen und Jobs anzulegen und zu steuern, die das Löschen auf der Betriebssystemebene automatisieren. Als erste Anregung, sich mit dem Package zu beschäftigen, sollen die bisherigen Ausführungen genügen.

Zurück zur Community-Seite