Oracle Core für Einsteiger: Das Alert Log

Transkript

1 DOAG Konferenz 2015 Martin Klier, managing partner database technology at Performing Databases. NOVEMBER 2015 Oracle Core für Einsteiger: Das Alert Log Einleitung Die wesentliche Aufgabe eines Oracle Datenbankadministrators oder -operators ist es, in Frieden und Störfall gleichermaßen den Überblick in seinen Datenbankinstanzen zu gewinnen und zu behalten. Eine solche Datenbankinstanz besteht aus einer zunächst unübersichtlichen Vielzahl von Speicherbereichen und Prozessen. Bei einer durchschnittlichen 12cR1 Multitenant-Instanz ist so beispielsweise von mindestens 60 Hintergrundprozessen 1 auszugehen. Dazu kommen noch die Server- (Vordergrund-) Prozesse, die für das Bedienen von User-Sessions notwendig sind. Diese Vielzahl von aktiven Komponenten braucht ein klares Konzept, wie Fehlermeldungen den Operator erreichen, und wie man zwischen der bloßen Signalisierung eines Vorfalls und dessen Details abgrenzt. Oracle hat sich an der Stelle für eine Teilung entschieden: Die Datenbank-Komponenten (=Hintergrund- und Vordergrundprozesse) loggen Ihre Fehler und Nachrichten in eine fortlaufende Protokolldatei mit dem Namen Alert Log, das für jede Instanz einzeln geführt wird. Demzufolge gibt es für jede Instanz auf einem Host ein eigenes Alert Log, und auf jedem RAC-Knoten ebenfalls. Weiterführende Informationen zu entsprechend kritischen Störungen finden sich in mehreren Kategorien von referenzierten Trace- und Dump Files. Die Oracle Dokumentation 2 definiert dieses Alert Log folgendermaßen: Eine Datei, die ein chronologisches Protokoll von Nachrichten und Fehlern der Datenbankinstanz enthält. 1 SQL> select * from v$process 2 Performing Databases GmbH! 1/!

2 Architektur Als Grundlage des Folgenden sei hier die Architektur des Oracle RDBMS grob zusammengefasst. Als Überblick dient eine Graphik aus der Oracle Online-Dokumentation 3. Die Zusammenhänge sind stark vereinfacht, sollten aber einen Einblick in die grundlegende Funktionsweise geben. Lesen Beim klassischen Lesevorgang parst der Serverprozess (=Session) unter Rückgriff auf die SQL-Optimizer-Bibliotheken ein Statement (z.b. SELECT), und legt dafür einen Cursor im Library Cache des Shared Pool ab. Bei der Ausführung holt derselbe Prozess die notwendigen Blöcke vom Tablespace, legt diese im Buffer Cache ab, und extrahiert die für die Abfrage relevanten Teile. Ist eine Aufbereitung oder ein aufwändigerer Join notwendig, verwendet der Serverprozess seine PGA, um zu sortieren, Hash Tables abzugleichen oder Merges auszuführen. Schreiben / Verändern Der Schreibvorgang gleicht im Prinzip dem Lesevorgang - oft genug beinhaltet er einen solchen. Nach dem Parsen (z.b. eines UPDATE) werden die Daten jedoch darüber hinaus im Buffer Cache verändert. Zur Absicherung des Cache gegen Verlust schreibt der Serverprozess die von ihm getätigten Veränderungen pro Block über seinen Private Strand im Shared Pool auch noch in den Redo Log Buffer, und der Hintergrundprozess Log Writer (LGWR) diese spätestens beim Commit in die Online Redo Log Files. Aus diesen Redo-Daten und dem Original-Block aus dem Tablespace wird im Fall eines Absturzes der Zustand des Buffer Cache rekonstruiert (Instance Recovery). Vollständige Online Redo Logs sichert der Archiver (ARCn) in sogenannte Archived Redo Logs. Diese bilden eine spezielle Form eines eingebauten inkrementellen Backups: Aufbauend auf einer Vollsicherung z.b. mit dem Recovery Manager (RMAN) lassen sich die kurz Archivelogs genannten Bausteine für einen Roll-Forward einsetzen: Nach der Rücksicherung bewegt sich der Stand der Datenbank durch die Vergangenheit in Richtung Gegenwart, bis zum Vollständigen Recovery oder, falls gewünscht zu einem genau spezifizierten Punkt in der Zeit ( Point in Time Recovery ) vor der Störung. Der Database Writer (DBWn), der im Zusammenwirken mit dem Checkpoint-Prozess (CKPT) konsistente Abbilder der Buffer aus dem Cache auf den Tablespace synchronisiert, läuft unabhängig von aktuellen User-Operationen als Lazy Writer. Damit wird sichergestellt, dass mittelfristig geschriebene Einträge im Online Redo Log unnötig werden, und überschrieben werden dürfen. Im Rahmen der Veränderung von Datenzeilen durch den Serverprozess entstehen Undo-Daten, die in Form sogenannter Undo-Segmente dem gleichnamigen Tablespace zugeordnet sind. Sie dienen für die Fähigkeit, Transaktionen rückgängig zu machen ( Rollback ) und zur Umsetzung des Transaktionskonzeptes allgemein, z.b. für die Consistent Read Isolation des Oracle RDBMS. 3 Performing Databases GmbH! 2/!

