Logo Oracle Deutschland   DBA Community  -  August 2012
Housekeeping 11gR2 RAC
von Sebastian Solbach, ORACLE Deutschland B.V. & Co. KG

11g Release 2 Real Application Cluster ist nun schon seit geraumer Zeit verfügbar und bei vielen Kunden im produktiven Einsatz. Im Normalfall laufen diese Systeme rund um die Uhr - höchstens unterbrochen durch das Einspielen eines Patches.

Bei laufenden Systemen schenkt der Administrator allen anfallenden Log-, Trace- und anderen Files - wie zum Beispiel Sicherungskopien der Oracle Cluster Registry (OCR) - die Oracle an vielen Stellen zur Analyse/Sicherung ablegt keine weitere Beachtung. Schaut man aber trotzdem genauer auf die ORACLE_HOME Verzeichnisse der Installation, so wird man bemerken, dass im Gegensatz zu einer neuen Installation der zur Verfügung stehende Plattenplatz doch erheblich reduziert ist.

Zwar hat Oracle an vielen Stellen vorgesorgt, dass Logfiles rotieren oder alte automatisch gelöscht werden, leider trifft dies aber nicht für alles zu. Ein Grund mehr sich einmal anzuschauen, in welche Verzeichnisse der Oracle RAC mit seiner Grid Infrastruktur Informationen ablegt und welche Verzeichnisse man im Bezug auf den verwendeten Speicherplatz im Auge behalten sollte. Zur besseren Übersicht werden im Artikel Verzeichnisse oder Dateien, die nicht von der Oracle Software gemanaged werden und ein manuelles Eingreifen erfordern, im Text rot markiert.

Der Artikel ordnet dabei die erzeugten Dateien den einzelnen Bereichen innerhalb eines Real Application Clusters zu. Durch diese Unterteilung lassen sich so auch auf Single Instanz Umgebungen Rückschlüsse ziehen. Hierbei wird die Oracle Clusterware trotz der vielen Unterprozesse als Ganzes betrachtet und nicht weiter unterteilt, da die erzeugten Dateien alle ähnlich gestaltet sind:

Oracle Clusterware Log-, Trace-Files und Anderes

Alle Prozesse der Oracle Clusterware legen ihre Logfiles unter $GI_HOME/log/<knotennamen> ab. Dabei schreiben alle Prozesse rollierende Logfiles: Das Orginal (*.log) wird umbenannt in *.l01. Gibt es bereits ein *.l01 wird dieses in *.l02 umbenannt und so weiter - bis *.l10. Das 12. Logfile (ehemaliges *.l10) wird gelöscht. Damit ist bei den meisten Prozessen der Clusterware kein explizites Housekeeping notwendig, da dieses von den Prozessen selber übernommen wird. Die Größe der Logfiles richtet sich dabei nach dem Prozess und ist nicht parametrisierbar. So sind dies in 11.2.0.2 für den CSSD Prozess und Diskmon Prozess 50 MB pro Logfile für alle anderen, wie z.B. den Oraagent, 10MB.

