Wenn man mit Firebird-Datenbanken arbeitet, kommt irgendwann der Punkt, an dem man genau wissen möchte, welche SQL-Statements tatsächlich auf der Datenbank ausgeführt werden. Vielleicht, um Performance-Probleme zu untersuchen, vielleicht um unerwartetes Verhalten einer Anwendung zu verstehen oder einfach, um ein besseres Gefühl für den Datenbankzugriff zu bekommen.

Firebird bringt dafür seit der Version 2.5 ein sehr mächtiges Werkzeug mit: das Trace- und Audit-Subsystem. Damit lassen sich Abfragen, Transaktionen, Verbindungsinformationen und vieles mehr protokollieren – ohne dass man tief ins System eingreifen oder die Anwendung verändern muss.

In diesem Beitrag zeige ich dir Schritt für Schritt, wie du mit Firebird 2.5.9 unter Linux (egal ob direkt auf dem Host oder in einem Docker-Container) ein SQL-Logging aktivierst und die Ergebnisse live einsehen kannst.

Trace-Konfigurationsdatei erstellen

Der Trace-Mechanismus in Firebird braucht zunächst eine Konfigurationsdatei, die beschreibt, was geloggt werden soll. Diese Datei kann an einem beliebigen Ort liegen – wir nehmen in diesem Beispiel /opt/fb_trace_all.conf.

Öffne die Datei mit einem Editor deiner Wahl, zum Beispiel nano oder vi:


Füge dann den folgenden Inhalt ein:


Was bedeutet das?

* enabled true – Schaltet das Logging für die Datenbank ein.
* log_connections true – Verbindungs- und Trennungsereignisse werden protokolliert.
* log_statement_prepare true – Auch das „Vorbereiten“ eines SQL-Statements (also bevor es ausgeführt wird) wird festgehalten.
* log_statement_start true / log_statement_finish true – Beginn und Ende jeder Abfrage werden geloggt.
* print_plan true – Der Ausführungsplan (Execution Plan) für jede Abfrage wird mit ausgegeben – sehr nützlich, wenn es um Performance geht.
* print_perf true – Zeitmessungen und andere Performance-Daten werden angezeigt.
* time_threshold 0 – Es gibt keine Mindestzeit; jede Abfrage wird geloggt, egal wie kurz sie läuft.
* max_sql_length / max_arg_length / max_arg_count – Diese Werte legen fest, wie groß die protokollierten SQL-Statements und ihre Parameter werden dürfen.

Mit dieser Konfiguration erhältst du ein sehr detailliertes Protokoll, das alle SQL-Statements sichtbar macht, die gegen deine Firebird-Datenbank laufen.

Trace Watcher starten

Nun muss Firebird angewiesen werden, diesen Trace-Job zu starten. Das geschieht über das Tool fbtracemgr, das mit der Firebird-Installation mitgeliefert wird.

Beispiel:


Erklärung der Parameter:

-se localhost:service_mgr – Verbindung zum Service Manager auf localhost.
-user SYSDBA -pass masterkey – Authentifizierung mit dem Standard-Administrator-Account.
-start – Startet einen neuen Trace-Job.
-name allsql – Vergibt einen Namen für diesen Job, z. B. „allsql“.
-conf /opt/fb_trace_all.conf – Verweist auf die Konfigurationsdatei von oben.
>> /tmp/lognamen.log – Leitet die Ausgabe in eine Log-Datei um.

Der Prozess läuft so lange, bis er manuell beendet wird (z. B. mit Ctrl+C).

Logdatei live mitverfolgen

Um nicht immer wieder die Log-Datei neu öffnen zu müssen, empfiehlt sich ein „Live-Tail“. In einem zweiten Terminal kannst du dir die Einträge direkt beim Eintreffen anschauen:


Jetzt siehst du sofort, wenn deine Anwendung eine Abfrage an Firebird schickt – inklusive der SQLs, der Ausführungspläne und der Performance-Daten.

Praktische Tipps
Docker-Setup: Wenn Firebird in einem Container läuft, musst du nur darauf achten, dass sowohl das fbtracemgr-Binary als auch die Konfigurationsdatei im Container verfügbar sind. Ein Volume-Mount für /opt/fb_trace_all.conf und /tmp/lognamen.log ist sinnvoll.

Ressourcen im Blick behalten: Da jede Abfrage geloggt wird, kann die Logdatei schnell sehr groß werden. Für längere Analysen solltest du mit Filtern arbeiten oder ein Tool wie grep verwenden.

Filterung: Du kannst in der Konfigurationsdatei auch bestimmte Datenbanken oder bestimmte Events ausschließen, um die Menge der Informationen überschaubarer zu halten.

Sicherheit: Achte darauf, dass sensible Daten (Passwörter, personenbezogene Daten) in Logs landen können. Im Produktivbetrieb sollte man also genau abwägen, welche Daten man wirklich braucht.

Fazit

Mit dem Firebird-Trace-Subsystem hat man ein mächtiges Werkzeug an der Hand, das es erlaubt, SQL-Abfragen transparent zu überwachen und zu analysieren. Gerade bei der Fehlersuche oder bei Performance-Optimierungen ist das oft der schnellste Weg, um zu verstehen, was im Hintergrund tatsächlich passiert.

Die hier gezeigte Konfiguration ist ein „Alles mitnehmen“-Ansatz, mit dem man sofort loslegen kann. Danach kann man Schritt für Schritt Feintuning betreiben, um genau die Informationen zu loggen, die man wirklich braucht.