6.4
Diagnostik
135
Die gesteigerte Effizienz bei der Administration ist verbunden mit einer Kosten-
einsparung. Häufig wird der Preis pro Datenbank berechnet, in den die Kosten für
die Administration eingehen. Die Erfahrung hat gezeigt, dass sich eine effiziente
Administration vor Ort in den Kosten nicht wesentlich von Off Shore- oder Near
Shore-Lösungen unterscheidet bei gleichzeitig höherer Kundenzufriedenheit.
Schon mit der Verwendung von Namenskonventionen und mit einem einheitli-
chen Dateilayout kann ein gutes Niveau erreicht werden. Standards sollten schrift-
lich festgehalten und im Team kommuniziert werden. Zur Qualitätssicherung
kann ein Skript erstellt werden, das überprüft, ob alle Standards für eine Daten-
bank eingehalten wurden.
Wenn zusätzlich Aliase für Datenbankserver und IP-Adressen verwendet werden,
dann wird zum Beispiel das Umziehen auf eine andere Hardware erleichtert.
Auch das Desaster Recovery wird einfacher, und der Einfluss auf die Clients und
Applikationen wird auf ein Minimum reduziert.
6.4 Diagnostik
Die Diagnostik von Problemen ist in einer immer komplexer werdenden IT-Infra-
struktur keineswegs eine triviale Aufgabe. So landen beispielsweise Probleme auf
dem Schreibtisch des Datenbankadministrators, die weit außerhalb der Daten-
bank liegen. Häufig gelingt es nicht, die Problemursache einzugrenzen und der
zuständigen Gruppe zuzuweisen.
Aber auch die Oracle-Datenbank selbst hat mit der Version 12c eine Komplexitäts-
stufe erreicht, die eine Problemdiagnose nicht nur zur zeitaufwendigen Aktion
macht, sondern auch ein gehöriges Man Wissen und Erfahrung voraussetzt,
um dem Problem zeitnah auf den Grund gehen zu können. Die Palette der Prob-
leme reicht von Performance-Problemen über Applikationsfehler bis zu Ausfällen
einzelner Komponenten und Features oder der gesamten Datenbank.
Um der Problematik bei wachsender Komplexität der Software Rechnung zu tra-
gen, hat Oracle in der Version 11g das Feature Advanced Fault Diagnostic Infrastruc-
ture eingeführt. Es verfolgt das Ziel, insbesondere bei kritischen Fehlern wie zum
Beispiel Bugs oder Korruption von Daten, eine schnelle und umfassende Diagnos-
tik herbeizuführen.
Wenn ein kritischer Fehler auftritt, dann wird ihm eine Incident-Nummer zugewie-
sen, und es werden automatisch Diagnostikdaten gesammelt und mit der Nummer
verbunden. Anschließend werden die Daten im Automatic Diagnostic Repository
(ADR) gespeichert. Das ADR basiert auf Dateien im Betriebssystem außerhalb der
Datenbank. Der Zugriff auf das ADR erfolgt über die Incident-Nummer. Dabei wer-
den die Ziele verfolgt, eine Anfangsdiagnose zu erstellen, den Aufwand für Diag-
Kapitel 6
Aufbau einer Datenbankinfrastruktur
136
nose und Problemlösung zu verringern und die Kommunikation mit Oracle
Support zu verbessern. Dabei werden die folgenden Technologien eingesetzt:
Automatisches Erstellen von Diagnosedaten beim erstmaligen Auftreten des
Fehlers
Incident Packaging Service (IPS)
Data Recovery Advisor
SQL Test Case Builder
Mit dem sofortigen Erstellen von Tracefiles und anderen Diagnosedaten beim Auf-
treten eines schwerwiegenden Fehlers werden die erforderlichen Informationen
für die Diagnose zur Verfügung gestellt. Damit steigen die Chancen, die Proble-
mursache schnell zu finden und die erforderlichen Maßnahmen zeitnah einleiten
zu können.
Der Incident Packaging Service ermöglicht es, die zu einem Incident gesammelten
Daten einfach zu einem Paket zu schnüren und dem Oracle Support zur Verfü-
gung zu stellen. Das bisher gewohnte, zeitaufwendige Erstellen und Sammeln von
Tracefiles sowie das Erstellen eines RDA kann für die überwiegende Mehrheit der
Incidents entfallen.
Der Data Recovery Advisor verwendet Health Checks, um Datenkorruptionen zu
erkennen. Er beschreibt die möglichen Auswirkungen der Fehler und erstellt
Empfehlungen für die Problembeseitigung.
Der SQL Test Case Builder unterstützt den Administrator, die Nachvollziehbarkeit
von SQL-Problemen herzustellen.
6.4.1 Die Komponenten der Fault Diagnostic Infrastructure
Die Fault Diagnostic Infrastructure besteht aus den folgenden Komponenten:
Das Automatic Diagnostic Repository (ADR)
Das Alert Log und Tracefiles
Die Enterprise Manager Support Workbench
Das Kommandozeilen-Utility ADRCI
Hinweis
Oracle versucht, die Begriffe Incident und Problem gemäß der aus ITIL bekann-
ten Definition zu verwenden. Dies ist, insbesondere in der Dokumentation,
nicht durchgängig gelungen. In der Regel ist aber auch hier ein Incident als das
konkrete Auftreten eines Problems zu verstehen.
6.4
Diagnostik
137
Das ADR wird außerhalb der Datenbank in einer Verzeichnisstruktur des Betriebs-
systems gespeichert. Der Init-Parameter DIAGNOSTIC_DEST spezifiziert das
Hauptverzeichnis für die Diagnose-Dateien, die sich in den Verzeichnissen
USER_DUMP_DEST, CORE_DUMP_DEST und BACKGROUND_DUMP_DEST
befinden.
Das ist auch der Grund, weshalb Sie das Alert Log und die Trace-Dateien nicht
mehr an den gewohnten Stellen finden. Der Parameter DIAGNOSTIC_DEST wird
standardmäßig auf $ORACLE_BASE gesetzt. Falls $ORACLE_BASE nicht gesetzt
ist, dann wird er auf $ORACLE_HOME gelegt.
Abb. 6.4: Die Verzeichnisstruktur des ADR
SQL> SHOW PARAMETER diagnostic_dest
NAME TYPE VALUE
----------------------------------- ----------- ------------------------------
diagnostic_dest string /opt/oracle

Get Oracle 12c - Das umfassende Handbuch now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.