Einzige Ausnahme zu dieser Regel sind das alert<knotennamen>.log und die Logfiles im "client" Unterverzeichnis:

  • Das Alert<knotennamen>.log wächst allerdings sehr langsam, falls es im Cluster zu keinen Problemen kommt. So gibt es Cluster, bei denen diese Datei nach ca. 1 Jahr gerade einmal die Größe von 50 MB erreicht. Dies ist auch das einzige Logfile des Clusters, bei dem es sich lohnt, dieses länger aufzubewahren, ähnlich wie das Alert.log der Datenbank. Falls man dieses "schrumpfen" möchte empfiehlt es sich, die Datei in jedem Fall vorher wegzusichern und dann zu "leeren":
    $ cp alert<knotennamen>.log alert<knotennamen>.l01
    $ echo "" >alert<knotennamen>.log
    
  • Im $GI_HOME/log/<knotennamen>/client Verzeichnis befinden sich die Logfiles von Aufrufen administrativer Befehle, wie z.B. ocrcheck oder ocrconfig. Da hier für jeden Aufruf ein Logfile angelegt wird, sollte man in diesem Verzeichnis öfters mal die alten Logfiles löschen, insbesondere dann, wenn man sich zur Überwachung des Clusters eigene Skripte geschrieben hat, die sich dieser Befehle bedienen. Auch im Datenbank Home findet sich dieses Client Verzeichnis ($ORACLE_HOME/log/<Nodename>/client). Hier fallen aber kaum so viele Logfiles an, als dass man diesem Verzeichnis Beachtung schenken müsste.

  • Neben den Logfiles kann es bei einer laufenden RAC Umgebung noch eine andere Ursache für erhöhten Plattenplatzbedarf der Grid Infrastruktur geben. Hierbei handelte es sich um die periodische Sicherung der OCR, bei der in den Vorgänger Versionen nur 7 aktuelle Sicherungen gespeichert wurden (3 aktuelle (vor 4/8/12 Stunden), 2 tägliche (letzte/vorletzte Nacht) und 2 wöchentliche). In manchen Fällen werden aber auch alle anderen Sicherungen unter $GI_HOME/cdata/<cluster> mit beibehalten, weshalb auch hier die älteren Files gelöscht werden sollten. Die Namen dieser zusätzlichen Dateien beginnen alle mit 8 Zahlen gefolgt von .ocr im Gegensatz zu dem Backup (backup00.ocr) - sind aber auch leicht anhand des dazugehörigen Datumsstempels der Datei zu erkennen.

    ASM Log-, Trace- und Audit-Files

    Die ASM Instanz hat, genau wie eine normale Datenbank Instanz, einen automatisches Mechanismus ihre alten Log- und Trace-Files zu löschen. Per Default geschieht dies alle 30 Tage für Trace Dateien und Core Dumps und 365 Tage für die Alert Informationen. Diese Defaults sind, wie im Tipp ADRCI: Automatic Diagnostic Repository Command Interpreter beschrieben parametrisierbar oder lassen sich durch den aktiven Aufruf von
    $ adrci exec="SET HOME asm; purge -age 10"
    
    bereinigen. Das obige Statement würde Logfiles, die älter als 10 Tage sind, löschen.

    Einzige Ausnahme hierzu ist wieder das Alert+ASM#.log, welches sich unter $ORACLE_BASE/diag/asm/+asm/+ASM<#>/trace befindet. Dies könnte man ähnlich sichern bzw. rollieren wie oben schon beim Alert.log der Clusterware beschrieben.

    Leider scheinen die System Audit Files der Datenbank-/ASM Instanzen nicht zu den Standard Logfiles zu zählen. Diese werden weder in die DIAG Verzeichnisstruktur gelegt, noch unterliegen diese einem automatischen Löschmechanismus. Diese Audit Files werden noch nicht einmal kumulativ geschrieben, so dass für jeden Anmeldeversuch als SYS an die ASM Instanz ein *.aud File nach $GI_HOME/rdbms/audit geschrieben wird. Dies wäre nicht weiter schlimm, wenn die Clusterware nicht jede Minute den Status der ASM Instanz mit einem "Connect" prüfen würde und die Datenbank Instanzen im Cluster sich nicht als SYSDBA verbinden würden. Dadurch sammeln sich schon nach relativ kurzer Zeit eine Masse an sehr vielen kleinen Audit Dateien in dem angesprochenen Verzeichnis an. Dies ist allerdings kein Bug (MOS Note 813416: A Lot of Audit Files in ASM Home) und es gibt einen eigenen Artikel (MOS Note 1298957.1 Manage Audit File Directory Growth with cron), wie damit umgegangen wird. Eine Schwierigkeit liegt in der Unmenge an kleinen Dateien, die häufig ein einfaches Löschen über den Befehl "rm" unmöglich macht. Es gibt 2 Alternativen dies trotzdem zuverlässig zu löschen - eine mit Hilfe des Befehls "find", wie er auch in der erwähnten MOS Note 1298957.1 steht. Allerdings kann gerade beim ersten Einsatz des Find Befehls der Löschvorgang sehr viel Zeit in Anspruch nehmen. Die andere Alternative bedient sich der Funktion "unlink", wodurch einfach der Dateieintrag aus dem Filesystem gelöscht wird:
    #!/bin/sh
    cd /u01/11.2.0.2/grid/rdbms
    perl -e 'chdir "audit" or die; opendir D, "."; while ($n = readdir D) { unlink $n }'
    
    Dies verwende ich z.B. täglich bei meinem Cluster als Cronjob unter /etc/cron.daily.

    Oracle Listener und SCAN Listener Log- und Trace-Files

    Die Listener Log- und Trace-Files werden standardmäßig ebenfalls unter $ORACLE_BASE/diag gespeichert und unterliegen ebenfalls dem Automatic Diagnostic Repository. Allerdings gibt es nicht wie bei der Datenbank einen zuständigen Prozess, der in regelmäßigen Abständen die alten Log- und Trace-Files löscht. Deswegen sollte man hier zwingend - wie oben bei der ASM Instanz optional erwähnt - die Logfiles in regelmäßigen Abständen löschen. Folgendes Shell Script unter /etc/cron.daily würde täglich dafür sorgen, alle Log- und Trace-Files der Listener, die älter als 30 Tage sind zu löschen:
    #!/bin/sh
    
    export ORACLE_HOME=/opt/11.2.0.2/grid
    export ORACLE_BASE=/opt/oracle
    
    $ORACLE_HOME/bin/adrci exec="SET HOME listener; purge"
    $ORACLE_HOME/bin/adrci exec="SET HOME listener_scan1; purge"
    
    Beim Listener gelten dieselben Grundeinstellungen zur Default Aufbewahrungszeit von Logfiles. Falls Sie zusätzliche Listener verwenden, können diese ebenfalls in das Shellscript mit aufgenommen werden.

    Auch hier gibt es ähnlich zum Alert.log das Listener.log im Verzeichnis $ORACLE_BASE/diag/tnslsnr/<knoten>/listener/trace, welches nicht der Überwachung des ADR unterliegt und dementsprechend selber gesichert und gelöscht werden sollte.

    Oracle Datenbank Log-, Trace- und Audit-Files

    Für die RAC Datenbank Instanzen gilt eigentlich dasselbe, wie für die ASM Instanzen. Deren Log- und Trace-Files werden im Automatic Diagnostic Repository gespeichert und unterliegen dessen Einstellungen zum Löschen alter Informationen (Default 30 Tage bzw. 365 Tage für das mechanische Alert File). Die Datenbank Instanz ruft den Löschjob ihrer Files selber auf, so dass das Housekeeping eigentlich von alleine geschieht. Auch hier ist das Alert<instanz>.log in der alten Form ($ORACLE_BASE/diag/rdbms/<instanzname>/trace) nicht betroffen und das Management dieses Files muss manuell erfolgen.

    Allerdings gibt es hier noch eine Ausnahme, wenn man mit RAC One Node oder Policy Managed Datenbanken arbeitet. Da die Server und Instanz Namen im Falle von Policy Managed Datenbanken nicht fix sind, bzw. wie bei RAC One Node nicht immer auf demselben Knoten laufen, läuft der Prozess für das aktive Löschen der diag Informationen nur auf dem Knoten, auf dem die Instanz gerade läuft. Dies ist zwar nicht besonders schlimm, da davon ausgegangen werden kann, dass die Instanz auch wieder auf den im Moment inaktiven Knoten wechselt. Trotzdem bleiben dadurch natürlich die älteren Informationen stehen, was nicht besonders übersichtlich ist.

    Als Workaround (nicht nur für die Datenbank Instanzen, sondern gleich auch für alle anderen ADR basierten Logfiles, wie die des Listener) kann man einen Cron Job anlegen, der durch die Homes des ADR scrollt und bei diesen nacheinander den Befehl "Purge" ausführt:
    #!/bin/sh
    export ORACLE_HOME=/opt/11.2.0.2/grid
    export ORACLE_BASE=/opt/oracle
    
    for home in `adrci exec="show home"`;
     do
      if [[ ( "$home" != "ADR" ) && ( "$home" != "Homes:" ) ]]
      then
       $ORACLE_HOME/bin/adrci exec="SET HOME $home; PURGE";
      fi;
    done;
    
    Dieses Skript funktioniert auch generell für die oben erwähnten Listener Logfiles.

    Auch beim Datenbank Home gibt es die Audit Files für das Login des SYS Operators. Zwar treten diese hier deutlich weniger häufig auf, als bei der ASM Instanz trotzdem sollte auch hier das Wachstum der Dateien im Auge behalten werden. Natürlich funktionieren dieselben Tipps und Befehle wie für die ASM Instanz, nur dass die Audit Files bei Datenbanken per Default im Verzeichnis $ORACLE_BASE/admin/<dbname>adump zu finden sind.

    Zusätzlich finden sich unter Umständen Tracefiles (*.trc) unter $ORACLE_HOME/rdbms/log. Auch dieses Verzeichnis sollte hin und wieder geleert werden.

    Enterprise Manager DB Console / Enterprise Management Agent

    Die Enterprise Manager DB Console ist in 11gR2 noch nicht in die ADR Struktur integriert. Zwar sind auch hier schon einige Logfiles, die sich unter $ORACLE_HOME/<knoten>_<dbuniquename>/sysman/log befinden, rollierend, allerdings nicht die dazugehörigen Tracefiles. Deswegen sollten auch in diesem Verzeichnis regelmäßig die Tracefiles geleert werden. Dies kann wie bei allen Files, die sich im Moment noch im Schreiben befinden, über ein "echo "" > logfile" geschehen.

    Im Gegensatz zur Enterprise Manager DB Console bringt der Enterprise Management Agent von 12c Cloud Control die Integration in das Automatic Diagnostic Repository mit. Zwar liegt das ADR Base hier an einer anderen Stelle als das generelle Oracle Base, die Log- und Trace-Files sind somit aber schnell im Griff, da auch dieses ADR dieselben Einstellungen bietet und der Befehl "Purge" des ADRCI automatisch die älteren Files entfernt.

    Sonstiges & Fazit

    Zu den bisher erwähnten Dateien sollte man noch auf das cfgtoollogs Verzeichnis (im $ORACLE_BASE und $ORACLE_HOME) achten. Je nach dem ob man häufiger mit OPatch die Oracle Homes überprüft, EMCA verwendet, um den Enterprise Manager umzukonfigurieren, oder den DBCA um Datenbanken anzulegen. Jedes dieser Tools schreibt ein Log in das entsprechende cfgtoollogs Verzeichnis. Sollte man in Skripten oder ähnlichem diese Tools periodisch verwenden, sollte auch das cfgtoollogs Verzeichnis von den anfallenden Logfiles befreit werden.

    Für viele Fälle bringen die RAC Datenbanken und Grid Infrastruktur ihre eigenen Housekeeping Prozesse mit. Gerade aber aus Rücksicht auf andere Managementtools werden auch ältere Arten der Logfiles noch mitgepflegt (insbesondere das Alert.log). Eben dieses fällt wie einige andere nicht unter das automatische Housekeeping und bedarf auch in 11gR2 besonderer Pflege und Beachtung. Sollten Sie auf die angesprochenen Verzeichnisse, Log- und Tracefiles achten, dürfte Ihnen aber auch in Zukunft der Plattenplatz bei den Oracle Installationen nicht so schnell ausgehen.

    Nützliche Links und Referenzen

  • Manage Audit File Directory Growth with cron (Doc ID 1298957.1)
  • A Lot of Audit Files in ASM Home (Doc ID 813416.1)
  • Zurück zur Community-Seite