Firebird DB - verkleinern ohne Backup/Restore

[Gruber_Hans_12345]

Hallo mal eine bescheidene Frage, meine datenbank wächst und wächst und wächst.
Ich habe einen Timer im Service drinnen, der jeden Tag die alten Daten rauslöscht, was auch gemacht wird

Ich dachte mir, das dann der gelöschte Bereich mit den neuen Daten überschrieben wird, aber die DB wächst nur.

Die dB abzudrehen,ein Backup und Restore zu machen, möchte ich gerne vermeiden, da dann auch alle anderen Programme, damit zu recht kommen müssen

Im Moment hat die DB 72 GB
Wenn ich Backup und Restore mache, dann braucht die DB nur mehr 17GB

Gibt es da eine Möglichkeit?

[Uwe Raabe]

Wie groß ist das SWEEP Intervall?

[Gruber_Hans_12345]

20000

Es handelt sich hier um eine logging DB wo sehr sehr viele einträge reinkommen, die dann periodisch um 24:00 wieder gelöscht werden (abhängig von der priorität)
nur eben wächst die DB dermassen an, das es schon problematisch ist ...

Code:

Service started at 10.01.2013 17:20:53
 
Database "d:\DB\logging.fdb" 
Database header page information: 
   Flags         0 
   Checksum      12345 
   Generation      71323419 
   Page size      8192 
   ODS version      11.2 
   Oldest transaction   71319978 
   Oldest active      71319979 
   Oldest snapshot      71319979 
   Next transaction   71322417 
   Bumped transaction   1 
   Sequence number      0 
   Next attachment ID   990 
   Implementation ID   26 
   Shadow count      0 
   Page buffers      4000 
   Next header page   0 
   Database dialect   3 
   Creation date      Dec 4, 2011 16:35:43 
   Attributes      force write 
 
    Variable header data: 
   Sweep interval:      20000 
   *END* 
 
 
Database file sequence: 
File d:\interbase\system.fdb is the only file 
 
Analyzing database pages ... 
CLIENT_LOG (135) 
    Primary pointer page: 164, Index root page: 165 
    Data pages: 207, data page slots: 207, average fill: 77% 
    Fill distribution: 
    0 - 19% = 1 
   20 - 39% = 0 
   40 - 59% = 0 
   60 - 79% = 206 
   80 - 99% = 0 
 
    Index RDB$PRIMARY7 (0) 
   Depth: 2, leaf buckets: 10, nodes: 16150 
   Average data length: 1.00, total dup: 0, max dup: 0 
   Fill distribution: 
        0 - 19% = 0 
       20 - 39% = 0 
       40 - 59% = 0 
       60 - 79% = 0 
       80 - 99% = 10 
 
LOG_ITEM (128) 
    Primary pointer page: 150, Index root page: 151 
    Data pages: 82804, data page slots: 184513, average fill: 80% 
    Fill distribution: 
    0 - 19% = 6270 
   20 - 39% = 98 
   40 - 59% = 89 
   60 - 79% = 4932 
   80 - 99% = 71415 
 
    Index LOG_ITEM_DATUM (2) 
   Depth: 3, leaf buckets: 3383, nodes: 3404270 
   Average data length: 2.01, total dup: 18823, max dup: 1 
   Fill distribution: 
        0 - 19% = 3 
       20 - 39% = 10 
       40 - 59% = 15 
       60 - 79% = 16 
       80 - 99% = 3339 
 
    Index LOG_ITEM_MODUL (1) 
   Depth: 3, leaf buckets: 3850, nodes: 3404270 
   Average data length: 0.00, total dup: 3404022, max dup: 2882862 
   Fill distribution: 
        0 - 19% = 34 
       20 - 39% = 677 
       40 - 59% = 1965 
       60 - 79% = 797 
       80 - 99% = 377 
 
    Index RDB$PRIMARY1 (0) 
   Depth: 3, leaf buckets: 2563, nodes: 3404270 
   Average data length: 1.02, total dup: 0, max dup: 0 
   Fill distribution: 
        0 - 19% = 3 
       20 - 39% = 16 
       40 - 59% = 8 
       60 - 79% = 11 
       80 - 99% = 2525 
 
