Garbage Collection

[kandalf]

Ich habe mal ne Frage.

Ich habe ein Problem mit Tabellen, bei denen sehr viele Datensätze in kurzer Zeit eingefügt und gelöscht werden. (Eine Art Ringspeicher, altes löschen neues rein) Bei diesen Tabellen werden nach ca. 4-5 Tagen Laufzeit die Zugriffe der verschiedenen Abfragen immer langsamer. Wenn ich den Index neu aufbaue geht es wieder super schnell. Dieses Problem habe ich erst seitdem wir Firebird 2.5 einsetzen.

Ich habe irgendwie mal gehört, dass es auch daran liegen könnte, dass die Daten nicht wirklich richtig gelöscht werden. Irgendwie kann man in Tabellen nachschauen welche Datensätze wirklich freigegeben wurden oder sowas. Angeblich soll manchmal der Garbage Collector nicht richtig dazu kommen etwas aufzuräumen.

Habt ihr ein paar Tips für mich wo ich suchen könnte um das Problem einzukreisen?

[kandalf]

Ist ja schon was her aber immer noch aktuell. Kann mir jemand von euch evtl. sagen wo man was überprüfen könnte?

[defo]

Soweit ich das im Kopf hab, geht es beim "richtig Löschen" nur um offene Transaktionen. Das wird bei Dir über Tage hinweg nicht der Fall sein.
Du schreibst aber selbst von der Index Reorganisation, die den Zugriff beschleunigt.
Auch hier fehlen mir Detailkenntnisse über die Möglichkeiten und die Umsetzung der Indizierung in FB, aber "normale" Indizes vergammeln nun mal gern. Bei "langsam" wachsenden oder statischen Tabellen fällt es kaum bis gar nicht auf. In Deinem Fall liegt es wohl in der Natur der Sache.
Der Index entartet, weil immer mehr Einträge gelöscht werden.

Es wäre nicht meine Soformaßnahme aber schau mal hier: http://www.firebirdnews.org/?p=5051

[kandalf]

Das blöde ist, dass der Aufbau vom index extrem lange dauert und die Datenbank sehr belastet. Da bei uns dauerhaft gespeichert wird führt das zu unheimlichen Verzögerungen.

[defo]

MMh, hast du die Möglichkeit, das alter index active unter halbwegs realistischen Bedingungen auszuprobieren?
Was bedeutet den lange und welche Prozesse kommen während dessen zum Erliegen?
Ein Ringspeicher, der so groß ist, dass Reindizierung so lange dauert ist vielleicht auch kein optimaler Ansatz. Wieviel Daten sind es und vor allem, wieviele Indices?

[kandalf]

Nun, so eine Tabelle die Daten von ca. 30 Tagen halten soll hat schnell so 1-10 Millionen Datensätze. Auf der Tabelle sind ca. 7-8 Indices für die unterschiedlichen Suchen.

[defo]

Hast Du alter index active schon mal versucht?
Wenn man die Indices so nicht online aktualisieren kann, ist das bei der Größenordnung wohl ein Limit, das eher mit einer professionellen Db zu lösen ist.

Alternativ kannst du Dein Konzept verschlanken, aber das ist nur ein bisschen Zeitgewinn.

[kandalf]

Ja sicher, früher habe ich alle paar Tage nachts einfach alle Indices der Tabellen mit Alter index xx incative und alter index xx active neu aufgebaut.
Bei größeren Systemen dauerte dieser Vorgang insgesamt aber schon gerne mal 1-2 Stunden.
Im Moment mache ich es so, dass ich die SQL Afragen immer analysiere wie lange sie benötigen. Wenn die zeit dann größer wird analysieren ich den PLAN dazu und baue nur den Indexneu auf, der bei diesem Kommando verwendet wird.

Ich lasse gerade noch mal ein Aufbau aller Indices auf meiner Testdatenbank laufen, dann kann ich nachher sagen wir lange es genauert hat.

Ein weiteres Problem alle Indices neu aufzubauen ist das Arbeitsspeicherproblem. Dazu habe ich auch noch einen anderen Thread aufgemacht. Anscheinend ist es hier das gleiche Problem.

Der Prozess nimmt sich ohne Ende Speicher! ohne dass man es beim Prozess selbst sieht. Im Process Explorer sieht man nur, dass der Wert für Cache WS extrem ansteigt.

Ich finde keine Möglihckeit, diesen Speicherbedarf einzugrenzen. Das Problem ist, dass die Systeme evtl. eskalieren da für die anderen Prozesse plötzlich nich tmehr genug Arbeitspeicher zur Verfügung steht!
Leider wird der Speicher auch nicht mehr freigegeben, wenn die Kommados alle abgearbeitet wurden.

Es ist auch kein Speicherfehler in meinem Prozess, wenn ich z.b. mit IBExpert diese SQL Befehle absetzte habe ich das gleiche Problem.

[defo]

Schön, wenn Du ein Testsystem hast, dann versuch doch bitte mal wie in dem Link beschrieben den inactive Schritt weg zu lassen. Das ist ja angeblich der Clou.

Ansonsten würde ich testen (>Testsystem), ob man Indices zusammenfassen kann, also wie groß die Einbußen sind, Ausführungspläne vergleichen usw. einfach abspecken.

[kandalf]

Hey, ja werde ich mal machen.
Wobei es natürlich nicht so einfach zu ermitteln ist ob es zeitlich geholfen hat.
Wenn mein Durchlauf hier beendet ist teste ich es mal nur mit dem active Kommando.

hast du eine Idee was den Arbeitsspeicher betrifft?

[kandalf]

Das hier:
It’s necessary to say that such rebuilding of indices (as well as majority of metadata operations) should be performed in exclusive mode.
Do not run it while users are actively write or update records, it can lead to corruption.

Ist natürlich etwas was auf keinen Fall passieren dürfte. Da in unserem System ständig zyklisch geschrieben wird und auch keine Pausen möglich sind sind diese Operationen immer sehr gefährlich.

Ich habe in der Vergangenheit ja schon so einiges erlebt, was die Datenbank zerstören kann es man es zur Laufzeit durchführt. Bin da etwas vorsichtig.

[defo]

Ich würd es nicht unbedingt zeitlich austesten, sondern die Veränderung in den Ausführungsplänen heranziehen. Grundsätzlich am ehesten Felder mit den wenigstens unterschiedlichen Werten aus der Indizierung rausnehmen oder mit "stärkeren" Feldern in einem kombinierten Index zusammenfassen.

Speicher:
Keine Ahnung, ich nutze FB nur für Experimente. Ich hab keine Erfahrung mit solchen Interna. Klingt aber etwas nach Bug.

[kandalf]

Ok, werde das mit meinen Indextabellen mal alles in Ruhe ausprobieren. Wird dann wohl was dauern :-(
Ich dachte immer Indextabellen mit mehreren Spaltenverknüpfungen wären deutlich schlechter als wenn ich für die ein oder andere Spalte einen eigenen Index anlege.

Muss ich dann wohl mal ausprobieren und sehen was ich sparen kann.