Moin Forum,,

wir haben hier eine Anwendung, die gemeinsam mit einem Firebird Server auf einem PC läuft. Auf drei weiteren PC´s laufen Clients, die ebenfalls auf diese DB zugreifen.
Das Problem: Die Größe der DB wächst kontinuierlich, keine großen Werte, wir reden hier von ursprüpnglich ~2MB, wächst innerhalb eines Tages auf etwa 9MB. Obwohl die Anzahl der Datensätze gar nicht so stark variiert. Aber der Zugriff auf die DB wird auch stetig langsamer. Anfangs dauert die Bearbeitung eines bestimmten Programmabschnittes 150ms, am nächsten Morgen dauert es dann manchmal 1500ms.
Firebird Server ist ein Superserver, Version 2.1, Zeos Komponenten 6.6.6 stable.

Wo liegt denn hier evtl. das Problem?
Man kann alle Anwendungen schließen, Backup+Restore, dann flutscht es wieder. Aber das muß doch auch eleganter gehen, oder?
Oder man hat irgendwas Grundlegendes falsch gemacht?

Ich freue mich auf Eure Antworten!

Gruß Oliver

Klingt so, als würde ein (oder mehrere Clients) eine Transaction über lange Zeit offen halten und nicht schließen. Dann muss der Server bei Updates kontinuierlich neue Versionen von den Records anlegen. Damit wächst vermutlich die TIP stetig immer mehr an.
Gibt es in Firebird 2.1 schon die MON$-Tabellen. Wenn ja, dann schau mal in die Tabelle MON$TRANSACTIONS rein. Dort hast Du das Feld MON$TIMESTAMP, die Dir sagt, seit wann die Transaction aktiv ist. Wenn Du eine Transaction ausgemacht hast, die seit langer Zeit offen ist, dann schau in das Feld MON$ATTACHMENT_ID. Die ID merken und in MON$ATTACHMENTS gucken. Dort findest du die AttachmentID wieder. Der entsprechende Datensatz hat Felder die Auskunft geben über User, Netzwerkadresse des Clients, den Prozess (also welche EXE ist ist). Sogar die ProzessID findet sich dort. Damit kannst Du sogar die Instanz der "schuldigen" EXE ausmachen.

Und in MON$STATEMENTS kannst Du mit der AttachmentID und der TransactionsID sogar das entsprechende SQL-Statement ausmachen.

Ich würde mal die Indexe auf der Datenbank überprüfen. Meist dauert ein select wegen fehlender Indexe je mehr in der Tabelle drin ist immer länger.

jjturbo hat folgendes geschrieben :

Man kann alle Anwendungen schließen, Backup+Restore, dann flutscht es wieder.

Probleme mit einem Index sind nach dieser Beschreibung eher nicht zu vermuten.
Wenn die Ursache eine "offene Transaktion" ist, genügt meist bereits das Beenden aller verbundenen Anwendung.
Wird dieser Fehler durch eine abgestürzte Anwendung verursacht, kann man die Datenbank runter- und wieder hochfahren (alternativ den Dienst Datenbankserver neu starten).

Das Backup/Restore verkleinert nur die Datenbankdateien, das ist aber für die Geschwindigkeit eher nebensächlich.

Blup hat folgendes geschrieben :

Wenn die Ursache eine "offene Transaktion" ist, genügt meist bereits das Beenden aller verbundenen Anwendung.

Ich möchte nur nochmal etwas konkreter drauf hinweisen: Öffnen und Schließen würde die Datenbankdatei nicht wieder verkleinern! Allerdings sollten die Geschwindigkeitsprobleme dann besser sein (bis das wieder allmählich voll läuft).

Das hat vermutlich etwas mit der Eigenschaft TransactIsolationLevel der TZConnection zu tun?
Was sollte man denn da einstellen?

Das Isolationlevel hat damit nur am Rande zu tun. Was die verschiedenen Dinge heißen steht hier:
www.firebirdsql.org/...ql-transactions.html

Dennoch musst drauf achten, dass Transactions, die gestartet werden, auch in absehbarer Zeit entweder übernommen werden (Commit) oder dass es ein Rollback gibt.
Ich kenne ZEOS jetzt nicht. Vielleicht startet ZEOS selbst Transactions ohne dass Du das wirklich mitbekommst. Z.B. wenn Du eine Query öffnest wäre es denkbar dass ZEOS so lange eine Transaction offen lässt, bis Du die Query schließt. Daher mein Hinweis im ersten Post, wie Du in den MON$-Tables auf Ursachensuche gehen kannst.

Sicherlich in dem Zusammenhang sehr interessant : www.delphi-treff.de/...rebird/tzconnection/