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

[IBExpert]

Zitat:

Zitat von lxo (Beitrag 1520146)

Zitat:

Zitat von TBx (Beitrag 1520142)

Wenn es sich hier tatsächlich um ein Log handelt, so würde ich das nicht in ein Blob-Feld schreiben.
Ich würde das über eine LogTabelle lösen, in der jeder Logeintrag ein Datensatz ist.
Logs in Blobfelder zu schreiben nimmt einem ja alle Auswertungsmöglichkeiten, die einem die Datenbank sonst bietet.

Ja, das sehe ich auch als beste Lösung. :thumb:

wenn das wie in deinem Beispiel dynamisch erweiterte Dateninhalte sind, dann ist das sowieso der Weg, den man gehen sollte.

Die Inhalte von so einem Log File sind ja im Filesystem unter anderen Voraussetzungen in einer Datei zusammengefasst, da
gibt es aber auch kein multiuser read/write zugriff, kein commmit, kein rollback, keine versionierung usw.

Zeilenweise einelne Records erfassen und die dann bei Bedarf gefiltert lesen ist bei der Idee von Log Files der Weg, den
man damit sauber umsetzt.

Beim Speichern von pdf dateien oder Bildern gibt es das Problem aber nahezu gar nicht und wenn jemand da zum Beispiel ein Memofeld
mit Text oder Html oder RTF Inhalten speichert, dann werden die sich sicherlich nicht hundertmal pro Sekunde um neue Zeilen ergänzen,
weil die daten dann dort eher durch Interaktion in einem Texteditor ergeben und dann verändert gespeichert werden, wenn der Anwender das möchte.

Es ist also wie fast immer, für den jeweiligen Anwendungsfall muss man immer die passenden Datentypen auswählen.

[lxo]

Zitat:

Zitat von IBExpert (Beitrag 1520155)

…

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:

Zitat von lxo (Beitrag 1520164)

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:

Zitat von lxo (Beitrag 1520164)

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.