Der erste Teil dieser Reihe hat einen Überblick über die wichtigsten Neuerungen in der Oracle Version 11g gegeben. Nun befassen wir uns mit dem neuen Advisory Framework zur Fehlerdiagnose, dem Automatic Diagnostic Repository (ADR). In diesem Beitrag stellen wir die wichtigsten Bereiche dieses Tools vor.

Überblick

Mit Oracle 11g wird das Automatic Diagnostic Repository (ADR) neu eingeführt. Unter ADR ist ein zentrales, auf XML-Dateien basierendes Repository zu verstehen. Es liegt außerhalb der Datenbank und setzt sich aus diagnostischen Daten zusammen. Diese Informationen musste der Administrator bisher aus vielen einzelnen Dateien zusammentragen. Zu solchen zählten zum Beispiel das Alert.log, Core Dumps, Dumps der Hintergrundprozesse und User Trace Files.

Durch das Zusammenfassen der Diagnoseinformationen, auch von mehreren Instanzen, wird dieses in Zukunft wesentlich einfacher werden. Nun können der Administrator sowie der Oracle Support leichter auf zusammenhängende Fehlerprotokolle zugreifen.

Abb. 1: ADR Verzeichnisstruktur.

Automatic Storage Management (ASM), Cluster Ready Service und andere Oracle Produkte und Komponenten speichern ihre Diagnoseinformationen ebenfalls im ADR. Jede Instanz erhält dafür ein eigenes ADR-Homeverzeichnis. Alle Initialisierungsparameter, die mit „_DUMP_DEST“ enden, werden ab jetzt ignoriert. Durch den Parameter DIAGNOSTIC_DEST wird das ADR_BASE-Verzeichnis gesetzt. Dieses Verzeichnis ist das Wurzelverzeichnis des ADR. Unterhalb dieses Wurzelverzeichnisses erhält jede Instanz ein eigenes ADR-Homeverzeichnis, in dem sich dann die Verzeichnisse für Alert.log, Incident Reports, Problems usw. befinden (siehe Abbildung 1).

Das Alert.log

Jeder, der zum ersten mal mit Oracle 11g zu tun hat, stolpert zwangsläufig über die Frage: „Wo ist das Alert.log?“ Bisher konnten wir das Alert.log in dem durch den Initialisierungsparameter BACKGROUND_DUMP_DEST festgelegten Verzeichnis finden. Dort suchen wir nun allerdings vergeblich.

In Oracle 11g werden nun zwei Versionen des Alert.logs gepflegt. Zum einen existiert auch weiterhin eine in ASCI geschriebene Version. Zum anderen wird das Alert.log nun auch in der XML-Version geschrieben.

Im Verzeichnis $ADR_HOME/alert finden wir nun die XML-Version des Alert.log, im Verzeichnis $ADR_HOME/trace wird es in der alten Version abgelegt. Das Alert.log in der XMLVersion kann nun bequem über den Enterprise Manager gelesen werden.

Zudem gibt es die Möglichkeit, das Alert.log über den Command Interpreter des ADR (ADRCI) zu betrachten. Außerdem kann man das Alert.log auch in der alten Version wie gewohnt mit einem Texteditor der eigenen Wahl lesen.

Die View V$DIAG_INFO

Mit der View V$DIAG_INFO lassen sich in der Datenbank die Pfade zu den einzelnen Dateien abfragen (siehe Abbildung 2).

SQL> select name, value from v$diag_info;


NAME VALUE
------------------------------------------------------------------------------------
Diag Enabled TRUE
ADR Base /oracle/11G
ADR Home /oracle/11G/diag/rdbms/ora11g/ora11g
Diag Trace /oracle/11G/diag/rdbms/ora11g/ora11g/trace
Diag Alert /oracle/11G/diag/rdbms/ora11g/ora11g/alert
Diag Incident /oracle/11G/diag/rdbms/ora11g/ora11g/incident
Diag Cdump /tmp
Health Monitor /oracle/11G/diag/rdbms/ora11g/ora11g/hm
Default Trace File /oracle/11G/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_3317.trc
Active Problem Count 0

• ADR_BASE: Pfad zum ADR-Wurzelverzeichnis
• ADR_HOME: Pfad zum Homeverzeichnis der aktuellen Instanz
• DIAG_Trace: Pfad zum textbasierten Alert.log File und den Trace-Dateien (foreground/background)
• Diag Alert: Pfad zum XML Alert.log File
• Default Trace File: Pfad zum trace File der aktuellen Session

ADRCI

Über das neue Kommandozeilenwerkzeug ADRCI werden die Diagnosedaten ausgelesen. Mit diesem sehr mächtigen Tool lassen sich außerdem viele diagnostische Aufgaben erledigen. Es können Diagnoseinformationen gelesen, ausgewertet oder zu einem Paket zusammengeschnürt werden. Diese Pakete können dann leicht an den Oracle Support weitergeleitet werden. Das ADRCI kann interaktiv aber auch in Skripten verwendet werden. Wie mächtig das Tool ist, möchten wir mit dem folgenden Beispiel verdeutlichen.

Auswertung des Alert.logs im ADRCI

Mit dem Tool ADRCI kann das Alert.log gelesen und geprüft werden. Vor dem Aufruf des ADRCI sollte geprüft werden, ob die Umgebungsvariablen richtig gesetzt sind.

