Auslesen von Alert.log und zugehörigen Trace-Dateien mittels SQL in Oracle-Datenbanken
Mein Kollege Marco hat vor Kurzem den Blogeintrag "Wo ist mein Tracefile?" veröffentlicht. In diesem ist beschrieben, wie man eine Session tracen und für diese herausfinden kann, wie ein Tracefile heisst, wo es liegt und wie man über das Betriebssystem und die Datenbank per SQL an die Details im Tracefile kommt. Dieser Post hier ist eine Ergänzung/Erweiterung, um Daten aus dem Alert.log bzw. aus Tracefiles, die nicht durch ein selbst eingeschaltetes Tracing geschrieben wurden, auslesen zu können. Mit beiden Blogeinträgen zusammen sollten Sie die wichtigsten Informationen und Dateien ohne Zugang zum Betriebssystem eines Datenbankservers erhalten können.
Es gibt viele Gründe, warum Oracle auch ohne explizites Tracing in das alert.log oder in Trace-Dateien schreibt. Am interessantesten für Datenbankadministratoren sind natürlich Fehler, die in das alert.log geschrieben werden und die Details, die in den zugehörigen Trace-Dateien zu finden sind. Aber auch für Entwickler können Traces von Interesse sein, weil etwas passiert, das an die Anwendung gebunden ist bzw. von dieser ausgelöst wird, z.B. Deadlocks oder Oracle interne Fehler (wie ORA-00600 oder ORA-07445, um zwei exemplarisch zu nennen). Mit den Daten aus den Traces kann dann im Oracle Support nach dem Problem und einer Lösung oder eines Workarounds gesucht werden. Typischerweise (und historisch gewachsen) gräbt sich der Administrator der Datenbank durch die verschiedensten Log- und Trace-Dateien im diag-Ordner und versucht, die notwendigen Informationen zu extrahieren.
Manchmal wird behauptet, dass sogar ein Betriebssystem-Zugang benötigt wird, um überhaupt an die Daten in den Dateien zu kommen. Aber ist das wirklich notwendig? Wird Zugriff auf das Dateisystem außerhalb der Datenbank benötigt, um alert.log-Einträge oder den Inhalt der Trace-Dateien zu erhalten?
Die Antwort ist natürlich klar: Nein, braucht es nicht. Zumindest in ganz vielen Fällen nicht. Es ist gerade aus dem Alert.log und den Trace-Dateien möglich, per SQL alle Daten zu erhalten, die benötigt werden. Dies geht so weit, dass über SQL abgespeicherte (gespoolte) Abfragen aus Trace-Dateien als Input für lokale tkprof-Auswertungen benutzt werden können.
Wie kann auf das Alert.log per SQL zugegriffen werden?
Es ist sehr einfach, von der Datenbank aus auf das alert.log zuzugreifen. Die von Oracle bereitgestellte View, die dazu dient, Daten aus dem alert.log zu erhalten, heisst v$diag_alert_ext.
Es existieren verschiedene Möglichkeiten, die ausgegebenen Inhalte der v$diag_alert_ext View einzuschränken.
Grundsätzlich stehen alle Einträge im alert.log für alle Container dann zur Verfügung, wenn mit einer SQL(Developer)-Sitzung eine Verbindung, z.B. als "System" Benutzer zum Root Container der Datenbank hergestellt wird.
Durch die Verbindung direkt zu einer pluggable Database (PDB) werden lediglich die alert.log-Einträge, die dieser PDB zugeordnet sind, zurückgegeben.
Normalerweise beinhalten die V$-Views nur Informationen, die flüchtig sind, also z.B. aktuelle Statistiken vom letzten Start der Instanz bis zu „SYSDATE“, aber die V$DIAG_ALERT_EXT zeigt auch die Einträge – wie in der Textdatei – vor dem letzten Start. Die Werte werden übrigens aus der XML-Datei des alert.logs entnommen. Wenn also Bereinigungswerte (Retention Policies) für das ADR (Automatic Diagnostic Repository) eingestellt wurden, beeinflusst dies die auswählbaren Log-Einträge.
Aus welchem Log gerade gelesen wird, kann ebenfalls aus v$diag_alert_ext selektiert werden.
Beispiele für Alert.log Einträge aus der V$DIAG_ALERT_EXT View
- Selektieren von Fehlerdaten in Bezug auf eine Pluggable Database (hier am Beispiel einer Testdatenbank).
select container_name, originating_timestamp, user_id, message_text, message_arguments, record_id from v$diag_alert_ext order by record_id;Dieser Ausschnitt aus dem Alert.log stammt von Backup- und Restore-Tests mit Common Usern. Sofort erkennbar ist der ORA-01157 Fehlereintrag mit dem fehlenden Datafile.
- Ebenfalls erkennbar ist die Wiederherstellung des Datafiles mittels eines Restores und die Online-Setzung des Datafiles.
- Hier ein Beispiel für die Änderung des Job_Queue_Processes Parameter.
- Wird der Container nicht im Where Clause eingeschränkt, werden bei der Verbindung zum Root Container Datensätze für ALLE Container zurück gegeben. Deshalb sollte immer der Container_Name mitselektiert werden (auch dann, wenn die Meinung vorherrscht, man sei zur PDB direkt verbunden). Ansonsten kann es passieren, dass z.B. ein Setzen eines spfile-Parameters mit alter system gar nicht in dem Container stattgefunden hat, in dem man es vermutet. Zu sehen sind im nachfolgenden Screenshot sowohl spfile-Änderungen im Root Container als auch in der PDB.
Zugriff auf Trace-Dateien
Für die Aktivierung von Traces in Sessions gibt es mehr als genug Beispiele und Blogeinträge, aber was ist, wenn z.B. ein Deadlock aus einem Job ausgelöst wird. Und das auch nicht bei jedem Durchgang, sondern nur ab und an? Ein selbst initiertes Session Tracing wird da nicht stattfinden, aber glücklicherweise sind Deadlocks im Alert.log eingetragen – und damit findet man auch das dazugehörige Tracefile.
Der Benutzer berichtet also über einen aufgetretenen Deadlock – hier einmal im SQL nachgestellt.
Und im Alert.log wird der Deadlock eingetragen – mit einem Verweis auf die Details im Tracefile.
Über die Spalte "Payload" und den Tracefile-Namen ohne Pfad im where-clause bekommt man nun den Inhalt des Tracefiles zurück.
Scrollt man im SQL dann etwas nach unten, sieht man auch die beiden Statements, die den Deadlock ausgelöst haben. Es ist natürlich auch möglich, das Tracefile zu spoolen und dieses z.B. an die Entwicklung oder den Softwarehersteller weiterzugeben.
Kommentare
Keine Kommentare