DB Firebird 3.0 wächst extrem

[Gruber_Hans_12345]

Hallo ich habe eine Datenbank mit Firebird 3.0 erstellt, wo ich nun zyklisch (5 Sekunden) Einträge in eine Log schreibe.
Die Logs werden aber nicht immer geinsert sondern, mit UPDATE OR INSERT geschrieben, in einen Ring Buffer.

Also es gibt nur 1440 Einträge für das Log wo nach den 1440 Eintrag wieder bei eins angefangen wird.

Also nach einer gewissen zeit werden nur mehr Updates gemacht.

Das problem ist, das nun die Datenbank extrem wächst zum Teil.
Das Backup ist gerade mal 2MB groß, im Moment ist die 300MB groß (nach ca. 2 Stunden lauf und Speichern der Index) vor kurzem hatte ich das Problem das sie 3GB groß war und mir der Speicherplatz ausging.

Mir wäre es verständlich, wenn ich DELETE und INSERT mache jedesmal, aber mit primitiven UPDATES?

ein weiter punkt ist, das ich alle 5 Sekunden ein UPDATE (in eine andere Tabelle) mache wo ich ein BLOB Feld aktualisiere mit 100kB ...

was kann ich da noch optimieren?

[hstreicher]

Firebird ist eine Transactionsorientierte Datenbank , d.h. sie hält verschiedene Versionen der Datensätze bereit.
D.H. es mach keinen Unterschied ob Insert oder Update ,da das Update auch einen neuen Datensatz erstellt mit einen höheren Versions(transaction)-Zähler als der alte

Das Problem so wie ich es sehe ist dass die Transactionen nicht committed werden (Commitretaining genügt nicht)
dann werden die alten Versionen der Daten nicht freigegeben und die Sweep und Garbagecollection Mechanismen
können die alten Daten nicht freigeben

mfg Hannes

[Gruber_Hans_12345]

Also eigentlich mache ich immer ein Commit, ich habe einen Dienst der immer reinschreibt und nach den 5 sekunden dann auch das Commit macht.
Und andere Prozesse die daraus lesen

Auch die Database Statisk schaut nicht shcelcht aus hätte ich gesagt (NExt Transaction und oc)

Code:

Database "D:\INTERBASE\MONITOR.FDB" 
Database header page information: 
   Flags         0 
   Generation      25109 
   System Change Number   0 
   Page size      8192 
   ODS version      12.0 
   Oldest transaction   25058 
   Oldest active      25059 
   Oldest snapshot      25059 
   Next transaction   25062 
   Sequence number      0 
   Next attachment ID   29 
   Implementation      HW=AMD/Intel/x64 little-endian OS=Windows CC=MSVC 
   Shadow count      0 
   Page buffers      0 
   Next header page   0 
   Database dialect   3 
   Creation date      Aug 6, 2017 8:52:15 
   Attributes      force write 
 
    Variable header data: 
   Sweep interval:      20000 
   *END*

[hoika]

Hallo,
und die anderen, lesenden Prozesse machen auch ein Commit?

Mach doch mal ein Backup/Restore.
Wenn die DB dann wieder klein ist, liegt es an den Transaktionen.

[Gruber_Hans_12345]

Ja mit Backup & Restore wirds wieder klein.

Eigentlich schon
allerdings muss ich sagen,das ich gerade gemerkt habe,, das ich mit der IBConsole noch drauf war, und die hält eine Transaktion ja immer offen .... hab die mal geschlossen und schaue obs noch weiter wächst

[mjustin]

Zitat von Gruber_Hans_12345:

allerdings muss ich sagen,das ich gerade gemerkt habe,, das ich mit der IBConsole noch drauf war, und die hält eine Transaktion ja immer offen .... hab die mal geschlossen und schaue obs noch weiter wächst

Dann hätte in der Datenbankstatistik eine grosse Differenz zwischen der ältesten und der aktuellen Transaktionsnummer sichtbar sein müssen. Die IBConsole-Transaktion müsste dann die älteste ID gehabt haben. Wenn die Differenz tatsächlich nur 3 ist, passt das nicht.

[mjustin]

Ist der Effekt reproduzierbar? Tritt er nur auf wenn IBConsole geöffnet ist?

Da bei uns eine größere InterBase Installation im Einsatz ist die wir eventuell auf Firebird migrieren wollen, ist das Thema "offene Transaktionen" uns schon öfter begegnet, aber eine so schnell wachsende Datenbank bisher nicht (wir erzeugen bei einer Transaktionsdifferenz von über 20000 einen Alarm).

[mkinzler]

Das Problem ist vermutlich der Blob, der regelmässig aktualisiert wird ( = neue Version = neuer DS)
Für die Implementierung der Emulation eines Ringpuffers ist eine DBMS ( speziell ein auf Versionierung basierendes System) nicht so geeignet.
Ein Delete mit neuem Insert wäre m.E. besser. Da hier dann die Datensätze sofort als gelöscht markiert werden und dann direkt Überschrieben werden können.

[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.