Bereinigung; Datenbank

[Smith]

Hallo zusammen.

Ich habe folgendes Problem:

Ein Kunde beschwerte sich darüber, dass der Zugriff auf seine Firebird Datenbank sehr langsam ist (Firebird in der Version 2.5).

Nach kurzer Zeit habe ich festgestellt, dass die Datenbank größer ist als erwartet.

Aktuell hat die Datenbank eine Größe von 23.5 GB, vor einem Monat lag diese noch bei ca. 8 GB.

Ebenfalls wurde vor ca. einem Monat das abendliche Backup der Datenbank deaktiviert.

Wenn ich es richtig verstanden habe, wird bei der Erstellung eines Backups automatisch der Sweep, also die Bereinigung der Datenbank von Altdaten durchgeführt.

Also denke ich mir, dass die Zunahme an notwendigem Speicher mit dem fehlenden Backup zusammenhängt.

Um das Problem zu beheben, wollte ich erst ein Backup durchführen (und anschließend wieder einspielen), mit dem Ergebnis, dass dieses auch nach 8 Stunden an der gleichen Stelle im Log stand und ich dieses abgebrochen habe.

Auch die Durchführung eines manuellen Sweeps via gfix kam nach mehreren Stunden zu keiner Rückmeldung.

Dar das alles zu nichts geführt hat, habe ich die Tabellen via gstat analysiert und habe unter anderem die folgende Tabelle gefunden:

Code: Alles auswählen

RP$_3000_LOGIN (570)
    Primary pointer page: 1312, Index root page: 1313
    Average record length: 0.00, total records: 57093911
    Average version length: 32.99, total versions: 57093854, max versions: 1
    Data pages: 261711, data page slots: 265463, average fill: 89%
    Fill distribution:
         0 - 19% = 3372
        20 - 39% = 0
        40 - 59% = 0
        60 - 79% = 0
        80 - 99% = 258339

    Index RDB$PRIMARY5114 (0)
        Depth: 3, leaf buckets: 29086, nodes: 57094827
        Average data length: 0.01, total dup: 56922728, max dup: 334
        Fill distribution:
             0 - 19% = 120
            20 - 39% = 0
            40 - 59% = 5057
            60 - 79% = 20408
            80 - 99% = 3501

Die Inhalte der Tabelle sind nicht "relevant" und können theoretisch gelöscht werden.

Jedoch wird auch der Lösch-Befehl auf die Tabellen-Inhalte nach mehrstündigen Warten nicht durchgeführt.

Hier auch die Header Page Infos:

Code: Alles auswählen

Database header page information:
        Flags                   0
        Checksum                12345
        Generation              3566779
        Page size               16384
        ODS version             11.2
        Oldest transaction      3445146
        Oldest active           3504727
        Oldest snapshot         3504727
        Next transaction        3504729
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      65337
        Implementation ID       16
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Apr 14, 2019 7:47:42
        Attributes              force write

    Variable header data:
        Sweep interval:         20000
        *END*

Bin ich einfach zu "ungeduldig" oder gibt es ggf. eine andere Möglichkeit die DB zu "bereinigen"?

[bfuerchau]

Das Problem habe ich leider auch ab und zu. Da geht kein Backup, gfix o.ä.
Das Einzige was dann wirklich hilft, ist ein Repikator, der den Inhalt Tabelle für Tabelle, Zeile für Zeile kopiert und eine neue DB erstellt. Der Datenteil der Tabellen geht am seltensten kaputt.
FBCopy kann das u.U. gewährleisten. Je nach Umfang der Tabellen ist das halt ein wenig Scriptarbeit.
Ich habe für solcche Zwecke mal ein FTReplicate (für unsere FTIS-Datenbank) entwickelt. Allerdings supportet dieses Tool nicht alle Feldarten.
Es ist allerdings ziemlich simpel.
Die DDL der Tabellen, Views, Trigger u.co. lassen sich z.B. via IBExpert extrahieren und in eine neue DB anwenden. Den zeilenweisen Copy kann man da auch schnell bauen.

[Smith]

Vielen Dank für den Tipp mit dem FBCopy.

Es ist zwar mit Arbeit verbunden, aber so konnte ich die Datenbank wieder zum laufen bringen.

[bfuerchau]

Deshalb machen wir ja auch für die Bereinigung 1x wöchentlich einen backup/restore um die DB zu bereinigen.
Allerdings ist es bei uns auch so, dass zur Laufzeit viele Tabellen entstehen und wieder gelöscht werden was die FB2.5 ab und an durcheinander bringt.
In FB3 ist das u.U. nicht mehr so häufig nötig, da das Transaktionshandling bzgl. der Satzversionen entscheidend verbessert wurde und der Transaktionsbereich da besser reorganisiert wird.

Ein weiteres Problem stellt die Sicherung einer VM dar, da die FB keinen VSS-Writer hat. Wenn die VM gesichert werden muss, muss man
a) entweder den FB-Dienst beenden und hinterher wieder starten
b) oder die VM runterfahren.

Im Installationsverzeichnis steht übrigens auch noch eine Firebird.log, die frühzeitig auf DB-Probleme hinweist. Außerdem gehört diese regelmäßig gelöscht was sich nicht von alleine tut. Die Größe der Log-Datei kann dann auch schon mal größer als die DB werden und das Anfügen an die Logdatei dauert dann auch, was die Gesamtperformance durchaus beeinträchtigt.

Einen Parameter für die regelmäßige Löschung oder Größenbeschränkung habe ich bis heute noch nicht gefunden.