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:

Zitat von Gruber_Hans_12345 (Beitrag 1198512)

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

[tsteinmaurer]

An alten Datensatzversionen kann es nicht liegen. Ich würde das Thema der BLOB-Verwendung weiterverfolgen.

[Gruber_Hans_12345]

was meisnt genau mit der BLOB Verwendung?

Wie gesagt ich mahce nur einmal ein INSERT rein, dabei gibt es datensätze mit BLOB und manche ohne BLOB

aber es wird niemals ein Update oder so gemacht in dieser Tabelle.

Aber bedeutet das was das "oldest snapshot" und "oldest transaction" bei mir auf den selben Wert sind?

[tsteinmaurer]

Dass deine Transaction-Counter knapp beisammen liegen ist gut. Sagt dir im Wesentlichen, dass das Transaktionsmanagement im Client paßt.

Bzgl. BLOB. Du wirst ja auch etwas mit den Daten machen. Wirst ja nicht nur reinschreiben oder? Ich dachte hier z.B. eine Stored Procedure, Trigger oder EXECUTE BLOCK, die über die Log-Tabelle irgendwie drüberiteriert, den BLOB Inhalt in der Schleife konkateniert etc.

Du mußt uns etwas mehr sagen, was mit den Daten nach der Speicherung gemacht wird. Aus den Statistiken kann man die DB-Größe nicht erklären.

[Gruber_Hans_12345]

Also die Daten werden geloggt und dann ab und zu angesehen und dann gelöscht.
Die werden zu keinen zeitpunkt per UPDATE manipuliert .. (zumindest diese LOG_ITEM nicht) aber die anderen Tabellen sind vernachlässigbar

In die Blob Felder kommt ein BugReport rein, falls es sich beim Log um einen Error Log handelt.

und je nach Priorität und von welchen Modul diese Logging Einträge kommen, werden diese Records früher oder später gelöscht.

Zurzeit sind in der Tablle LOG_ITEM 546.106 Einträge drinnen, der Generator steht aber bereits schon auf 99.542.392 also ist sind in summe schon fast 100 Millionen datensätze eingefügt worden, und fast alle wieder gelöscht worden, bis eben auf diese halbe million.

[tsteinmaurer]

Die Differenz zwischen "data pages" und "data page slots" für die Tabelle LOG_ITEM ist interessant, weil es ein Indiz dafür ist, dass Garbage nicht weggeräumt werden konnte. Hast jetzt schon einmal ein manuell angestoßenes Sweep laufen lassen?

Wenn man die restored DB Size von 17 GB und die ca. 550.000 hernimmt, dann kommt auf so ca. 32KB pro Datensatz, was womöglich plausibel ist.

Da ja das DB-File nie automatisch verkleinert wird, könnte es auch einfach sein, dass bei einem großen Batch-Import mal die DB auf die dafür benötigte Größe angewachsen ist?

D.h. du hast nichts (Stored Procedure, Trigger, etc.) womit der BLOB Inhalt irgendwie weiterverarbeitet wird?

[Gruber_Hans_12345]

nein ich verwende weder Trigger noch Stored Procedure

Ich habe nun mal ein komplettes Backup und Restore durchgeführt nun ist die DB mit den 550.000 Records gerade mal 1.24GB groß

ich werde mal beobachten wie und was sich tut die nächsten tage

nun schaut das gstat auf alle fälle mal so aus

Code:

Database "d:\interbase\system.fdb"
Database header page information:
   Flags         0
   Checksum      12345
   Generation      41
   Page size      8192
   ODS version      11.2
   Oldest transaction   29
   Oldest active      30
   Oldest snapshot      30
   Next transaction   31
   Bumped transaction   1
   Sequence number      0
   Next attachment ID   3
   Implementation ID   26
   Shadow count      0
   Page buffers      4000
   Next header page   0
   Database dialect   3
   Creation date      Jan 11, 2013 15:28:32
   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: 16189
    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: 16189
   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: 99.59, total records: 563616
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 10082, data page slots: 10082, average fill: 83%
    Fill distribution:
    0 - 19% = 2
   20 - 39% = 6
   40 - 59% = 8
   60 - 79% = 4354
   80 - 99% = 5712

    Index LOG_ITEM_DATUM (2)
   Depth: 2, leaf buckets: 555, nodes: 563616
   Average data length: 2.08, total dup: 12801, max dup: 1
   Fill distribution:
        0 - 19% = 0
       20 - 39% = 0
       40 - 59% = 1
       60 - 79% = 0
       80 - 99% = 554

    Index LOG_ITEM_MODUL (1)
   Depth: 2, leaf buckets: 345, nodes: 563616
   Average data length: 0.00, total dup: 563502, max dup: 268784
   Fill distribution:
        0 - 19% = 0
       20 - 39% = 0
       40 - 59% = 4
       60 - 79% = 0
       80 - 99% = 341

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

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

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

[RWarnecke]

Was passiert, wenn gar kein Sweep Interval gesetzt ist ? Das habe ich noch nicht so richtig verstanden. Ich habe es zumindest soweit verstanden, dass der Sweep Interval irgendwas mit dem endgültigen Löschen der Datensätze zu tun hat.

[mkinzler]

Ein (Hintergrund-)Sweep löscht eigentlich nicht, sondern gibt nur nicht mehr benötigte Versionen von Datensätze frei, welche dann bei einem manuellen Sweep ( z.B. Backup/Restore Zyklen) entfernt werden oder deren Platz von anderen Datensatzversionen eingenommen werden kann.