Oracle 12c - Das umfassende Handbuch

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 Maß an 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