LOG_MODUL (129) 
    Primary pointer page: 152, Index root page: 153 
    Data pages: 8, data page slots: 22, average fill: 49% 
    Fill distribution: 
    0 - 19% = 3 
   20 - 39% = 0 
   40 - 59% = 0 
   60 - 79% = 5 
   80 - 99% = 0 
 
LOG_PRIORITY (130) 
    Primary pointer page: 154, Index root page: 155 
    Data pages: 0, data page slots: 0, average fill: 0% 
    Fill distribution: 
    0 - 19% = 0 
   20 - 39% = 0 
   40 - 59% = 0 
   60 - 79% = 0 
   80 - 99% = 0 
 
    Index RDB$PRIMARY2 (0) 
   Depth: 1, leaf buckets: 1, nodes: 0 
   Average data length: 0.00, total dup: 0, max dup: 0 
   Fill distribution: 
        0 - 19% = 1 
       20 - 39% = 0 
       40 - 59% = 0 
       60 - 79% = 0 
       80 - 99% = 0 
 
LOG_PRUNE (132) 
    Primary pointer page: 158, Index root page: 159 
    Data pages: 1, data page slots: 1, average fill: 9% 
    Fill distribution: 
    0 - 19% = 1 
   20 - 39% = 0 
   40 - 59% = 0 
   60 - 79% = 0 
   80 - 99% = 0 
 
    Index RDB$PRIMARY3 (0) 
   Depth: 1, leaf buckets: 1, nodes: 13 
   Average data length: 1.08, total dup: 0, max dup: 0 
   Fill distribution: 
        0 - 19% = 1 
       20 - 39% = 0 
       40 - 59% = 0 
       60 - 79% = 0 
       80 - 99% = 0 
 
LOG_SEND_SUPPORT (133) 
    Primary pointer page: 160, Index root page: 161 
    Data pages: 1, data page slots: 1, average fill: 3% 
    Fill distribution: 
    0 - 19% = 1 
   20 - 39% = 0 
   40 - 59% = 0 
   60 - 79% = 0 
   80 - 99% = 0 
 
    Index RDB$PRIMARY5 (0) 
   Depth: 1, leaf buckets: 1, nodes: 5 
   Average data length: 1.20, total dup: 0, max dup: 0 
   Fill distribution: 
        0 - 19% = 1 
       20 - 39% = 0 
       40 - 59% = 0 
       60 - 79% = 0 
       80 - 99% = 0 
 
LOG_SETTINGS (131) 
    Primary pointer page: 156, Index root page: 157 
    Data pages: 1, data page slots: 1, average fill: 2% 
    Fill distribution: 
    0 - 19% = 1 
   20 - 39% = 0 
   40 - 59% = 0 
   60 - 79% = 0 
   80 - 99% = 0 
 
    Index RDB$PRIMARY4 (0) 
   Depth: 1, leaf buckets: 1, nodes: 3 
   Average data length: 7.67, total dup: 0, max dup: 0 
   Fill distribution: 
        0 - 19% = 1 
       20 - 39% = 0 
       40 - 59% = 0 
       60 - 79% = 0 
       80 - 99% = 0 
 
SETTINGS (134) 
    Primary pointer page: 162, Index root page: 163 
    Data pages: 1, data page slots: 1, average fill: 4% 
    Fill distribution: 
    0 - 19% = 1 
   20 - 39% = 0 
   40 - 59% = 0 
   60 - 79% = 0 
   80 - 99% = 0 
 
    Index RDB$PRIMARY6 (0) 
   Depth: 1, leaf buckets: 1, nodes: 5 
   Average data length: 10.00, total dup: 0, max dup: 0 
   Fill distribution: 
        0 - 19% = 1 
       20 - 39% = 0 
       40 - 59% = 0 
       60 - 79% = 0 
       80 - 99% = 0 
 