Mit HELP sehen Sie zunächst alle möglichen Befehle. Mit SHOW HOMES können alle ADR-Homeverzeichnisse angezeigt werden. Mit SET HOMEPATH <PATH> kann das aktuelle ADR-Homeverzeichnis gesetzt werden. Mit SHOW ALERT wird das Alert.log angezeigt. Um die Anzeige auf die letzten Einträge zu beschränken, kann man mit der Option -tail arbeiten. Diese verhält sich genauso wie auch das tail unter Unix.

Mit dem Schalter -f kann das „following“ eingeschaltet werden und das Alert.log live mitverfolgt werden. Mit dem Kommando SHOW ALERT -P MESSAGE_TEXT LIKE '%ORA-%' kann mit Hilfe des ADRCI nach bestimmten Begriffen gefiltert werden. In diesem Beispiel werden alle Einträge ausgegeben, die „ORA-“ beinhalten, also Fehlermeldungen. Die Ausgabe kann dann per Spool in eine Datei geschrieben werden (siehe Abbildung 3).

adrci> show alert -tail
Completed: ALTER DATABASE OPEN
2007-10-27 21:32:54.417000 +02:00
Starting background process CJQ0
CJQ0 started with pid=29, OS id=3301
2007-10-27 21:32:59.125000 +02:00
Setting Resource Manager plan SCHEDULER[0x2C0E]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
2007-10-27 21:33:41.629000 +02:00
Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
Sat Oct 27 21:33:42 2007
Logminer Bld: Lockdown Complete. DB_TXN_SCN is UnwindToSCN (LockdownSCN) is 951511
2007-10-27 21:34:14.682000 +02:00
End automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"

adrci> show alert -P "message_text like '%ORA-%'"

ADR Home = /oracle/11G/diag/rdbms/ora11g/ora11g:
*************************************************************************
Output the results to file: /tmp/alert_3474_30564_ora11g_1.ado
adrci>

Problems und Incidents

Durch den ADR werden zwei neue Konzepte eingeführt: Problems und Incidents.

Problem

Als Problem wird ein kritischer Fehler in einer Datenbankinstanz bezeichnet. Jedes Problem bekommt einen Problem Key, der das Problem beschreibt. Dieser beinhaltet den Fehlercode und manchmal einen oder mehrere Fehlerparameter. Mögliche Fehler in Oracle zeigt Abbildung 4.

Incident

Ein Incident ist das einmalige Auftreten eines Problems. Jeder Incident bekommt eine eindeutige, numerische Incident-ID. Sobald ein Incident auftritt, passiert Folgendes:

Die Datenbank

• schreibt einen Eintrag ins Alert.log
• sendet einen alert an den Enterprise Manager
• sammelt Diagnoseinformationen in Form eines Dumps
• hängt dem Incident eine Dump-ID an
• speichert den Incident in einem extra dafür angelegten Verzeichnis unterhalb des ADR

Im ADR werden somit automatisch Incidents geschrieben. Wie lange ein Incident gespeichert werden soll, kann durch das Setzen einer Retention Policy im ADRCI konfiguriert werden. Hierfür gibt es zwei Parameter, die getrennt voneinander gesetzt werden können:

• Die Metadata Retention Policy gibt an, wie lange Metadaten gespeichert werden. Diese wird per Default auf ein Jahr gesetzt.
• Die Files und Dumps Retention Policy gibt an, wie lange generierte Dump Files gespeichert werden. Hier ist der Default-Wert ein Monat.

Incident Stati

Der Status eines Incidents gibt seinen Zustand wieder. Ein Incident kann in einem der folgenden Stati sein:

• Collecting: Der Incident wurde soeben erzeugt und sammelt noch die Diagnoseinformationen. In diesem Zustand ist der Incident unvollständig und sollte nicht gepackt werden.
• Ready: Das Sammeln der Diagnoseinformationen ist abgeschlossen und kann nun genutzt werden, um das Problem zu analysieren oder um ein Paket für den Oracle Support zu schnüren.
• Tracking: Dieser Status zeigt an, dass ein Datenbankadministrator an diesem Problem arbeitet. Dieser Status muss manuell gesetzt werden.
• Closed: Dieser Incident gilt als erledigt und kann vom ADR zum Löschen ausgewählt werden, sobald die Retention Policy greift.
• Data Purged: Die betroffenen Dateien wurden vom Incident gelöscht. In den meisten Fällen können die Dateien auch nicht mehr genutzt werden, selbst wenn sie sich noch im File-System befinden.

Der Status eines Incident kann direkt mit dem ADRCI geprüft werden: ADRCI>show incident -mode detail

Incident Packaging Service (IPS)

Mit IPS können Diagnoseinformationen sehr einfach und automatisch zu einem ZIP-File zusammengeschnürt werden. Dieses Paket kann dann an den Oracle Support übertragen werden.

Da die Diagnoseinformationen, die zu einem kritischen Fehler gehören, mit einer ID getracked werden, müssen die Daten nicht mühsam von Hand zusammengesucht werden. Der IPS identifiziert anhand der ID die entsprechenden Informationen selbstständig und fügt diese zu einem Paket zusammen.

Fazit

Mit ADR hat Oracle ein sehr sinnvolles Werkzeug zur Fehlersuche und -diagnose eingeführt. Viele Aufgaben, die bisher mühsam von Hand gelöst werden mussten, können nun mit geringem Aufwand ausgeführt werden.

Selbst der Einsatz in vollautomatischen Skripten kann die Arbeit der Datenbankadministratoren wesentlich vereinfachen.

Frank Späth (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen