Achtung: extremes Wachstum des SYSAUX-Tablespaces durch Unified Auditing

Veröffentlicht am von

In Oracle 12 wird mit dem sog. Unified Auditing eine neue Form des Datenbank-Auditings eingeführt. Dieses Modul muss aktiviert werden, um es nutzen zu können. Leider zeigt sich, dass jedoch auch bei Nicht-Aktivierung lästige Nebeneffekte auftreten können.

In jeder neuen 12c-Datenbank wird ein Schema namens AUDSYS angelegt, dem eine Tabelle des Formats CLI_SWP$xxxxxx gehört. In diese Tabelle werden Informationen  gemäß vordefinierter  Auditing-Policies unabhängig von den bisher verwendeten Auditing-Instanz-Parametern eingetragen – dummerweise auch dann, wenn man das Unified Auditing gar nicht aktiviert hat, sondern z.B. nur gewisse DDL-Statements mit dem seit jeher bekannten „normalen“ Auditing überwachen möchte. Die Tabelle liegt im SYSAUX-Tablespace; eine Spalte hat den Datentyp BLOB, in dem die auditierten SQL-Statements und Bindevariablen-Inhalte gespeichert werden, ähnlich wie in der bekannten Tabelle SYS.AUD$.

Die vordefinierten Policies ORA_SECURECONFIG und ORA_LOGON_FAILURES werden standardmäßig auditiert. Sie beinhalten das Auditing so gut wie aller Privilegien und diverser Aktionen sowie aller Datenbank-Logins inkl. SYSDBA-Logins.

Man kann sich vorstellen, dass die Tabelle innerhalb relativ kurzer Zeit sehr stark anwachsen kann. Daher existieren auch diverse Purge-Mechanismen, die jedoch leider zwar die Datensätze aus der Tabelle, aber nicht das zugehörige LOB-Segment entfernen.

Damit nicht genug, ist die Tabelle auch Read Only – das heißt, es ist weder möglich, diese per truncate table zu leeren, zu löschen noch sie auch nur in einen anderen Tablespace zu verschieben oder sonst irgendwie zu reorganisieren. Da die Tabelle im SYSAUX-Tablespace liegt, gestaltet es sich quasi unmöglich, den einmal allokierten Platz zurückzugewinnen.

Hierbei handelt es sich laut MOS um einen Bug:

Bug 18109788 – CLEANUP OF UNIFIED AUDIT TRAIL DOES NOT RELEASE LOB SEGMENT SPACE

Es gibt keinen Workaround hierfür im aktuellen Release. Ist das LOB-Segment einmal auf diverse GB angewachsen (und das geht schneller, als man denkt), wird man es nicht mehr los. Das einzige, was man dann noch tun kann, ist, das weitere Wachstum durch die Deaktivierung des Auditings der genannten Policies zu stoppen:

NOAUDIT POLICY ora_secureconfig;
NOAUDIT POLICY ora_logon_failures;

Hierbei ist natürlich zu beachten, dass dieses Mittel nur eingesetzt werden kann, wenn man Unified Auditing tatsächlich NICHT nutzen möchte. Ansonsten muss man sich wohl leider bis zum Fix des Bugs gedulden…

Nachzulesen in MOS (https://support.oracle.com), Doc IDs

1624051.1: The UNIFIED_AUDIT_TRAIL is Getting Populated even if Unified Auditing was not explicitly enabled in 12c

sowie

1935169.1: DBMS_AUDIT_MGMT does not release the space occupied by LOB segment

 

4 Gedanken zu „Achtung: extremes Wachstum des SYSAUX-Tablespaces durch Unified Auditing“

  1. Hallo Frau Jahr,
    bin zufällig auf Ihren Blog Eintrag gestoßen… Es gibt einen Workaround für das Problem: Man verschiebt die Unified Audit Tabellen in einen anderen Tablespace und führt anschließend einen kompletten Cleanup des Unified Audits aus:
    — tablespace anlegen, hier UNIFIED_WORKAROUND
    dbms_audit_mgmt.set_audit_trail_location(dbms_audit_mgmt.audit_trail_unified,’UNIFIED_WORKAROUND‘);
    exec dbms_audit_mgmt.clear_last_archive_timestamp(dbms_audit_mgmt.audit_trail_unified)
    exec dbms_audit_mgmt.clean_audit_trail(dbms_audit_mgmt.audit_trail_unified,FALSE)

    Probieren Sie es mal aus, bei mir funktioniert es…

    P.S. Schöne Grüße an Uwe Herrmann

    Holger Timm

  2. Pingback: Neues vom SYSAUX-Tablespace... - Herrmann & Lenz BlogHerrmann & Lenz Blog

Schreibe einen Kommentar