Viele kennen das Problem: Man kann zwar als Administrator auf die Datenbank zugreifen, jedoch nicht auf das Betriebssystem. Typische Beispiele sind Hosting- und Cloud-Plattform-Umgebungen wie beispielsweise die Oracle Autonomous Database.

Doch wie komme ich an weiterführende Informationen, wenn etwas nicht funktioniert? Wie komme ich an die Trace-, Alert- Dateien, etc. wenn kein Zugriff auf das Betriebssystem des Datenbank-Servers möglich ist? 

Der nachfolgende Artikel zeigt einige Möglichkeiten an Trace- bzw. Alert-Logfile-Informationen zu kommen, ohne auf das Betriebssystem zugreifen zu müssen. Grundsätzlich existieren zwei Möglichkeiten:

  • Zugriff auf Client-Tracing-Informationen 
  • Zugriff auf Server-Tracing/Alert-Informationen

1. Zugriff auf Client-Tracing-Informationen 

Client Tracing wurde in einem vorangegangenen Blog-Eintrag besprochen. Der Link zum Posting findet man unter “Was geht ab? SQL*Net Tracing, erste Schritte bei der Fehlersuche.“. Im Artikel wird beispielhaft demonstriert wie Client-Tracing für SQL*Plus aktiviert wird und die zugehörigen Trace-Files generiert werden. Dies hilft vor allem bei Verbindungs-Problemen zur Datenbank.

2. Zugriff auf Server-Tracing/Alert-Informationen

Der Zugriff auf Server Tracing Informationen ist durch die Abfrage verschiedener Data Dictionary Tabellen möglich. Folgende Voraussetzungen müssen dafür erfüllt sein:

  • Die Ziel-Datenbank muss geöffnet sein
  • Es müssen ausreichende Zugriffsrechte auf die erforderlichen V$-Views vorhanden sein. Dies ist standardmässig in Oracle Datenbanken über die SYS bzw. SYSTEM Accounts gewährleistet. In der Oracle Autonomous Datenbank erfüllt der ADMIN-Account diese Voraussetzung.

Auslesen des Alert Logs

Das Alert-Log kann mit folgenden SQL Statement ausgelesen werden:

SELECT
    originating_timestamp,
    message_text,
    module_id,
    process_id,
    filename
FROM v$diag_alert_ext
ORDER BY originating_timestamp DESC;

Bild 1: Anzeige des Alert-Logs im SQL*Developer

Die Ausgabe enthält die Alerts in einer absteigenden Reihenfolge (neustes Datum zuerst). Natürlich können je nach Anforderungen zusätzliche Spalten mit Informationen hinzugefügt werden. 
Das Statement kann in eine Datei umgeleitet werden, um eine lokale Kopie des Alert-Logs zu erzeugen. Auf die geeignete Formatierung der Spalten wird an dieser Stelle nicht eingegangen.

Auslesen von Trace-Files

Zum Auslesen der Trace-Informationen kann die View v$diag_trace_file_contents verwendet werden. Die Abfrage ist nur ein Beispiel; natürlich können andere/weitere Spalten ausgegeben werden.

SELECT
    timestamp,
    payload,
    trace_filename
FROM v$diag_trace_file_contents
ORDER BY timestamp DESC;

Bild 2: Anzeige der Trace-File-Informationen im SQL*Developer


Das Statement liest die gesamte Tabelle aus und stellt die Einträge mit abfallender Zeit/Datumsreihenfolge dar. Es werden alle vorhandenen Trace-Dateien angezeigt. Soll dies eingeschränkt werden, muss im ersten Schritt ermittelt werden, welches Trace-File verwendet werden soll. Der Name/Datum/Uhrzeit der Trace-Files lässt aus der V$-View v$diag_trace_file auslesen, wie folgendes Beispiel zeigt:

SELECT
    trace_filename,
    modify_time
FROM v$diag_trace_file
ORDER BY modify_time DESC;

Bild 3: Anzeige der Trace-File-Informationen im SQL*Developer

In dieser Auflistung erscheint das zuletzt geänderte Trace-File an der ersten Stelle.
Anschließend kann man mit dem ermittelten Trace-File-Namen das gewünschte Trace-File auslesen (in diesem Beispiel wurde ein Phantasiename als Trace-File-Name angegeben):


SELECT
    timestamp,
    payload,
    trace_filename
FROM v$diag_trace_file_contents
WHERE trace_filename = ‘DB0401_m004_10490.trc’
ORDER BY timestamp DESC;

Fazit

Wenn es darum geht mehr Einblicke in mögliche Fehlerursachen zu bekommen, stellt die Abfrage von Trace/Alert-Log-Informationen über die Datenbank ein sehr mächtiges Werkzeug dar. Im Zweifelsfall benötigt man natürlich immer noch Zugriff auf das Betriebssystem, um mögliche Fehlerursachen zu ermitteln. Die hier vorgestellten Möglichkeiten bieten jedoch ein schnelles und unkompliziertes Vorgehen, um mögliche Fehlerursachen schnell und unkompliziert zu ermitteln.