Home 
ORDIX News 3/2009 Datenbanken
ORDIX News 3/2009 Datenbanken
ORDIX News 3/2009 Datenbanken
und teilweise automatisieren möchten.
Weiterführende Links
|
In kleinen Unternehmen mit nur einem oder wenigen Datenbankadministratoren fällt das zumeist nicht so sehr auf, so lange Konstanz bei der personellen Besetzung besteht. In einem global agierenden Unternehmen z. B. mit einem "follow the sun" Support, bei dem der Support vom jeweiligen lokalen Team tagsüber übernommen wird, erschwert dies jedoch die Administration und Pflege der Datenbanken ungemein. Im Fall eines kritischen Fehlers verstreicht wertvolle Zeit, bis sich der jeweilige Mitarbeiter auf dem Server zurechtfindet, bevor überhaupt mit der Analyse begonnen werden kann.
Ein weiterer Punkt, der in einem großen Unternehmen zu unnötigen Kosten führt, ist die manuelle Installation. Die Anforderung nach neuen Instanzen, und sei es nur zu Testzwecken, werden fast wöchentlich von den Applikationsteams an die IT-Infrastruktur gestellt.
Daraus lassen sich die folgenden Anforderungen für einen globalen Standard ableiten:
Aus diesen Gründen werden bei einem unserer Kunden globale Standards für nahezu den gesamten Software-Stack definiert. Sie sind die Grundlage für die anschließende technische Umsetzung. In Abbildung 1 ist der Aufbau einer SOU zu erkennen. Wer sich ein wenig im Sybase-Umfeld auskennt, wird hier einige Parallelen wiederfinden. Dies hat den Hintergrund, dass die Standard Oracle Umgebung in Anlehnung zu einer bereits standardisierten Sybase-Umgebung erstellt wurde. Daher könnten einige Namensgebungen (z. B. dumps oder devices) in Bezug zum Oracle-Kontext etwas befremdlich wirken.
Eine Datenbank wird grundsätzlich einem Projekt zugeordnet. Das Projekt wird über ein n-stelliges Kürzel identifiziert und ist der Einstiegspunkt in die Struktur. Jedes Projekt erhält ein eigenes ORACLE_HOME-Verzeichnis. Dadurch sind im Falle einer Patch- Einspielung nur die Datenbank(en) des jeweiligen Projekts betroffen.
Neben diesen essentiellen Vorgaben, existieren weitere Richtlinien für die Benennung der Datenbanken und der abhängigen Services.
Am Beispiel wird nun gezeigt, wie die oben genannten Ziele erreicht werden konnten.
Um die Anforderungen der Oracle-Installation zu erfüllen, wird initial ein "Prepare Package" erstellt. Dieses legt den Benutzer oracle und die Gruppe dba an, setzt Kernel Parameter sowie die Shell Limits und hinterlegt die SSH-Konfiguration, um den Login über einen zentralen Login Server zu ermöglichen.
Unter Solaris wird zusätzlich ein Service eingerichtet, der die Datenbankkomponenten beim Hochfahren startet bzw. beim Herunterfahren stoppt.
Die SOU selbst ist eine Ansammlung von Shell-Skripten, die nach unterschiedlichen Themen unterteilt sind. Ein zentrales Wrapper-Skript (STOra_setup) ist die Schnittstelle zum Benutzer bzw. zum Tivoli Provision Manager (TPM), doch dazu später mehr.
Die Installation selbst besteht bei einer Standard Umgebung aus 4 Schritten. Ein Schritt gruppiert dabei mehrere Shell-Skripte, die einzelne Aufgaben erledigen (siehe Abbildung 2). Die Prepare-Phase der Installation überprüft zunächst, ob alle Bedingungen für die Installation der SOU erfüllt sind. Im Prinzip wird hier getestet, ob das Prepare Package und die damit verbundenen Komponenten installiert sind. Anschließend wird die einheitliche SOU-Verzeichnisstruktur erstellt und die DBA-Skriptsammlung abgelegt.
Die letzte Aufgabe ist nun die Erstellung des Response Files, dass für die Silent-Installation der Datenbank-Software benötigt wird. Sollte es bei einer Aufgabe zu einem Problem kommen, wird der Benutzer darüber informiert. Er hat nun die Chance, den Fehler zu beheben und die Installation erneut zu starten. Dabei wird automatisch wieder an der Stelle aufgesetzt, an der der Fehler aufgetreten ist. Die dafür nötige Logik ist im Wrapper-Skript STOra_setup implementiert.
Die zweite Phase wird mit dem Schritt Software_Install eingeläutet. Hier wird ausschließlich die Datenbank-Software installiert. Anhand einer Konfigurationsdatei und der Benutzerangabe wird entschieden, welche Datenbankversion aufgespielt wird.
Die "Configure" Phase umfasst dann das eigentliche Aufsetzen der Datenbank (create database) und die jeweiligen Nachbereitungen, wie z. B. das Erstellen des spfiles, die Konfiguration der listener.ora, das Implementieren von diversen Security Policies und das anschließende Registrieren der Datenbank im zentralen Repository des Unternehmens.
Der vierte Schritt ist optional und installiert den aktuellen CPU-Patch.
Somit sind für die Installation maximal vier Aufrufe des Wrapper-Skripts nötig, jeweils mit dem entsprechenden Task (-T <Task>), um die Software zu installieren und eine Datenbank aufzusetzen (siehe Abbildung 3).
Es gibt weitere Parameter, die spezifiziert werden können, die für diese Betrachtung jedoch nicht entscheidend sind.
Neben dieser Default-Installation ist es auch erlaubt, bestimmte Eigenschaften der Datenbank vor der Installation zu konfigurieren. Dazu zählen z. B. der Zeichensatz der Datenbank und/oder die Anzahl der Redolog-Gruppen.
Hierfür existiert eine zentrale Konfigurationsdatei, deren Aufbau in Abbildung 4 gezeigt ist. Hier kann z. B. direkt zu Beginn der Installation die Größe der SGA dimensioniert werden, falls die Default-Werte nicht ausreichend sein sollten. Im Prinzip darf jeder beliebige Initialisierungsparameter verändert werden, solange dieser nicht der SOU-Struktur widerspricht. Die Ablage von Control- und archivierten Redologdateien über die Parameter log_archive_dest_[1-9] und control_files dürfen beispielsweise daher nicht angepasst werden und würden abgewiesen.
Um der SOU nun ein schickes Äußeres zu verpassen und die Bedienung weiter zu vereinfachen, wurde diese in den Tivoli Provision Manager (TPM) integriert.
Unser Kunde setzt eine angepasste Oberfläche des TPM ein, die eine effizientere Bedienung ermöglicht. Durch die Anbindung an das zentrale Host Repository kann nun im Webbrowser über wenige Schritte der zu bespielende Server ausgewählt werden. Selbstverständlich können auch hier sämtliche Eigenschaften der Datenbank vom Benutzer festgelegt werden. Sind die Informationen vollständig, sorgt TPM für den Aufruf der Skripte.
Eine weitere Interaktion seitens des Benutzers ist nun nicht mehr erforderlich. Das Aufspielen der Software und das Installieren der Datenbank läuft selbstständig im Hintergrund. Die Ausgabe der Skripte und eventuelle Fehlermeldungen können im Browser-Fenster bei Bedarf betrachtet werden. Über TPM ist es so auch möglich, direkt mehrere Server parallel zu bespielen, was den Aufwand für den einzelnen DBA nochmals erheblich reduziert.
Neben der Oracle Standard Umgebung existieren eine ganze Reihe von weiteren Standardisierungen, die die in der Einleitung genannten Kriterien erfüllen. Dieses gilt nicht nur im Datenbankbereich, sondern auch für die Betriebssystemebene. So kann ein Server in sehr kurzer Zeit komplett bespielt und an das Applikationsteam übergeben werden.
Durch neue Anforderungen sind mittlerweile weitere Komponenten in die SOU eingeflossen. So kann neben der Datenbank auch ein vollständiger Oracle Unix Client und das Ausrollen von Oracle Grid Control Agenten über eine Standard-Installation eingeleitet werden.
Komplettiert wird die SOU durch die automatische Installation der Clusterware auf einer beliebigen Anzahl von Knoten als Voraussetzung für den Einsatz von Oracle RAC.
Durch die Einführung eines standardisierten Verfahrens zum Aufsetzen von Datenbanken konnten viele Vorteile gewonnen werden. Der "follow the sun" Support findet in jeder Lokation dieselbe Struktur vor. Das Aufsetzen von neuen Datenbanken ist nun keine Tagesaufgabe mehr. Auch das Patchen von Instanzen, die standardisiert eingerichtet sind, wurde vereinfacht. Zudem ist die Installation von Datenbanken für eingekaufte Anwendungen hierdurch vereinheitlicht worden.
Die Anzahl der Datenbanken die nun SOU-konform sind, lag zum Ende des Projekts bei 40 % (siehe Abbildung 5).