Service ended at 10.01.2013 17:29:10

[Gruber_Hans_12345]

... also mir würde ein gleichbleiben oder langsames wachsen auch schon reichen.
Da eh jeden Tag die alten Datensätze gelöscht werden, würde es schon reichen, wenn die Datenbank nicht so extrem wachsen würde, sie muß eigetnlihc nicht kleiner werden, ein einmaligs Backup und Restore kann ich eh machen, aber danach sollte die dann nicht mehr wachsen

[DeddyH]

Soweit mir bekannt ist, machen das ziemlich alle bekannten DBMS so, dass gelöschte Datensätze intern zunächst nur als gelöscht markiert werden. Deshalb wird die DB nach dem Löschen auch nicht kleiner. Erst durch ein Backup und Restore werden sie dann tatsächlich entfernt. Aus diesem Grund wirst Du wohl leider nicht darum herum kommen (es sei denn, es gibt eine Art Shrink-Tool, das ich nicht kenne).

[tsteinmaurer]

Verkleinern ist nur mit einem Backup/Restore-Zyklus mit gbak möglich. Transaktions-Counter siehen gut aus und wenn man sich anhand deines gstat Output die DB-Größe überschlägt, dann ist man von deiner erwähnten DB-Größe sehr weit entfernt. Wäre interessant zu sehen, was bei gstat -v -i rauskommt.

Hast Du (String) BLOBs im Einsatz?

[IBExpert]

Zitat von Gruber_Hans_12345:

Ich habe einen Timer im Service drinnen, der jeden Tag die alten Daten rauslöscht, was auch gemacht wird

Versuche mal doppeltes löschen, d.h. jedes mal wenn du was löscht, die transaktion committen, danach
in einer neuen Transaktion den gleichen Löschbefehl noch mal absetzen und wieder committen.
Auf dem Weg bekommt der Garbage collector für die betroffenen Pages mit, das da Müll drin ist
und sollte die auch ohne erreichen des sweep intervals zeitnah aufräumen.

zeig doch am besten noch mal eine Datenbankstatistik mit gstat -r oder in IBExpert mit
der Checkbox oben angeklickt, damit man die Recordversionen sieht.

Gruß

Holger

[Gruber_Hans_12345]

Die gstat Resultate poste ich morgen

Ja ich verwende Blobs
und mir ist schon klar, das die DB nicht kleiner wird, mir würde schon reichen, das wenn ich jeden Tag die alten Records lösche und neue dazukommen, dieDB nicht so extrem wächst

Was mir eben komisch vorkommt, der SWEEP Intervall bezieht sich ja auf Transactionen oder?
und die 20000 sollte eigetnlich im nuh erreicht werden ... da jederLogeintrag in einer eigenen Transaktion abgesetzt wird, sollte das mindestens alle paar tage der fall sein
Daher wunderts mich warum die DB so groß ist

Also ist das definitiv so,das nach einem SWEEP alle Records und Blobs die ich mit DELETE gelöscht habe, freigegeben weden und derder Platz vom nächsten Record dann benutzt werden kann/darf?
Oder muss ich da noch etwas spezielles machen?

[tsteinmaurer]

Hallo,

ich hab mich verschrieben. Soll natürlich: gstat -r -i heißen.

Das Sweepintervall bezieht sich auf die Differenz zwischen Oldest Snapshot und Oldest Transaction. Wenn die Differenz > dem Sweepintervall ist, dann sollte ein Sweep automatisch angestoßen werden. Mit 2.5.2 bekommt man ein Sweep sehr einfach mit. So wird ein Sweep in firebird.log reingeloggt bzw. die Trace API mit log_sweep bringt hier noch mehr Transparenz rein.

