Firebird Server wurde unerwartet beendet.

[tsteinmaurer]

Hallo,

wenn es keinen Hinweis im firebird.log gibt, dann wird es schwierig in irgendeine Richtung zu gehen. Welche Client-Bibliothek wird denn von den Clients verwendet? Einfach mal SysInternals ProcessExplorer anwerfen.

Hast ja sonst schon einiges versucht/geschrieben. UDFs sind immer ein "Indiz". Aber auch hier sollte etwas im firebird.log stehen.

Sonst würd ich mal den Kontakt mit dem Firebird-Dev-Team und den Einsatz eines Debug-Builds vorschlagen.

Thomas

[mkinzler]

Du könntest auch mit einem SQL-Monitor o.ä. die Staements loggen um zu sehen, ob es nicht doch an einem bestimmten Statement ( Funktion/UDF) liegt.

[MarcoWarm]

Danke erstmal für die Antworten.

Zitat von tsteinmaurer:

Welche Client-Bibliothek wird denn von den Clients verwendet?

Die 32bit fbclient.dll der Version 2.5.0

Zitat von tsteinmaurer:

Sonst würd ich mal den Kontakt mit dem Firebird-Dev-Team und den Einsatz eines Debug-Builds vorschlagen.

Das werd ich vermutlich tun müssen. Allerdings müssten wir dazu wohl einen extra Server aufsetzen, da ein DebugBuild in der Produktivumgebung wohl nicht besonders performant ist, oder?

Zitat von mkinzler:

Du könntest auch mit einem SQL-Monitor o.ä. die Staements loggen.

Die Trace-Funktion von Firebird macht das ja schon. Die Abstürze sind aber in den Trace-Logs nicht mit irgendeiner Abfrage in Verbindung zu bringen. Und die Tracelogs sagen auch nicht, daß irgendwas schief gelaufen ist. Es wird einfach getraced und getraced ... und nach dem Absturz weiter getraced... so lässt sich auch im log nicht genau sagen wann der Absturz genau war. Es sei denn man macht eine längere Neustartzeit (5Minuten) damit man den Zeitsprung sieht. Aber da steigen uns die User aufs Dach, wenn die DB 5 minuten weg ist.

[tsteinmaurer]

Gut, dann haben wir das mit der Client-Library mal geklärt. Das passt so.

Bzgl. Debug-Build: Ja, das stimmt schon, schneller wirds nicht. Ich kann nicht sagen, um wieviel prozentuell es langsamer sein wird. Aber im Falle der Bearbeitung mit dem Dev-Team wirst du vermutlich nicht rundherum kommen.

Bzgl. Trace: Dann verwendest vermutlich ein System Audit durch Setzen des Parameters in firebird.conf? Wenn ja, dann ist es richtig, dass nach dem Neustart automatisch wieder mit dem Trace begonnen wird. Was du hier brauchst ist ein User Trace, das manuell von einem Benutzer angestoßen werden muss, damit was getraced wird. Unverschämte Werbung: Unser Firebird Trace Manager (http://www.upscene.com/go/?go=fbtm) kann dir hier weiterhelfen.

lg,
Thomas

[mkinzler]

Welche Zugriffskomponenten werden eingesetzt?

[MarcoWarm]

Zitat von mkinzler:

Welche Zugriffskomponenten werden eingesetzt?

• von der Delphi-Seite: FibPlus 6.9.9 2009/2010
• einige (5-6) Clients nutzen den Firebird ODBC client: Version 2.0 Release Candidate 1 (Abstürze gibt es aber auch auf den Servern, wo der ODBC Client nicht hinkommt)
• IBExpert 2010.06.20 (Abstürze sind auch nachts, wenn niemand über IBExpert auf die Datenbank schaut)
• IBEScript.dll (immer die gleiche wie die IBExpert Version)

Gruß
Marco

[MarcoWarm]

Zitat von tsteinmaurer:

Bzgl. Trace: Dann verwendest vermutlich ein System Audit durch Setzen des Parameters in firebird.conf? Wenn ja, dann ist es richtig, dass nach dem Neustart automatisch wieder mit dem Trace begonnen wird. Was du hier brauchst ist ein User Trace, das manuell von einem Benutzer angestoßen werden muss, damit was getraced wird. Unverschämte Werbung: Unser Firebird Trace Manager (http://www.upscene.com/go/?go=fbtm) kann dir hier weiterhelfen.

Jupp wir haben das System Audit verwendet. Was das usertrace angeht müssten wir 150-200 Connections tracen 24 Stunden am Tag... da kommt ne Menge Log zusammen ... und da den schuldigen zu finden ... ich schau mir euer Tool mal an. Danke

Gruß
Marco

[tsteinmaurer]

Hallo,

ein System Audit unterscheidet sich von einem User Trace eigentlich nur dahingehend, dass halt das SystemAudit beim Firebird Server Start automatisch gestartet. Die möglichen Konfigurationsparameter sind eigentlich ident. D.h., auch mit einem System Audit kann ordentlich was zusammenkommen, wenn eine Fülle an unterschiedlichen Eventtypen mitgetraced werden.

lg,
Thomas

[MarcoWarm]

da muss ich mich mal belesen

Gruß
marco

[MarcoWarm]

Zitat von tsteinmaurer:

den Einsatz eines Debug-Builds vorschlagen.

Nur die Frage, welcher Art die CrashDumps sein müssen. Ich hab (mangels DrWatson wie hier vorgeschlagen) das neue "Standardformat" WER (Windows Error Reporting) als Crash-Report bekommen. Ich hab nun keine Ahnung, ob das dem Dev-Team was nützt. Der Report enthält allerdings ein 150Mb Heapdump.