Firebird Backup-Wiederherstellung ist frustrierend, gibt es eine Möglichkeit, es zu vermeiden?

7

Ich benutze Firebird, aber in letzter Zeit wird die Datenbank wirklich ernst. Es werden sehr viele Löschanweisungen ausgeführt, auch update / insert, und die Größe der Datenbankdatei wächst sehr schnell. Nach Tonnen von Löschen von Datensätzen sinkt die Datenbankgröße nicht, und noch schlimmer, ich habe das Gefühl, dass die Abfrage tatsächlich etwas verlangsamt wird. Um dies zu beheben, war ein täglicher Backup / Restore-Prozess involviert, aber wegen der Zeit, um es zu beenden - ich könnte sagen, dass es wirklich frustrierend ist, Firebird zu benutzen.

  • Irgendwelche Ideen zu Problemumgehungen oder Lösungen dazu sind willkommen.

  • Ich überlege auch, zu Interbase zu wechseln, weil ich von einem Freund gehört habe, dass es dieses Problem nicht hat - es ist so?

Yordan Yanakiev 03.06.2011, 08:32
quelle

3 Antworten

9

Wir haben eine Menge großer Datenbanken über Firebird in der Produktion, aber nie ein Problem mit einem Datenbankwachstum. Ja, jedes Mal, wenn ein Datensatz gelöscht oder aktualisiert wird, wird eine alte Version in der Datei gespeichert. Aber früher oder später wird ein Müllsammler es vertreiben. Sobald sich beide Prozesse gegenseitig ausgleichen, wächst die Datenbankdatei nur für die Größe neuer Daten und Indizes.

Als allgemeine Vorsichtsmaßnahme, um ein enormes Datenbankwachstum zu vermeiden, versuchen Sie, Ihre Transaktionen so kurz wie möglich zu gestalten. In unseren Anwendungen verwenden wir eine READ ONLY-Transaktion zum Lesen aller Daten. Diese Transaktion ist während der gesamten Anwendungslebensdauer geöffnet. Für jeden Stapel von Einfüge- / Aktualisierungs- / Löschanweisungen verwenden wir kurze separate Transaktionen.

Die Verlangsamung der Datenbankoperationen könnte auf veraltete Indexstatistiken zurückzuführen sein. Hier finden Sie ein Beispiel für die Neuberechnung von Statistiken für alle Indizes: Ссылка

    
Andrej Kirejeŭ 03.06.2011, 09:55
quelle
7

Überprüfen Sie, ob in Ihren Anwendungen noch nicht abgeschlossene Transaktionen vorliegen. Wenn die Transaktion gestartet, aber nicht festgeschrieben oder zurückgesetzt wird, hat die Datenbank für jede Transaktion nach der ältesten aktiven Transaktion eine eigene Revision.

Sie können die Datenbankstatistik (gstat oder externes Tool) überprüfen, es gibt die älteste Transaktion und die nächste Transaktion. Wenn der Unterschied zwischen diesen Zahlen weiter wächst, haben Sie das festgefahrene Transaktionsproblem.

Es gibt auch Überwachungs-Tools die Prüfsituation, eine, die ich verwendet habe, ist Sinatica Monitor für Firebird.

Bearbeiten: Außerdem wird die Datenbankdatei nicht automatisch verkleinert. Teile davon werden nach dem Sweep-Vorgang als unbenutzt markiert und wiederverwendet. Ссылка

    
Harriv 03.06.2011 09:28
quelle
6

Der von gelöschten Datensätzen belegte Speicherplatz wird wiederverwendet, sobald er von Firebird entsorgt wird. Wenn GC nicht auftritt (Transaktionsprobleme?), Wird die DB weiter wachsen, bis GC seine Arbeit machen kann.

Außerdem gibt es ein Problem, wenn Sie eine massive Löschung in einer Tabelle vornehmen (zB: Millionen von Datensätzen), die nächste Auswahl in dieser Tabelle wird die Speicherbereinigung auslösen und die Leistung wird fallen, bis GC beendet ist. Die einzige Möglichkeit, dies zu umgehen, wäre, die massiven Löschungen in einer Zeit durchzuführen, in der der Server nicht sehr ausgelastet ist, und danach einen Sweep auszuführen, um sicherzustellen, dass es keine festgefahrenen Transaktionen gibt.

Denken Sie auch daran, dass Sie in manchen Fällen eine beschädigte Datenbank erhalten, wenn Sie "Standard" -Tabellen verwenden, um temporäre Daten zu speichern (dh, dass Informationen mehrmals eingefügt und gelöscht werden). Ich empfehle Ihnen dringend, die Funktion Globale temporäre Tabellen zu verwenden.

    
WarmBooter 05.06.2011 00:38
quelle