Stabilität für Oracle Datenbanken

Warum Standardisierung zur Stabilitätsgewinnung?

"Ordnung ist das halbe Leben." Ein total abgedroschenes Sprichwort - finde ich - unwahr ist es deshalb aber bei Weitem nicht. Ganz im Gegenteil. Meine Erfahrungen als Oracle-DBA haben mich immer wieder zu dem Schluss geführt, dass viele Fehler vermeiden lassen wenn Ordnung herrscht.

Oracle Datenbanken zu betreiben, bedeutet weit mehr als Software Installation, Tablespaces erweitern und Backup. Datenbanken brauchen sehr viel Pflege und Zuwendung, sie sind sehr unbeständig und können ihre Ansprüche daher auch schnell verändern. Kümmert sich ein (DBA) nicht ständig um das Wohlergehen der Datenbanken, so wird bald ein Durcheinander und Wirrwarr entstehen. Dies hat zur wiederum Folge, dass die Performance und Stabilität der Systeme untergraben werden. Es gibt viele Oracle Datenbank Landschaften, die nach genau diesem Prinzip betrieben werden, aber sie sind alles andere als stabil, schnell und zuverlässig.

Meiner Meinung nach ist es also unabdingbar ein klares Konzept zu haben, ein "Handbuch" das eine Verbindliche Vorgehensweise beschreibt, wie Datenbanken unter welchen Umständen zu konfigurieren sind. Damit meine ich nicht nur die Konfigurations-Parameter der Datenbank selbst, sonder insbesondere die Infrastruktur in der diese Datenbank eingefügt ist.

Inhalt der Database Guideline

Was sollte alles in der Database Guideline beschrieben werden? Meine Antwort darauf lautet „ALLES – (fast) alles!“. Alles was nicht individuell für diese eine Datenbank so eingestellt wird muss in diesem Handbuch stehen. Für ein 1-Mann DBA-Büro mag das unsinnig erscheinen - ist es aber nicht. Wer kennt das nicht: "Wie war das gerade nochmal? Ach, wird schon stimmen...". Die Schwierigkeit besteht also darin, zwischen sinniger und unsinniger Dokumentation zu bleiben. Dabei ist aber die unsinnige Dokumentation immer noch besser als keine Dokumentation.

Als Starthilfe will ich hier ein mögliches Inhaltsverzeichnis vorgeben:

1. Host System
   1. Unterstützte Betriebsysteme (je weniger, desto besser)
   2. Benutzer und Benutzer-Gruppen
      1. Oracle Environment (UNIX/Linux)
      2. User und Group-IDs (sehr wichtig z.B. zentralen Script-Shares)
2. Massenspeicher-Medien
3. Datenbank Konfiguration
   1. Pfade für Software
      1. Oracle Datenbank
      2. ASM
      3. Application Server
   2. Pfade für Konfiguration
      1. Oracle HOME und BASE
      2. Parameter Dateien, Scripte, Kleine Helferlein
   3. Pfade für Daten
      1. Oradata
      2. Oraredo
      3. Oraarchive
      4. Oramirror (sofern verwendet)
      5. Flashrecovery Area (sofern verwendet)
   4. Namensauflösung
      1. TNSNAME / LDAP / OID
      2. Ein Standard, wie die Namensauflösung verteilt wird wenn TNANAMES verwendet wird
4. Datenbank Backup
   1. Erläuterungen zum Backup-Konzept
   2. Scheduler
   3. Protokolle, Fehlermeldungen, Fehlerbehandlung
   4. Überwachung
   5. Anbindung an Backup-System
   6. RMAN-Scripte und Usage
5. Hochverfügbarkeit
   1. RAC
      1. […]
   2. DataGuard
      1. […]
   3. Grid Infrastructure
   4. Oracle Restart / init-Scripte
6. Antragsformulare
   1. Klingt bürokratisch, ist aber eine große Hilfe beim Managen von User-Anfragen

Fast alle dieser Punkte sind ein absolutes Muss. Je nach Datenbank Landschaft kommen noch einige Punkte hinzu, ganz besonders im Hochverfügbarkeits-Bereich. Wenn alle diese Punkte Dokumentiert und auf jeder Datenbank umgesetzt sind, so kann ich mit Sicherheit voraussagen, dass eine Grund-Stabilität geschaffen ist.

An dieser Stelle passt das folgende Beispiel aus einem Kundenprojekt: Fast täglich hatte irgend eine Datenbank (von ca. 70-80 Datenbanken) die unterschiedlichsten Probleme, meistens war eine Downtime nicht zu vermeiden. Zunächst wurde das zweiköpfige Datenbank-Team neu aufgestellt, anschließend arbeitete man an einem Konzept zur Standardisierung der Datenbank-Landschaft. Schon während der Umsetzung verringerten sich die Ausfälle immer mehr. Innerhalb von einem halben Jahr wurde das DBA-Team zum Aushängeschild der IT-Abteilung was Zuverlässigkeit der Systeme und Dokumentation anging.

That's IT :-)