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

[lxo]

Hallo zusammen,

kann mir jemand erklären wieso sich das so verhält bzw. was ich machen kann damit es sich nicht so verhält.

Folgendes Problem, ich schreibe kontinuierlich etwas in einen Blob rein.
Können schon mehrere tausend Male sein.
Das führt dazu, dass sich die Datenbank irgendwann extrem schnell aufbläht.
Nach dem Backup/Restore ist sie wieder deutlich kleiner.

Ich kenn diesen Effekt bei Firebird, wenn man immer wieder Delete/Insert macht, dann wird die Datenbank größer und größer und nach einem Backup/Restore ist sie wieder kleiner.
Aber wieso tritt der Effekt bei Update auf Blob-Fields auf?

Delphi-Quellcode:

  
// Verallgemeinert, aber so in etwa schreibe ich immer wieder in das Blobfeld
var lQuery := TUniQuery.Create(nil);
  try
    lQuery.Connection := GetConnection;
    lQuery.SQL.Text := 'Select t.* from TEST t ' +
                       'Where t.ID = 1';
    lQuery.Execute;
    if not lQuery.IsEmpty then
    begin
      lQuery.Edit;
      lQuery.FieldByName( 'BLOBTEST').AsString := lQuery.FieldByName( 'BLOBTEST').AsString  + sLineBreak +
                                                  Now.toString + ';' + Random(100000).ToString + ';' + Random(100000).ToString;
      lQuery.Post;
    end;
  finally
    lQuery.Free;
  end;

[Uwe Raabe]

Blobs werden ja nicht im eigentlichen Record gespeichert, sondern in speziellen Pages. Daher entspricht ein Update auf ein Blob-Feld einem Insert/Delete.

[lxo]

Zitat von Uwe Raabe:

Blobs werden ja nicht im eigentlichen Record gespeichert, sondern in speziellen Pages. Daher entspricht ein Update auf ein Blob-Feld einem Insert/Delete.

Und das kann man nicht umgehen, in dem man immer wieder auf die selbe Pages schreibt?

[mjustin]

Exakt das gleiche Problem habe ich mit Oracle 19c (und Db2 for i) dieses Jahr beobachtet. Oracle Tablespace, der noch ca. 10 GB Platz hat, ist nach wenigen Minuten voll. Geschrieben wurden aber nur maximal wenige MB mit einem Protokoll, immer in das gleiche DB-Feld. Der "unbenutzte", aber dennoch blockierte Tablespace kann nur durch einen Admin wieder freigemacht werden.

Eine Lösung wäre, auf normale Char-Datentypen umzustellen und das Log darin normal (Satz für Satz inserten) zu schreiben...

[lxo]

Zitat von mjustin:

Exakt das gleiche Problem habe ich mit Oracle 19c (und Db2 for i) dieses Jahr beobachtet. Oracle Tablespace, der noch ca. 10 GB Platz hat, ist nach wenigen Minuten voll. Geschrieben wurden aber nur maximal wenige MB mit einem Protokoll, immer in das gleiche DB-Feld. Der "unbenutzte", aber dennoch blockierte Tablespace kann nur durch einen Admin wieder freigemacht werden.

Eine Lösung wäre, auf normale Char-Datentypen umzustellen und das Log darin normal (Satz für Satz inserten) zu schreiben...

Da habe ich aber die Grenze von 32.767 Bytes beim Typ VARCHAR. Das reicht an der Stelle nicht.

[TBx]

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.

[Uwe Raabe]

Zitat von lxo:

Und das kann man nicht umgehen, in dem man immer wieder auf die selbe Pages schreibt?

Das solltest du besser die Entwickler von FireBird fragen. Allerdings kannst du die gleiche Frage dann auch für das UPDATE eines normalen Record stellen. Ich gehe mal davon aus, das ist ganz tief in der Interbase/Firebird-Architektur verankert und wird wohl nicht so schnell geändert werden. Hat ja vermutlich auch was mit Transaktionssicherheit zu tun.