Wie man seinen RAC sauber hält, wird in diesem Artikel der Deutschsprachigen DBA-Community von Sebastian Solbach beschrieben:
Housekeeping 11gR2 RAC
Wie fast immer wird sich auf Linux bezogen. Ich fasse das Ganze für Windowsserver zusammen.
Ich bin einer der [ironie]Glücklichen[/ironie], der einen RAC auf WindowsServer2008 administriert.
Der Betrieb des RAC verläuft recht problemlos, was dazu verleitet, den vielen Log-Dateien nicht die Aufmerksamkeit zu schenken, die sie verdienen – und sei es nur, sie zu löschen.
Log- und Tracedateien fallen im Grunde in 2 Bereichen an:
- In der Grid-Infrastruktur
- Datenbanken
GRID-Infrastruktur
Ein Großteil der Logdateien wird von der Clusterware verwaltet. Unterhalb von %GRID_HOME%\log\<host>\ liegen diverse Unterverzeichnisse mit rollierenden Logdateien. Bis auf 2 Ausnahmen muss man sich um nichts kümmern.
Folgende Logs auf jedem Node müssen manuell behandelt werden:
- Das Clusterware-alert.log: %GRID_HOME%\log\<host>\alert<host>.log
- Die Logs unterhalb: %GRID_HOME%\log\<host>\client\*
Alert.log - Clusterware
Das
alert<host>.log wächst langsam. Auf meinem Beispielcluster mit 2 Knoten sind es nach einem Jahr Betrieb 15 bzw. 50MB.
Unter Windows kann das Logfile aber nicht wie unter Linux bei laufender Clusterware rolliert werden, da sich die Datei im Zugriff befindet.
Es bietet sich also an, das Log manuell im Zuge eines Wartungsfensters bei Windowsupdates zu rollieren.
Eine jährliche Rotation sollte ausreichen.
Ein Skript könnte so aussehen und im Zuge der Wartung per Windows-Scheduler beim Serverstart ausgeführt werden:
set GRID_HOME=D:\oragrid\11.2.0.3
set GRID_HOST=RAC1
set LOGPATH=%GRID_HOME%\log\%GRID_HOST%
set jahr=%date:~-4%
set monat=%date:~-7,2%
set tag=%date:~-10,2%
set LOGDATE=%jahr%%monat%%tag%
copy %LOGPATH%\alert%GRID_HOST%.log %LOGPATH%\alert%GRID_HOST%_%LOGDATE%.log
type nul > %LOGPATH%\alert%GRID_HOST%.log
OCRDUMP, OCRCHECK, OCRCONFIG, CRSCTL
Unterhalb
%GRID_HOME%\log\<host>\client\* finden sich viele kleine Logdateien, die bei administrative Aufrufen von z.B. ocrcheck erzeugt werden.
Auf meinem Produktivsystem summierte sich der Platzbedarf innerhalb eines Jahres auf 200-250MB je Node. Mit diesem Skript kann man der Plage Herr werden:
set GRID_HOME=D:\oragrid\11.2.0.3
set GRID_HOST=RAC1
set LOGPATH=%GRID_HOME%\log\%GRID_HOST%
forfiles /P %LOGPATH%\client\ /S /M *.* /D -7 /C "cmd /c del /q @path"
Es löscht alle Dateien älter als 7 Tage. Wenn man das täglich oder monatlich über den Scheduler startet, hat man seine Ruhe.
Listener.log, listener_scan<#>.log rollieren
Auf jedem Knoten die Listener.log- und listener_scan1.log bis listener_scan3.log-Dateien umbenennen. Zum Beispiel:
%GRID_HOME%\log\diag\tnslsnr\<host>\listener\trace
%GRID_HOME%\log\diag\tnslsnr\<host>\listener_scan1\trace
%GRID_HOME%\log\diag\tnslsnr\<host>\listener_scan2\trace
%GRID_HOME%\log\diag\tnslsnr\<host>\listener_scan3\trace
Es genügt, die ursprüngliche log umzubenennen/löschen. Beim nächsten Eintrag wird eine neue Datei generiert.
Die Größe der Logs ist natürlich abhängig von der Aktivität auf dem Cluster. Auf meinem Beispielsystem liegen nach einem Jahr insgesamt 1,5GB an Listener-Logs vor.
Eine monatliche Rotation ist empfehlenswert.
ASM
Die Log- und Trace-Files der ASM-Instanzen werden im Automatic Diagnostic Repository gespeichert.
Das Housekeeping ist automatisiert.
Einstellungen zum Löschen alter Informationen:
- Default 30 Tage
- 365 Tage für das mechanische Alert File
Das Alert-log der ASM-Instanzen findet sich hier:
%ORACLE_BASE%\diag\asm\+asm\asm<#>\trace\alert_ asm<#>.log
Zum rollieren einfach
- die alert_ asm<#>.log in alert_ asm<#>_YYYYMMDD.log umbennennen und
- eine neue alert_ asm<#>.log anlegen.
Außerdem muss man sich um die Tracefiles unter
%GRID_HOME%\RDBMS\trace selbst kümmern.
Datenbanken
Die RAC-DB verhalten sich wie die ASM-Instanzen:
Das Housekeeping wird vom ADR erledigt und um das alert.log muss sich der Admin kümmern.
Alert.log
Wie bei der ASM-Instanz auf allen Knoten unter
%ORACLE_BASE%\diag\rdbms\<database>\<instance>\trace:
- alert_<instance>.log in alert_<instance>_YYYYMMDD.log umbennennen und
- neue alert_<instance>.log anlegen.
Sonstiges
OCR
Weiterhin gibt es laut
Housekeeping 11gR2 RAC unter
%GRID_HOME%\cdata\<cluster>\ Sicherungen der OCR, die periodisch erzeugt und gelöscht werden müssen. In meiner WindowsServer-Installation existieren die angesprochenen Sicherungen nicht an dieser Stelle oder anderswo im GRID_HOME. Ich sehe bei Gelegenheit nach, ob diese in der ASM zu finden sind.
Auditfiles der ASM- und Datenbankinstanzen
Anders als in
Housekeeping 11gR2 RACbeschrieben, existieren unter Windows diese Logs nicht im Filesystem. Dieses Auditing findet man in der Ereignisanzeige:
 |
| Event Viewer |
Enterprise Manager DB Console / Enterprise Management Agent
Unterhalb %ORACLE_HOME%\<knoten>_<dbuniquename>\sysman\log befinden sich logs und tracefiles der DBCansole. Innerhalb eines Jahres kamen hier 120MB zusammen.
Monatliches Rollieren und Löschen kann nicht schaden.
cfgtoollogs
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.
Je nach Aufkommen monatliches oder jährliches Löschen.
Fazit
Ob es sich lohnt bei einem 2-Knoten-RAC alle Einzelschritte zu verskripten ist Geschmackssache. Da das Datenaufkommen so gering ist, dass es genügt, die logs monatlich zu rollieren oder zu löschen, ist es zu verschmerzen, dies manuell zu erledigen. Netter Nebeneffekt: Man hat regelmäßig die Verzeichnisstruktur vor Augen.
Wenn man das Ganze in ein oder mehrere Skripte gießen und das gleich richtig machen will, bietet sich auf einem WindowsServer natürlich PowerShell an, statt lauter Batchdateien anzulegen.