3 Darreichungsformen Oracle präsentiert uns das Alert Log in verschiedenen Formen. Je nach dem welchem Zweck unser Zugriff dient, und mit welchen Mitteln er ausgeführt wird, bieten sich die unterschiedlichen Formate an. Textdatei Sicher die älteste, bekannteste und zumeist verwendete Form des Alert Log ist die Textdatei. Sie hat ihren genormten Speicherort im ADR 4, dessen Betriebssystem-Pfad der Datenbank durch den Parameter diagnostic_dest bekanntgemacht wird. Üblicherweise 5 setzt sich der Pfad wie folgt zusammen: <diagnostic_dest>/diag/rdbms/<db_name_in_kleinbuchstaben>/<instanzname>/trace/alert_<$oracle_sid>.log Zum Beispiel auf dem Referenzssystem: /u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log Am häufigsten wird der DBA diese klassische Form verwenden, wenn er einfach ein fortlaufendes Log der Datenbank anzeigen möchte (z.b. mit Unix tail ) oder dem (Oracle) Support einen Überblick über die Gesamtsituation und jüngere Historie geben möchte. Nachteilig wirkt sich bei dieser Lektüre die entweder unübersichtliche Größe oder die referenzlose Teilung durch manuelle Rotationsmechanismen aus. 4 Automatic Diagnostic Repository ( 5 nach Oracle Flexible Architecture, kurz OFA Performing Databases GmbH! 3/!

4 XML-Datei Die modernste Form zur Darstellung der anfallenden Information ist das XML-Format. Oracle stellt entsprechend auch sein Alert Log in der Gestalt zur Verfügung. Ein Beispiel ist beigefügt. Der entsprechende Dateipfad im ADR lautet: <diagnostic_dest>/diag/rdbms/<db_name_in_kleinbuchstaben>/<instanzname>/alert/log.xml oder konkret z.b.: /u01/app/oracle/diag/rdbms/orcl/orcl/alert/log.xml Diese Datei bietet sich für eine Analyse durch das menschliche Auge nicht an, ist aber prädestiniert für die maschinelle Auswertung. Nicht zuletzt Oracle selbst nutzt das Format, um ein virtuelles Datenbankobjekt zur Verfügung zu stellen (siehe nächster Absatz) oder eigene Tools damit zu speisen (z.b. ADRCI). Datenbankobjekt - Fixed Table Die Datenbank-Engine stellt uns mit der Tabelle x$dbgalertext einen Zugriff per SQL auf die Daten des Alert Log bereit 6. Die nebenstehenden Graphiken zeigen ein Beispiel dafür. Dieser Weg eignet sich vorrangig für Recherchearbeiten oder Monitoringzwecke im laufenden Betrieb. Für die Suche nach der Ursache eines Fehlstartes der Instanz beispielsweise ist er denkbar ungeeignet. Ein Hinweis ist sicher angebracht: Der Zugriff auf x$dbgalertext ist nicht dokumentiert oder durch Oracle empfohlen, so dass sich die Struktur und der Inhalt der Tabelle bei Veränderungen der Version ohne Mitteilung ändern können. Der ebenfalls nicht dokumentierte Weg über den View V$DIAG_ALERT_EXT ist aus Gründen der entstehenden Last und der ggf. trägen Antwortzeiten oft nahezu unbenutzbar. 6 Performing Databases GmbH! 4/!

5 Purging Für Trace- und immer wieder beschnittene XML-Dateien des ADR sorgt Oracle selbständig alle sieben Tage für das Housekeeping nach zuvor definierten Aufbewahrungsregeln 7 (SHORTP_POLICY und LONGP_POLICY in ADRCI). Diese greifen jedoch nur für Dateien die nicht mehr berührt wurden - ein fortlaufend geschriebenes Logfile wird daher unbegrenzt weiter wachsen. Deshalb muss sich der verantwortungsbewusste DBA in Eigenverantwortung um die Archivierung bzw. Aufräumung kümmern. Ein Hilfsmittel dazu ist z.b. unter Linux das Tool logrotate. Das Textfile-Alert Log wird zum Anfügen / Schreiben geöffnet, und jedes Mal wieder geschlossen 8. Damit ist es jederzeit möglich, das File zu verschieben, umzubenennen oder zu komprimieren ohne dass offene File Handles übrig bleiben, oder eine Sperre den Vorgang längere Zeit aufhält. Speicherorte von weiteren Diagnoseinformationen Oracle bietet als Hilfe zur Selbsthilfe mit V$DIAG_INFO einen View, der unter Berücksichtigung der konkreten Datenbank-Konfiguration anzeigt, welche Diagnoseinformationen in welchem Pfad liegen. (Graphik aus der Oracle Dokumentation 12c) leicht nachzuprüfen mit den Unix-Kommandos lsof oder fuser Performing Databases GmbH! 5/!

6 Inhalt Inhaltlich interessant wird das Alert Log natürlich vor allem bei Fehlern - aber auch für das Monitoring oder rückwirkende Recherchen ist es von Nutzen. Im Folgenden ist anhand mehrerer Beispiele dargestellt, welche Informationen sich ablesen lassen. Die Dokumentation sagt zum Inhalt des Alert Log, es schließe unter anderem ein: Alle internen Fehler (ORA-600), block corruptions (ORA-1578), und Deadlocks (ORA-60) Administrative Operationen wie die SQL*Plus Kommandos STARTUP, SHUTDOWN, ARCHIVE LOG, und RECOVER Diverse Meldungen und Fehler in Bezug auf die Funktionen der Shared-Server- und Dispatcher-Infrastruktur Fehler aus dem automatischen Refresh von Materialized Views u.v.m. Einen guten Eindruck vermitteln auch die MESSAGE_GROUPs in x$dbgalertext (siehe auch oben). Diese beinhalten startup, shutdown, background_proc, process start, process end, schema_ddl, admin_ddl, sqltune, Access Violation usw. Beispiel 1 - Startup Beim Start der Instanz protokolliert Oracle diverse Informationen - zunächst zur Systemumgebung, später zur eigenen Konfiguration. Am Ende gibt es Auskunft über den Verlauf des Starts, u.a. mit einer Meldung für jeden gestarteten Hintergrundprozess. Auch für solche wie den CJQ (Scheduler), der erst deutlich verzögert in Erscheinung tritt, sobald die Instanz einige Zeit stabil lief. Performing Databases GmbH! 6/!

7 Nicht fehlen dürfen oben auch Hinweise wie die Realtime-Priorität von VKTM, dem Prozess für die Zeitbasis. Nachdem die für NOMOUNT notwendigen Prozesse laufen, folgt der MOUNT-Status, d.h. die Anbindung des Control File. Auffällig hier sind die Zugriffe (=mounts) der Automatic Storage Management (ASM) Diskgroups, auf welchen die aktuell nachgefragten Dateien liegen. Wurde die Datenbank nicht ordnungsgemäß beendet, muss die Instanz beim Wechseln in den OPEN-Status zunächst ein Crash Recovery durchführen: Performing Databases GmbH! 7/!

8 Ist das Recovery abgeschlossen, wird die Datenbank für den Regelbetrieb fertiggestellt. Dazu nimmt die Instanz das Redo-System in Betrieb, ebenso gehört die Rückführung der durch den Crash nicht abgeschlossenen Transaktionen durch SMON dazu. Auch hier sieht man immer wieder, wie der Beginn einer Serie von Zugriffen auf ASM Diskgroups mit mounting signalisiert wird. Ganz am Ende, bevor die Datenbank geöffnet wird, startet bei diesem System ein vom DBA definierter STARTUP TRIGGER alle Pluggable Databases die vorhanden sind. Performing Databases GmbH! 8/!

9 Nun folgt der Echtbetrieb im OPEN-Status. Das RDBMS meldet kurz den Status der Fast Recovery Area (FRA), und widmet sich seinen Usern. Das gezeigte System erweitert hier einige Systemtabellen um weitere Intervall-Partitionen, und am Beispiel eines Backups sehen wir wie im Alert Log Veränderungen an Oracle Managed Files (OMF) vorgenommen werden. Hier sind es Backupfiles, aber prinzipiell würde ein Eintrag bezüglich eines hinzugefügten oder entfernten Datafiles eines Tablespace nicht anders aussehen. Nach einem weiteren Log Switch sehen wir noch ganz unten Einträge zu inkrementellen Checkpoints, die auf die besondere Parametrierung dieses Systems zurückgehen, die ich nur wärmstens empfehlen kann: log_checkpoints_to_alert=true gibt für jeden konsistenten Checkpoint nicht nur dessen Uhrzeit, sondern auch die System Change Number (SCN) und die aktuelle Cursorposition im Online Redo Log zurück. Diese Information kann für ein Point-in-Time-Recovery eines Tages entscheidend sein. Performing Databases GmbH! 9/!

10 Beispiel 2 - Shutdown Beim regulären Shutdown stoppt die Instanz nach und nach ihre Prozesse und entlädt sich damit aus dem Speicher. Performing Databases GmbH! 10/!

11 Beispiel 3 - Fehler Am Beispiel eines Deadlock lässt sich gut erläutern, wie die einschneidende Maßnahme zur Bereinigung einer Situation zwar im Alert Log protokolliert wird jedoch die umfangreichen weiterführenden Informationen in einem Trace File besser aufgehoben sind, und dort mit jedem Texteditor analysiert werden können. Im Falle des ORA-0060 besteht diese Information aus Hinweisen zu den beteiligten Transaktionen, wie Row-IDs und Session-Details. Performing Databases GmbH! 11/!

12 Praxistip Auf Umgebungen die ohne klassische Unix-Tools auskommen müssen, liefert das Kommandozeilen-Tool des ADR mit dem schönen Namen ADRCI eine Möglichkeit, das Alert Log fortlaufend zu betrachten, ganz so wie das tail im Unix- Umfeld anbietet. Das folgende Beispiel zeigt die richtige Anwendung von show alert -tail 10 -f ( zeige die letzten 10 Zeilen des Alert Log und dann fortlaufend jede Zeile, die neu dazu kommt. Was fehlt? Eine ganze Reihe operativer Informationen kann der DBA aus dem Alert Log ablesen. Allerdings finden sich etliche für den Betrieb relevante Informationen NICHT in diesem File. Die folgende Liste ist keinesfalls vollständig, sondern soll einen Eindruck über anderswo verfügbare, teils reichhaltige Diagnosedaten vermitteln. In Klammern sind mögliche Quellen für derartige Daten angegeben. Blockierungen, die keine Deadlock sind (v$lock) Angemeldete User, Historie von SQL Statements (v$session, Audit Trail) Gründe für Erreichen der Prozesslimits (v$session, v$process) Clientseitige Verbindungsfehler (Logs auf dem Client) Probleme beim Verbindungsaufbau (Listener-Logfile im ADR) Performance-Vorfälle (Oracle Wait Interface, AWR, Statspack) Start, Verbleib und Stop von Scheduler-Jobs (dba_scheduler-views) Vorfälle der Oracle Clusterware im RAC (crsd.log, ocssd.log, evmd.log, Alert Log der Clusterware) ASM-Vorfälle (eigenes Alert Log) Performing Databases GmbH! 12/!

13 Zusammenfassung Das Alert Log ist ein unverzichtbarer Bestandteil für jeden, der sich ein Bild der Lage im System machen möchte. Es zeigt Fehler, aktuelle Meldungen und vielerlei was mit dem administrativen Status der Instanz zusammenhängt. Jedoch sind weiterführende Details von Störungen sowie viele für die Performance und die Aktivität des Systems relevante Informationen daraus nicht erhältlich und müssen aus Trace Files und den dynamischen Views der Instanz extrahiert werden. Richtig angewendet und verstanden, liefert das Alert Log aber unverzichtbare Teile zum Lagebild und ermöglicht in vielen Fällen erst Maßnahmen von der Rekonstruktion von Problemen der Vergangenheit bis hin zur Vermeidung von Fehlern der Zukunft. How to contact me Martin Klier Managing Partner / Database Technology at Performing Databases Wiesauer Strasse Mitterteich GERMANY Phone: Fax: Mobile: PERFDB7 ( ) martin.klier@performing-db.com About my company We are "performing databases" - and we are keen on caring for you: "Your reliability. Our concern." Specialized in services around database technology, supreme performance and the highest availability of your systems is our ultimate and most important goal. Performing Databases GmbH Your reliability. Our concern. Geschäftsführer: Martin Klier, Benedikt Nahlovsky Sitz der Gesellschaft: Mitterteich HRB 4350, Amtsgericht Weiden i.d.opf VAT ID: DE Performing Databases GmbH! /!