Firebird Datei wird immer grösser und Index immer langsamer

[kandalf]

Hallo zusammen,

ich habe derzeit ein grösseres Problem mit unserer Firebirddatenbank. Wir setzen derzeit die Firebirdversion 2.5.0 ein.

Unsere Tabellen funktionieren wie eine Art Ringspeicher. Es wird sehr viel geschrieben auch auch recht viel altes wieder gelöscht, so dass nach einer gewissen Anlaufzeit ein recht stabiler Stand der Anzahl Datensätze vorhanden ist.

Stellenweise sind dabei Tabellen, in denen nur so ca. 100000 Datensätze drin sind.
Es scheint so zu sein, dass die Abfragen auf diese Tabellen mit der Zeit immer langsamer werden. Innerhalb des ersten Tages wenn der Zustand eingeschwungen ist liegen die Abfragezeit so bis zu ca. 1 Sekunde, also recht fix. (z.b. die Abfrage nach dem ältesten Datensatz). Wennd as Programm nun ein paar Tage läuft dann dauert die gleiche Abfrage plötzlich 300-1000 Sekunden. Ganz schön heftig. Manchmal hilft es die Indexstatistik neu zu berechnen, manchmal muss der ganze Index neu aufgebaut werden damit es wieder schnell geht. Alles nicht so toll.

Nun hatte ich über das Wochenende einen Test laufen, bei dem ich drei Tabellen zyklisch gefüllt habe, alle Datensätze älter als 15 Minuten wurden im Hintergrund immer gelöscht. In jeder Tabelle waren so ca. 300000 Datensätze drin mehr nicht. Nun habe ich auf der Festplatte eine Datenbankdatei, die über 6 GB gross ist obwohl ja eigentlich die Tabellen recht leer sind. Ein solches Problem hatte ich bei Kunden auch schon mal gesehen. Ich habe das gefühl, dass die Firebird in der Version 2.5 die gelöschten Datensätze nicht mehr richtig wieder verwendet, kann das sein?

Für ein paar Tips wäre ich sehr dankbar, auch evtl. für den ein oder anderen Hinweis ob ich mit dem Problem des Index noch was machen kann.

[Markus Kinzler]

Die Datensätze werden nicht physikalisch gelöscht, sollten aber später überschrieben werden. Das scheint bei euch nicht der Fall zu sein.
Irgendwelche offenen Transaktionen?

[kandalf]

Ja da schaue ich gerade nach und habe auch etwas entdeckt. In der vorletzten Nacht hat ein Indexneuaufbau nicht funktioniert. ALTER INDEX x ACTIVE.
Es kam die Fehlermeldung:

Firebird Fehler: <-607>:<335544351>:<unsuccessful metadata update. MODIFY RDB$INDICES failed. deadlock. update conflicts with concurrent update. concurrent transaction number is 3673>

Am Ende von dem Execute konnte ich die Transaktion nicht schliessen. Beim Versuch die Tansaktion zu schliessen kam die Fehlermeldung:

Firebird Fehler: <-913>:<335544336>:<deadlock. update conflicts with concurrent update. concurrent transaction number is 3673>

Diese ist dann offen geblieben und hat vermutlich das Problem erzeugt. Ich frage mich nun, warum ich die Transktion nicht schliessen konnte und was man in diesem Fall wohl am besten macht?

[kandalf]

Hm, ok das Problem kann ich nun relativ einfach forcieren. Wenn mein Thread aktiv ist der den Index neu aufbau und ich parallel mit einem anderen Programm (z.b. IBExpert) die Selektivität neu berechnen lasse dann kommt es sehr schnell zu dem Deadlock.

Wenn so etwas passiert gebe ich mit dem Befehl:
select MON$TRANSACTION_ID, MON$STATE, MON$SQL_TEXT from mon$statements

die Liste der aktiven Transaktionen aus. Komischerweise taucht die Transaktions ID die in als Deadlock aufgeführt wird dort gar nicht auf.

Ich hatte eine Schleife im Transaktion schliessen, aber diese Transaktion kann nie erfolgreich geschlossen werden und an der Stelle hatte ich ein Rollback vergessen, daher blieb das Tranakstionhandle offen. Der Rollback funktioniert.

[Thomas Steinmaurer]

MON$STATEMENTS gibt dir die Liste der Anweisungen. MON$TRANSACTIONS ist die Tabelle mit den Transaktionen.