Bereinigung; Datenbank
Verfasst: Mi 28. Apr 2021, 17:54
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:
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:
Bin ich einfach zu "ungeduldig" oder gibt es ggf. eine andere Möglichkeit die DB zu "bereinigen"?
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
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*