Datenbankadministration - Versuch einer

Datenbankadministration - Versuch einer Begriffsklärung
Harald Schöning
Software AG
Uhlandstr. 12
D-64297 Darmstadt
Einleitung
Wohl für jede Datenbank, die sich im praktischen Einsatz befindet, gibt es einen Datenbankadministrator (DBA). Die Aufgabe eines DBA ist Datenbankadministration (und alle Datenbankverwaltungssysteme (DBVS) bieten eine ausgedehnte Palette von Werkzeugen dafür) was genau ist aber ist Datenbankadministration? Zu den Aufgaben eines DBA gehören auch
Tätigkeiten wie z.B. das Training von Anwendern [SAG95], die man i.a. nicht als Datenbankadministration bezeichnen würde. Andererseits gibt es auch Tätigkeiten, die man sehr wohl
als Datenbankadministration bezeichnen sollte, die aber nicht von einem DBA, sondern von
Operateuren o.ä. ausgeführt werden [KP96]. Der vorliegende Beitrag hat das Ziel, das Thema
Datenbankadministration zu untergliedern, dadurch genauer zu fassen und einen Rahmen für
die Einordnung der Beiträge zum Frühjahrstreffen der GI-Fachgruppe Datenbanken zu bieten.
Auf diese Beiträge wird auch jeweils bei den einzelnen Unterpunkten verwiesen.
Zunächst wird Datenbankadministration in drei Gebiete aufgeteilt: die Datenadministration,
die Benutzeradministration und die Systemadministration, die man vielleicht auch als Datenbankadministration im engeren Sinne bezeichnen könnte. Deshalb wird letztere dann nochmals untergliedert.
Datenadministration
Datenadministration umfaßt den logischen und physischen Datenbank-(Schema-)entwurf und
die Datenpflege. Aus dem logischen Datenbankentwurf ergeben sich für den Datenbankadministrator die Tätigkeiten der Schemadefinition (Definition von Tabellen, Domains, Constraints, etc.). In SQL gibt es hierfür die DDL-Anweisungen.
Tätigkeiten wie das Einrichten und Löschen von Zugriffspfaden, das Partitionieren und Replizieren von Daten, etc. ergeben sich aus dem physischen Datenbankentwurf. Die Planung von
Replikation ist dabei ein relativ neuer Aspekt, der jedoch sehr komplex ist, da neben der Entscheidung, welche Daten wo repliziert werden, auch entschieden werden muß, ob die Änderungsstände der Replikate immer gleich sein müssen (synchrone Replikation) oder in welchem Maße sie voneinander abweichen dürfen. Zum physischen Datenbankentwurf gehören
auch die Kapazitäts- und Leistungsplanung. Es handelt sich bei all diesen Tätigkeiten um die
deskriptive Definition eines Datenbankzielzustandes.
Das Wiederherstellen dieser definierten Eigenschaften, die ggf. durch den Datenbankbetrieb
bedingt nicht mehr vollständig erfüllt sind, ordne ich als Datenreorganisation der Datenbankadministration zu. Je nach DBVS ist solche eine Datenreorganisation nicht erforderlich oder
wird durch das DBVS selbst vorgenommen.
Benutzer- und Sicherheitsadministration
Manche Daten müssen besonders gegen unbefugten Zugriff oder unerlaubte Veränderung geschützt werden. Der DBA muß für diese Daten einen Zugriffsschutz einrichten. Dieser kann
auf Tabellen- oder Feldebene definiert werden oder auch wertabhängig für bestimmte Datensätze eingerichtet werden.
Manche Datenbanksysteme erlauben auch die Definition weiterer Sicherheitsmaßnahmen gegen unbefugten Zugriff auf die physischen Speichermedien. Mögliche Optionen sind hier beispielsweise die Erzwingung physischen Löschens bei logischem Löschen oder das Verschlüsseln der abgespeicherten Daten auf dem Speichermedium.
Das Einrichten und Löschen von Benutzerkennungen (im Datenbanksystem) und die Vergabe
von Zugriffsrechten für diese Benutzerkennungen gehören ebenfalls zu diesem Thema. Dem
entsprechen die GRANT-/REVOKE-Anweisungen in SQL.
An Benutzerkennungen können auch weitere Privilegien geknüpft sein,z.B. die Befugnis, eine
bestimmte Menge von Systemresourcen verbrauchen zu dürfen (Bswp. maximale Zeit pro
Transaktion).
Zur Laufzeit kann der DBA die Transaktionen von Benutzern anhalten oder abbrechen, oder
die benutzerspezifischen Parameter für eine Transaktion des Benutzers ändern (Priorität z.B.).
Systemadministration ( Datenbankadministration im engeren Sinne)
Folgende Abschnitte konkretisieren den Begriff Systemadministration. Allen Aspekten gemeinsam ist zum einen die Tatsache, daß die Mitwirkung des DBA gefordert ist, zum anderen, daß es keine SQL-Konstrukte für diese Aktionen gibt.
Installation
Hierzu gehört nicht nur das Einspielen des Codes des DBVS oder der Upgrade auf eine neue
Version, sondern auch die Definition der zu verwendenden Speichermedien, die Aufteilung
der Daten auf diese und ggf. deren Formatierung.
Datensicherung und -wiederherstellung
Datensicherung in diesem Sinne dient der Sicherung der Daten vor Zerstörung (durch Datenträgerausfall, Fehler in Hard- oder Software oder Benutzerfehler). Die Daten werden - gesteuert durch den DBA - in normalerweise regelmäßigen Abständen gesichert (auf Bänder oder
ähnliche Speichermedien) und an einem sicheren Ort gelagert (im Tresor, oft an einem geographisch verschiedenen Ort). Tritt ein Datenverlust auf, dann wird eine dieser Sicherungskopien eingespielt. Anschließend werden die Änderungen, die seitdem im Datenbanksystem durchgeführt wurden, anhand eines System-Logs nachgespielt. Das bedeutet, daß auch
diese System-Logs an einem sicheren Ort (und auf einem getrennten Medium) verwahrt werden sollten.
Es handelt sich hier nicht um das Gebiet der Crash-Recovery (Wiederanlauf), d.h. um den
Datenbankstart nach einem Systemfehler. Dieser sollte im Normalfall ohne Mitwirkung des
DBA erfolgen und muß von diesem auch nicht besonders vorbereitet werden.
Während die Datensicherung eine Routineaufgabe sein muß, falls sie erfolgreich sein soll, ist
die Datenwiederherstellung eine zeitkritische Ausnahmetätigkeit. An die Datensicherung
kann es verschiedene Anforderungen bezüglich ihres Verhaltens geben, wie z.B. minimale
Dauer (z.B., wenn sie off-line geschieht) oder möglichst geringe Belastung des Datenbanksystems im on-line-Fall oder ggf. damit zusammenhängend eine möglichst geringe Datenmenge: inkrementelle Sicherung (nur die seit der letzten Sicherung geänderten Daten) oder
partielle Sicherung (nur Teile der Datenbank, z.B. einzelne Tabellen). Die Wahl des Sicherungsverfahrens kann die Dauer der Datenwiederherstellung beeinflussen.
Datenarchivierung
Datensicherung dient lediglich dazu, den aktuellen Datenbestand der Datenbank vor dem Verlust zu bewahren. Das zeigt sich u.a. daran, daß die Datensicherung nicht nach logischen, sondern eher nach organisatorischen Kriterien erfolgt, z.B. in regelmäßigen Abständen oder
wenn die Datenbank ohnehin off-line ist, und daß nach Erzeugung einer Datensicherung ältere Sicherungen gelöscht werden.
Im Gegensatz hierzu soll Datenarchivierung den Datenbestand zu einer bestimmten Zeit festhalten, beispielsweise zu Revisionszwecken oder aus rechtlichen Gründen. Schneller Zugriff
auf die Archivdaten ist u.U. nicht erforderlich (es kann Tertiärspeicher eingesetzt werden).
Nach heutigem Stand der Technik sind Archivsicherungen nicht ohne weiteres mit den normalen Mitteln des Datenbankverwaltungssystems zugreifbar. Normalerweise muß die gesamte Datenbank (mit den Beschreibungsdaten) gesichert werden, so daß große Datenmenge anfallen können. Die verwendeten Sicherungsmedien müssen besonders alterungsbeständig sein.
Gegebenenfalls müssen auch die Programme zum Datenzugriff mit archiviert werden.
Datenreorganisation
Datenadministration umfaßt wie oben dargelegt die Definition logischer oder physischer Datenbankstruktur (Tabellendefinition, Zugriffspfad- und Clusterdefinition). Nicht alle Datenbankverwaltungssysteme können garantieren, daß diese Eigenschaften im Laufe dieses Betriebs erhalten bleiben. Vordefinierte Bereiche können überlaufen, Clustereigenschaften
verlorengehen, usw. Der DBA muß dann reorganisierend eingreifen, z.B. durch Umladen einer Tabelle oder ähnliche, hochgradig vom jeweiligen Datenbankverwaltungssystem abhängige Maßnahmen.
Datenverifikation
Die strukturelle Konsistenz der Datenbank wird normalerweise natürlich vom Datenbanksystem garantiert. Jedoch ist es in den meisten DBVS möglich, daß in bestimmten Fehlerfällen
(auch bei Fehlern in der DBVS-Software oder der verwendeten Hardware) Inkonsistenzen in
der Datenbank entstehen. Dem DBA stehen Verifikations- und Analysewerkzeuge zu Verfügung. Je nach Art und Schwere einer Inkonsistenz muß der DBA mit speziellen Werkzeugen
des DBVS oder durch Datenwiederherstellung (s.o.) den Fehler beheben.
Laufzeitkontrolle
Datenbanksysteme müssen gestartet werden (in den on-line-Zustand überführt werden), ggf.
kontrolliert beendet werden und zur Laufzeit überwacht werden (Monitoring). Fehlersituationen wie z.B. Überläufe müssen frühzeitig erkannt oder wenn möglich sogar vermieden werden. Da ein DBA heute oft mehrere Datenbanksysteme betreut, ist eine Unterstützung durch
entsprechende Werkzeuge erforderlich, die Laufzeitparameter der einzelnen Datenbanksysteme beobachten und auswerten, um die Entstehung kritischer Situationen rechtzeitig
prognostizieren zu können.
Performance-Analyse und Tuning
Der DBA ist verantwortlich für ein zufriedenstellendes Antwortzeitverhalten und einen ausreichenden Durchsatz des Datenbanksystems. Um beides zu erreichen, muß er mit den Mitteln
des DBVS ein Tuning vornehmen. Das kann durch Änderung der Datenverteilung auf die
Speichermedien geschehen oder durch Änderung von Laufzeitparametern wie Puffergrößen
u.ä.
Voraussetzung für solchen Maßnahmen ist, daß der DBA Engpäße und Überlastungen im Datenbanksystem erkennen kann. Auch die Identifikation von Zugriffsmustern und -häufigkeiten
müssen dem DBA möglich sein. Entsprechende Werkzeuge stellt das DBVS zur Verfügung.
Natürlich kann auch eine Änderung des physischen Datenbankentwurfs (s. Datenadministration) Ergebnis einer solchen Engpaßanalyse sein.
Auditing
In bestimmten Anwendungsszenarien ist es wichtig nachvollziehen zu können, wer eine bestimmte Änderung durchgeführt hat oder welche Änderungen ein bestimmter Benutzer verursacht hat. Dazu stehen dem DBA Auditing-Werkzeuge zur Verfügung.
Massendatentransfer
Nicht alle Änderungen einer Datenbank geschehen auf dem regulären Weg, d.h. durch Anwendungen, die die Datenmanipulationssprache (bspw. SQL) verwenden. In manchen Situationen müssen Massendaten geladen werden. Diese können z.B. aus dateibasierten Anwendungen oder aus anderen Datenbanksystemen stammen und somit ganz verschiedene Formate
haben. Das DBVS bietet auch für diese Aufgabe Werkzeuge an.
Zusammenfassung
Der vorliegende Beitrag untergliedert das Thema Datenbankadministration und ermöglicht so
eine Einordnung verschiedener Datenbankadministrations-Werkzeuge und -Ansätze.
Datenbankadministration besteht aus drei großen Aufgabengebieten: der Datenadministration,
der Benutzer- und Sicherheitsadministration und der Systemadministration. Datenadministration (logische Aspekte) und Benutzeradministration sind in SQL standardisiert, während die
restlichen Gebiete durch SQL nicht abgedeckt sind.
Systemadministration wurde im vorliegenden Beitrag weiter detailliert. Sie umfaßt so unterschiedliche Teilaufgaben wie Installation, Datensicherung und -wiederherstellung, Archivierung, Datenreorganisation, Laufzeitkontrolle, Tuning, Auditing und Massendatentransfer.
Wachsende Datenbankgröße, Heterogenität von Hard- und Software in heutigen Systemen
und Verteilung komplizieren fraglos die Datenbankadministration, sind jedoch zu der vorgestellten Gliederung orthogonal. Nimmt man noch die ständig wachsenden Verantwortungsbereiche der DBA hinzu, ist der Bedarf an unterstützenden Werkzeugen zur Durchführung der
Datenbankadministration offensichtlich.
Die Schnittstellen für die Aufgaben der Systemadministration sind von DBVS zu DBVS extrem verschieden - ein DBVS-übergreifendes Systemadministrationswerkzeug ist daher gerade in Umgebungen, in denen mehrere verschiedenen DBVS zu administrieren sind (oder gar
bei föderierten Datenbanksystemen), äußerst wünschenswert.
Für Administrationswerkzeuge sind allerdings noch weitere Anforderungen relevant, die zu
den vorgestellten Aspekten von Datenbankadministration orthogonal sind. So sind z.B. die
Administration einer verteilten Umgebung von einer einzelnen Stelle aus (remote administration, single point of control) wichtig.
Auf diese Aspekte von Werkzeugen gehen einige der Beiträge des Workshops ein []
Referenzen
[AKK96] A. Eickler, A. Kemper, D. Kossmann: Namensservices in verteilten Objektbanken
[BCG96] W. Benn, Y. Chen, I. Gringer: FSM: A Federated System Manager, Frühjahrstreffen der GI Fachgruppe “Datenbanken”, Darmstadt, März 1996.
[Ca96]
R. Caspary: Datenbankadministration eines SAP R/3 Systems, Frühjahrstreffen
der GI Fachgruppe “Datenbanken”, Darmstadt, März 1996.
[Di96]
S. Dirks: Umfassende Datenbankverwaltung mit DataHub für UNIX Operating
Systems, Frühjahrstreffen der GI Fachgruppe “Datenbanken”, Darmstadt, März
1996.
[Ge96]
M. Gertz, G. Koschorreck, U. Lipeck, M. Bethke, R. Grützner, A. Schlüter: ODDIS
- Ein Informationssystem für das Oracle Data Dictionary, Frühjahrstreffen der GI
Fachgruppe “Datenbanken”, Darmstadt, März 1996.
[HK96]
D. Hildebrand, H. Kinzinger: Unternehmensweites Anwendungs-Management am
Beispiel von ADABAS C, Frühjahrstreffen der GI Fachgruppe “Datenbanken”,
Darmstadt, März 1996.
[KP96]
H. Kinzinger, J. Pill: Graphische Administration von Datenbanksystemen in einem
Client/Server-Umfeld, Frühjahrstreffen der GI Fachgruppe “Datenbanken”,
Darmstadt, März 1996.
[KS96]
K. Küspert, R. Schaarschmidt: Datenbankintegriertes Archivieren: Anforderungen,
Funktionalität, ausgewählte Aspekte und Realisierungsmöglichkeiten, Frühjahrstreffen der GI Fachgruppe “Datenbanken”, Darmstadt, März 1996.
[Ra96]
E. Rahm: Automatisches, zielorientiertes Performance-Tuning von Transaktionssystemen, Frühjahrstreffen der GI Fachgruppe “Datenbanken”, Darmstadt, März
1996.
[Rö96]
W. Röder: Datenbankbasiertes Archivieren, Frühjahrstreffen der GI Fachgruppe
“Datenbanken”, Darmstadt, März 1996.
[SAG95] Software AG: ADABAS C V2.2: DBA Reference Manual, 1995.
[Scha96] G. Schaefer: DUO - ein Tool für Datenbankadministration und Systementwicklung, Frühjahrstreffen der GI Fachgruppe “Datenbanken”, Darmstadt, März
1996.
[St96]
U. Störl: Klassifikation und Bewertung von Backup- und Recovery-Strategien in
Datenbanksystemen, Frühjahrstreffen der GI Fachgruppe “Datenbanken”, Darmstadt, März 1996.