In diesem Artikel wird exemplarisch erklärt wie man bei einem konkreten Fehler, sich die Log-Datei zu Nutze machen kann um den Fehler zu beheben.
Problem:
Ein Kunde übermittelt uns folgenden Fehler: „Am 16.08.11 ist ein Fehler aufgetreten. Die Datenbank kann nach dem Zurücksetzen aus dem Backupmodus nicht mehr geöffnet werden.“
Vorgehensweise:
Dieser Fehler betrifft nur die Datenbank und nicht den ganzen Server. Wir öffnen also die Log-Datei der entsprechenden Datenbank und sehen eine Datei mit über 22.000 Einträgen.
Da uns der Kunde ein Datum mit einem Zeitraum in dem der Fehler aufgetreten ist genannt hat können wir die Anzeige der Log-Einträge schon einmal auf diesen Zeitraum begrenzen. Dafür öffnen wir den Filter (Strg+F) und geben als Start- und Enddatum den 16.08.11 an. Schon schrumpft die Anzahl der Einträge auf knapp 300.
Nun blenden wir über die Symbole alle für uns erst mal irrelevanten Daten aus. In diesem Fall sind das alle bis auf die Fehler.
Übrig bleibt ein Eintrag, die gesuchte Fehlermeldung: „Database reopen in read-write failed (Acces denied)“. Dieser Eintrag verrät uns nicht nur welcher Fehler aufgetreten ist, sondern auch den genauen Zeitpunkt.
Schauen wir uns also die um diesen Zeitraum entstandenen Einträge an, dafür müssen wir die Filter wieder rausnehmen. Zeitgleich mit der Fehlermeldung haben wir den Eintrag „Backup event completed“.
Um kurz zu zeigen wie die Einträge im Normalfall aussehen sollten, schauen wir uns die Einträge vom 15.08.11 an, also ein Tag vor der Fehlermeldung. Ganz oben in der Datei ohne lange zu suchen, werden wir auch schon fündig. „Backup event completed“ und vorher „Database switched to read-write“, hier scheint also noch alles im grünen Bereich zu sein.
Zusammenfassung:
Wir wissen also, dass sich die Datenbank nicht mehr im exklusiven Lese- und Schreibmodus öffnen lässt. Die Ursache dafür ist, dass das Betriebssystem den exklusiven Lesemodus verhindert. Nun stellt sich die Frage: Warum das Betriebssystem den Zugriff verhindert?
Lösung:
Es gibt nicht viele Gründe wieso das Betriebssystem den exklusiven Zugriff auf die Datenbank verhindert. Die häufigste Ursachen ist, dass sie bereits von einem anderem Dienst oder Prozess gesperrt ist. Es gilt nun also diesen Prozess oder Dienst zu finden und zu beenden. Damit sollte dann auch das Problem gelöst sein. Sofern es sich um die Backupsoftware handelt muss eventuell die Backupzeit angepasst werden.
Ich hoffe Ihnen hat die Artikel-Reihe zu den Log-Dateien gut gefallen und ermutigt Sie bei einem Fehler auch einmal selbst in die Log-Datei reinzuschauen.
4 Antworten
Sehr gut. Vielen Dank für diese Hinweise.
@Kilian: Zu a) und b) Diese Möglichkeit besteht zur Zeit nicht. Wir nehmen diesen Punkt jedoch gerne als Vorschlag auf.
Zu c) Die Möglichkeit des Textexports existiert mit Hilfe des Script-Utility-Kommandos "decode".
Die Syntax für den Befehl lautet:
c16_serv_cmd_win.exe decode <blog1> [<blog2>] [-start=<date>] [-end=<date>]
[-days=<int>] [-records=<int>] [-filterex=<string>] [-charset=<string>]
Mit den Parametern -start= und -end= können Sie den Zeitraum vom Export eingrenzen. Über den Parameter -filterex können Sie die unterschiedlichen Eintragstypen und -Klassen herausfiltern. Nähere Informationen erhalten Sie in der Dokumentation bzw. mit dem Befehl "c16_serv_cmd_win.exe help decode"
Ich nutze die Möglichkeiten, die der Log-Viewer bietet, gerne, habe aber nun das Problem, dass nur eine sehr einfache Textsuche möglich zu sein scheint.
Z.B. habe ich hunderte Logeinträge eines Typs mit demselben Zeitstempel, die ich per Textsuche weiter einschränken möchte. Ich möchte dabei, dass nur solche Einträge gezeigt werden, die im Text ‚ABC‘ und ‚DEF‘ oder ‚GHI‘ stehen haben.
a) Geht das, falls ja, wie?
b) Falls nicht, möchte ich anregen, dass reguläre Ausdrücke in den LogViewer-Textfilter integriert werden (etwa analog zu ‚grep‘ und ähnlichen Filter-Tools)
c) Richtig super wäre ein Textexport, weil ich die resultierende Textdatei dann so behandeln könnte, wie ich möchte.
guter Eintrag für unserer Supportabteilung. Dadurch gewinnen wir Zeit und arbeiten effizienter an Fehlermeldungen. Spart beide Seiten Zeit und die Lösung wird schneller gefunden.