Firebird plötzlich langsam...

[alzaimar]

Ahoj

Heute komme ich zu einem Kunden, dort ist ein PC, auf dem Firebird 2.1 sowie zwei Delphi-Apps laufen.
Die eine App bläst ständig Daten in die DB, die andere liest sie wieder aus und löscht sie. Fragt bitte nicht nach dem Sinn dieser Geschichte, aber so isses jedenfalls. Normalerweise ist das System recht flott und belastet den PC nicht sonderlich.

Firebird war aber ziemlich lahm: anstatt für eine bestimmte Transaktion 100ms zu verbraten, war FB nun plötzlich 500-1000ms unterwegs, um 10 Zeilen in eine an sich leere Tabelle zu schreiben. Ich bin mir 99,9% sicher, das sonst nicht viel mit der DB los war.

Ich musste FB abschießen, woraufhin der fbguard es neu startete und anschließend war die (Performance-)Welt wieder in Ordnung.

Frage: Gibt es Zeiten, in denen FB aufräumt, sich selbst organisiert oder sonste was macht, oder wie sonst ist diese Spassbremse sonst zu erklären? Oder: Ist dieses Problem bekannt, oder sitzt es vielmehr vor dem PC (bin ich also der Depp? Ihr könnt ruhig ehrlich sein )

Großartige Fehlerursachenforschung müsst ihr nicht betreiben. Es reicht ein:
A) Sowas kommt nie vor
B) Kenn ich, da musst Du .... machen

Bonusfrage: Kann man Firebird irgendwie per Skript/Batch mal eben zum re-initialisieren bringen? Den fbserver.exe abschießen würde ich nur ungerne machen...

[MagicAndre1981]

da ist noch eine alte Transaktion offen und wegen der MGA wird das dann langsam. Über die Monitoring Tabellen siehst du welche Transaktion offen ist und wann sie gestartet wurde

[TBx]

Hallo,

das riecht dannach, dass da eine Transaktion lange Zeit offen bleibt. Guck Dir dazu mal die Statistik an, die nächste Transaktion und die älteste aktive sollten nicht zu weit auseinanderliegen.

Die Aufräumarbeiten gibt es, das sog. Sweepen. Das wird hier aber vermutlich nicht der Grund für den Geschwindigkeitsverlust sein.

Die Idee mit dem erneut initialisieren würde ich ganz schnell verwerfen, das ist Vertuschen der Probleme und nicht Abstellen.

Gruß

Thomas

[alzaimar]

Super, mein Verdacht ging in die Richtung. Nun muss ich los, wieder auf diese Baustelle. 'Monitoring Tabellen'.... mal sehen, was das ist.. *googel googel googel*, Ah... ja. Teste ich gleich.

Danke für die Hinweise!

[nahpets]

Hallo,

wie sieht die Transaktionsbehandlung in den beiden Programmen aus?
Eine Transaktion für die gesamte Programmlaufzeit?
Oder jedes Statement in einer Transaktion bzw. klar definierte Transaktionsklammern?
Kann es sein, dass das Löschprogramm schon Daten wegwirft, bevor das Füllprogramm mit seiner Transaktion für diese Daten fertig ist?

Meine bisherige praktische Erfahrung ist (datenbankunabhängig):

Je mehr Daten in einer Transaktion eingefügt und/oder gelöscht werden, um so langsamer wird das.

Wie sieht das mit den Indizes aus?
Gibt es da viele, die permanent aktualisiert werden müssen?
Das kann durchaus auch schon mal zu 'ner Spassbremse werden.

Anstatt die Datenbank gewaltsam neu zu starten, wäre es einen Versuch wert, die Programme einzeln mal zu beenden und dann neu zu starten. Wenn sich das Verhalten dann ändert, stimmt in dem beendeten und neu gestarteten Programm das Transaktionshandling (höchstwahrscheinlich) nicht. So ein Test kann aber schon mal Stunden/Tage dauern, da man ja nie so genau weiß, wann die Schmerzgrenze bei der Datenbank erreicht ist.

Eine unelegante Methode, dieses Problem zu umgehen ist:
Arbeitsschritt- oder zeitabhängig (kommt auf die Programmlogik an) die Datenbankverbindung der Anwendung zu schließen und wieder neu aufzubauen. Dabei werden (in der Regel) Reste, die auf eine ungeschickte Programmierung zurückzuführen sind (offenen Transaktionen...) abgebaut und eine neue, saubere Verbindung hergestellt.
Diese Methode hilft auch, wenn man Datenbanktreiber/-schnittstellen benutzen muss, die leicht fehlerhaft sind und bei permanenter Benutzung zu Problemen führen.

[mquadrat]

Wie du wahrscheinlich schon rausbekommen hast kannst du über die Monitoring-Tabellen sogar den lokalen Prozess identifzieren, der die Transaktion offen lässt. Voraussetzung ist, das die Clients auch 2.1 benutzen, aber wenn ich richtig gelesen habe ist das ja eh die gleiche Maschine.

Soetwas wie einen Reset gibt es auch. Einfach ein Backup und anschließend ein Restore. Da wird dann der ganze Housekeeping-Kram wie Speicher freigeben und Indizes neu aufbauen gemacht. Funktioniert natürlich nur, wenn man keinen 24 Stunden Betrieb braucht, sondern mal ein Stündchen abschalten kann.

[alzaimar]

So. Die Ursache lag... vielmehr...hüstel...saß... wie soll ich sagen .. nun ja, ca. 80cm vor dem Problem...

Eine Query, die sonst ein paar ms dauert, hat wohl den Server für Minuten lahm gelegt. Natürlich war da eine Transaktion aktiv, die schon etwas älter war... aber wen wunderts, wenn die Query ein wenig länger dauert als üblich. Eine Tabelle, die normalerwiese 1-10 Einträge hat, war nun bei 1,5 Mio Records angelangt. Die Torfnase, die die Query gebastelt hat, hat nicht drauf geachtet, das diese auch mal etwas länger werden könnte... Ich wars jedenfalls nicht, Ehrenwort.

Danke auf jeden Fall an Alle, denn diese Transaktions-Geschichte war der Schlüssel zur Fehlerbehebung...

Einmal mehr gilt:

@Nahpets: Die Apps einzeln mal zu beenden, hat den Schurken dann entlarvt. Es war der Gärtner, nicht der Verdächtige....

PS: Ich *hasse* es, fremden Code zu übernehmen, der dann unter Zeitdruck beim Kunden installiert werden muss...