Ein Sweep kann natürlich auch wieder nur mit den Datensatzversionen aufräumen, die von keiner Transaktion mehr benötigt werden. Somit ist ein Sweep am Effektivisten, wenn wenig bis gar nichts los ist auf der Datenbank. Darum geht man in der Regel auch so vor, dass man Sweepintervall auf 0 setzt (deaktiviert) und ein geplantes, manuelles Sweep mit gfix z.B. in der Nacht ausführt.

Die Frage wegen dem BLOB ist die, dass sich das massiv auf die DB Size auswirken kann, wenn man BLOBs z.B. in einer Schleife konkateniert. Oder ich denke die Verwendung von LIST auf einem BLOB ist ähnlich. Siehe hier: http://tracker.firebirdsql.org/browse/CORE-3948

[Gruber_Hans_12345]

Hmmm bei mir ist "oldest snapshot" und 2oldest transaction" fast immer gleich .... ?

Also in der DB werden immer nur datensätze per Insert eingefügt
also transaktion aufmachen INSERT Transaktion zu (das dauert also immer nur ganz ganz kurz)
das sagen wir mal so 5000-20000 pro Tag
und am ende des tages werden dann wieder so 4000-18000 Datensätze (alte) gelöscht

also bisschen darf die DB immer wachsen aber eben nicht so enorm, da läuft was schief ....

so das ist gstat -r -i

[edit] und falls man es nicht sieht, es geht hier NUR um die Tabelle LOG_ITEM alle anderen sind beinahe leer[/edit]

Code:

Database "d:\interbase\system.fdb"
Database header page information:
   Flags         0
   Checksum      12345
   Generation      71397630
   Page size      8192
   ODS version      11.2
   Oldest transaction   71396618
   Oldest active      71396619
   Oldest snapshot      71396619
   Next transaction   71396620
   Bumped transaction   1
   Sequence number      0
   Next attachment ID   998
   Implementation ID   26
   Shadow count      0
   Page buffers      4000
   Next header page   0
   Database dialect   3
   Creation date      Dec 4, 2011 16:35:43
   Attributes      force write

    Variable header data:
   Sweep interval:      20000
   *END*


Database file sequence:
File d:\interbase\system.fdb is the only file

Analyzing database pages ...
CLIENT_LOG (135)
    Primary pointer page: 164, Index root page: 165
    Average record length: 63.64, total records: 16180
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 207, data page slots: 207, average fill: 77%
    Fill distribution:
    0 - 19% = 0
   20 - 39% = 1
   40 - 59% = 0
   60 - 79% = 206
   80 - 99% = 0

    Index RDB$PRIMARY7 (0)
   Depth: 2, leaf buckets: 10, nodes: 16180
   Average data length: 1.00, total dup: 0, max dup: 0
   Fill distribution:
        0 - 19% = 0
       20 - 39% = 0
       40 - 59% = 0
       60 - 79% = 0
       80 - 99% = 10

LOG_ITEM (128)
    Primary pointer page: 150, Index root page: 151
    Average record length: 97.36, total records: 523953
    Average version length: 161.97, total versions: 37, max versions: 1
    Data pages: 11451, data page slots: 165710, average fill: 67%
    Fill distribution:
    0 - 19% = 2235
   20 - 39% = 160
   40 - 59% = 86
   60 - 79% = 4394
   80 - 99% = 4576

    Index LOG_ITEM_DATUM (2)
   Depth: 3, leaf buckets: 558, nodes: 523953
   Average data length: 2.09, total dup: 12398, max dup: 1
   Fill distribution:
        0 - 19% = 2
       20 - 39% = 12
       40 - 59% = 22
       60 - 79% = 38
       80 - 99% = 484

    Index LOG_ITEM_MODUL (1)
   Depth: 3, leaf buckets: 553, nodes: 523953
   Average data length: 0.00, total dup: 523839, max dup: 268780
   Fill distribution:
        0 - 19% = 0
       20 - 39% = 13
       40 - 59% = 443
       60 - 79% = 10
       80 - 99% = 87

    Index RDB$PRIMARY1 (0)
   Depth: 3, leaf buckets: 432, nodes: 523953
   Average data length: 1.09, total dup: 0, max dup: 0
   Fill distribution:
        0 - 19% = 3
       20 - 39% = 18
       40 - 59% = 15
       60 - 79% = 28
       80 - 99% = 368

