Firebird - update BLOB-Field - Datenbank wird immer größer

[lxo]

Zitat von IBExpert:

…

Um die recordversionen dieses blobs aufzuräumen, die niemand mehr sehen kann, muss du Firebird einen Hinweis geben. Einfachster weg:
Mach nach deinem update/post und dem noch einzufügenden commit ein simples select count(*) from tabelle where .... mit genau dem
key, wo du gerade deine updates machst. wenn es da zum pk nämlich zB 5 Record versionen gibt, von denen nur 2 sichtbar
sind und keine zu alte transaktion das alles komplett blockiert, dann wird der garbagecollector asynchron beginnen, die nicht mehr benutzen blob pages
wieder freizugeben und diese werden dann bei späteren updates wieder benutzt.
…

Danke für die ausführliche Antwort. Jeder edit/Post also der Update Vorgang wird in einer eigenen Transaktion ausgeführt, habe das Beispiel nur klein gehalten um das wesentliche Problem zu verdeutlichen. Das gleiche Verhalten habe ich auch wenn ich direkt Update statements ausführe.

Verstehe ich das richtig, das ein einfaches select count(*) den garbage collector anstößt und ich bräuchte kein gfix sweep aufrufen damit die Datenbank wieder kleiner wird?
Oder würde das nur dafür sorgen, das alte Pages wiederverwendet werden?

[TBx]

Zitat von lxo:

Verstehe ich das richtig, das ein einfaches select count(*) den garbage collector anstößt und ich bräuchte kein gfix sweep aufrufen damit die Datenbank wieder kleiner wird?
Oder würde das nur dafür sorgen, das alte Pages wiederverwendet werden?

Nein, die Datenbank wird nie kleiner, auch durch gfix nicht. Es wird lediglich Speicherplatz in den Pages zur erneuten Benutzung freigegeben.
Die Datenbankgröße kannst Du ausschließlich durch Backup/Restore verringern.

[IBExpert]

Zitat von lxo:

Verstehe ich das richtig, das ein einfaches select count(*) den garbage collector anstößt und ich bräuchte kein gfix sweep aufrufen damit die Datenbank wieder kleiner wird?

Richtig verstanden, setzt aber voraus das nicht irgendeine andere alte Transaktion das noch lesen könnte, was da aufgeräumt werden könnte, egal ob die daten in dieser Transaktion überhaupt schon mal gelesen wurden oder überhaupt relevant sind.

Die Pages werden durch den Sweep bzw die garbagecollection in der Page Inventory page dann nicht mehr als belegt markiert,sondern als verfügbar (und nicht nur für andere Blobs, sondern für alles was fb damit dann machen kann). Und wie Thomas schon sagt, die DB Datei wird nicht verkleinert, weil Firebird bei Bedarf zwar neue Dateibereiche anfordert für Pages, auf den was gespeichert werden muss, diese werden an nie wieder zurück an das Betriebssystem gegeben.

Durch den Neuaufbau der Datenbankdatei beim Restore werden die unbenutzten pages, die auch schon gar nicht im Backup sind, auch nicht wieder aufgebaut, so das dabei die Datei so groß bleibt wie es erforderlich ist.

Die 80% Füllgrad Regel (use all space) lass ich mal in der Erklärung weg, die ist dabei erst mal unwichtig.