DB Firebird 3.0 wächst extrem

[IBExpert]

Das mit dem Blob ändern ist sicherlich Teil des Problems, weil alle Versionen des Blob vor dem update komplett in der db bleiben und nach dem update neu reingeschrieben werden, weil sonst kein rolllback möglich wäre und blobs halt auch mal 1GB sein können, wenn man das braucht (geht je nach pagesize mit bis zu 128GB pro Blob Feld und Record.

Es gibt auch ein Tracker Eintrag, aus dem deutlich wird, das das sogar bei Variablen vom Typ Blob passiert, ohne das die überhaupt in eine Tabelle geschrieben werden sollen: http://tracker.firebirdsql.org/browse/CORE-5114

Also ist es sicherlich ein guter vorschlag, statt einen Blob mehrfach zu ändern, diesen besser zu lösche und neu einzutragen, weil da der Garbagecollector das Leben ein wenig einfacher hat.

Wenn aber keine alte Transaktion offen ist, dann würde ein zugriff auf die Blob inhalt auch den Garbage collector anschmeissen. In dem Falle dann nicht einfach regelmäßíg select count(*) machen, sondern zB

select sum(char_length(blobspalte)) from tabelle

(das zwingt Firebird dazu, sich die Blobinhalte mit alle pages anzuschauen und benachrichtigt den Garbagecollector über nicht mehr benutzte blob pages.

[jobo]

ggF. hilft auch die exakte Prüfung der Where Clauses, vielleicht wird zu viel aktualisiert.
Und
vielleicht ein kleiner Umbau mit 1:1 Relation von Hauptdaten zu Blobdatentabelle. Letztere dann nur ändern, wenn es wirklich sein muss.