RAC Housekeeping unter Windows

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

1. die alert_ asm<#>.log in alert_ asm<#>_YYYYMMDD.log umbennennen und
2. 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:

1. alert_<instance>.log in alert_<instance>_YYYYMMDD.log umbennennen und
2. 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

Hier zitiere ich direkt aus Housekeeping 11gR2 RAC :

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.

Quellen:
Housekeeping 11gR2 RAC