LOG_MODUL (129)
    Primary pointer page: 152, Index root page: 153
    Average record length: 42.85, total records: 486
    Average version length: 9.00, total versions: 485, max versions: 1
    Data pages: 8, data page slots: 22, average fill: 67%
    Fill distribution:
    0 - 19% = 2
   20 - 39% = 1
   40 - 59% = 0
   60 - 79% = 0
   80 - 99% = 5

LOG_PRIORITY (130)
    Primary pointer page: 154, Index root page: 155
    Average record length: 0.00, total records: 0
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 0, data page slots: 0, average fill: 0%
    Fill distribution:
    0 - 19% = 0
   20 - 39% = 0
   40 - 59% = 0
   60 - 79% = 0
   80 - 99% = 0

    Index RDB$PRIMARY2 (0)
   Depth: 1, leaf buckets: 1, nodes: 0
   Average data length: 0.00, total dup: 0, max dup: 0
   Fill distribution:
        0 - 19% = 1
       20 - 39% = 0
       40 - 59% = 0
       60 - 79% = 0
       80 - 99% = 0

LOG_PRUNE (132)
    Primary pointer page: 158, Index root page: 159
    Average record length: 38.54, total records: 13
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 1, data page slots: 1, average fill: 9%
    Fill distribution:
    0 - 19% = 1
   20 - 39% = 0
   40 - 59% = 0
   60 - 79% = 0
   80 - 99% = 0

    Index RDB$PRIMARY3 (0)
   Depth: 1, leaf buckets: 1, nodes: 13
   Average data length: 1.08, total dup: 0, max dup: 0
   Fill distribution:
        0 - 19% = 1
       20 - 39% = 0
       40 - 59% = 0
       60 - 79% = 0
       80 - 99% = 0

LOG_SEND_SUPPORT (133)
    Primary pointer page: 160, Index root page: 161
    Average record length: 30.00, total records: 5
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 1, data page slots: 1, average fill: 3%
    Fill distribution:
    0 - 19% = 1
   20 - 39% = 0
   40 - 59% = 0
   60 - 79% = 0
   80 - 99% = 0

    Index RDB$PRIMARY5 (0)
   Depth: 1, leaf buckets: 1, nodes: 5
   Average data length: 1.20, total dup: 0, max dup: 0
   Fill distribution:
        0 - 19% = 1
       20 - 39% = 0
       40 - 59% = 0
       60 - 79% = 0
       80 - 99% = 0

LOG_SETTINGS (131)
    Primary pointer page: 156, Index root page: 157
    Average record length: 44.33, total records: 3
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 1, data page slots: 1, average fill: 2%
    Fill distribution:
    0 - 19% = 1
   20 - 39% = 0
   40 - 59% = 0
   60 - 79% = 0
   80 - 99% = 0

    Index RDB$PRIMARY4 (0)
   Depth: 1, leaf buckets: 1, nodes: 3
   Average data length: 7.67, total dup: 0, max dup: 0
   Fill distribution:
        0 - 19% = 1
       20 - 39% = 0
       40 - 59% = 0
       60 - 79% = 0
       80 - 99% = 0

SETTINGS (134)
    Primary pointer page: 162, Index root page: 163
    Average record length: 45.80, total records: 5
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 1, data page slots: 1, average fill: 4%
    Fill distribution:
    0 - 19% = 1
   20 - 39% = 0
   40 - 59% = 0
   60 - 79% = 0
   80 - 99% = 0

    Index RDB$PRIMARY6 (0)
   Depth: 1, leaf buckets: 1, nodes: 5
   Average data length: 10.00, total dup: 0, max dup: 0
   Fill distribution:
        0 - 19% = 1
       20 - 39% = 0
       40 - 59% = 0
       60 - 79% = 0
       80 - 99% = 0