Garbage collection

<< Fremdschlüssel | IBExpert Glossar | Generator >>

(Speicherbereinigung)

Wenn Firebird/InterBase^® eine Garbage Collection ausführt, werden veraltete Datensätze und Index Dateien entfernt, was zu einer Verkleinerung der Datenbank führt. Veraltete Datensätze werden in Firebird/InterBase^® aus folgendem Grund gespeichert: Firebird/InterBase^® sind Multi-Generations-Datenbanken. Wenn ein Datensatz geändert wird, wird diese in der Datenbank als eine neue Kopie gespeichert. Die alten Werte bleiben in der Datenbank als eine Backversion für den Rollback Protokoll. Sollte die Transaktion nach dem Update mit einem Rollback rückgängig gemacht werden, nimmt der alte Wert seine Funktion als gültiger Wert wieder auf. Wenn die Transaktion allerdings committed wird, wird diese Backversion überflüssig. Bei Datenbanken mit vielen Updateoperationen kann es zu viel Garbage führen.

Wenn Garbage in Firebird/InterBase^® eingesammelt wird, werden nicht nur veraltete Updatewerte gelöscht, sondern - basiert auf der Transaction Inventory Page (TIP) Information - alle veralteten und gelöschten Datensatzversionen.

Eine Garbage Collection wird nur während einer Datenbanksweep, Datenbankbackup oder wenn eine SELECT-Abfrage auf einer Tabelle (und nicht INSERT, ALTER oder DELETE) durchgeführt wird. Jedes Mal wenn Firebird/InterBase^® eine Zeile berührt, wie zum Beispiel bei einem SELECT, fegt die Versioning-Engine alle Versionen der Zeile, wo die Transaktionsnummer älter ist als die Oldest Interesting Transaction (OIT) (älteste interessante Transaktion) weg. Diese Funktion hilft, die Versionshistorie klein und übersichtlich zu halten und die Leistung zu optimieren.

Das Sweepintervall (d.h. wie oft (in Anzahl Transaktionen) eine Datenbanksweep automatisch durchgeführt werden soll) für die Garbage Collection wird im IBExpert Dienste Menü Datenbankeigenschaften festgelegt.

Die Garbage Collection ist kooperativ, d.h. statt ein dediziertes Garbage-Team nehmen alle Transaktionen daran teil. Alte Versionen, gelöschte Datensätze und rolled-back Updates werden entfernt, jedes Mal wenn eine Transaktion versucht den Datensatz zu lesen. In einer Datenbank, wo alle Rekorde stets aktiv sind, oder wo vollständige Abfragen (d.h. nicht indizierte Zugriffe) regelmäßig an allen Tabellen durchgeführt werden, funktioniert kooperative Garbage Collection einwandfrei, so lange die Transaktionsmaske aktuell bleibt.

Bei Datenbanken mit indizierten Zugriffen, werden alte Datensätze selten - oder nie - mehrere Male besucht, also werden sie selten - oder nie - bereinigt. Eine regelmäßige Datensicherung mit gbak hat die sekundären Auswirkung, Garbage Collection zu zwingen, da gbak vollständige Abfragen an alle Tabellen durchführt.

Die Garbage Collection kann problemlos auch bei 24 Stunden Onlineoperation durchgeführt werden (d.h. Der Server muss nicht heruntergefahren werden). Die Leistung könnte allerdings durch den Sweep fallen, was nicht immer wünschenswert ist. Wenn das Sweepintervall auf Null (0) gesetzt wird (siehe Datenbankeigenschaften), wird die Garbage Collection überhaupt nicht automatisch ausgeführt. Man könnte dann, zum Beispiel, den Sweep oder einen Backup nachts mit dem GFIX-Tool ? und den at Windowsbefehl oder den Linux chron-Befehl ausführen.

Neu in Firebird 2.0: Superserver Garbage Collection Änderungen

Früher führte der Firebird Superserver nur Garbage Collection im Hintergrund aus. Im Gegensatz dazu, leistet Classic "kooperative" Garbage Collection, wo mehrere Verbindungen den Leistungsabfall während der Garbage Collection auffangen. Nun ist Superservers Standardverhalten für Garbage Collection eine Kombination der kooperative und Hintergrundmodi. Das neue Defaultverhalten garantiert in der Regel eine bessere Gesamtleistung, da die Garbage Collection online ausgeführt wird, was das Wachstum der Versionsketten bei hoher Belastung mindert.

Es bedeutet, dass einige Abfragen bei der Datenrückgabe langsamer sein können, wenn das Volumen der alten Rekordversionen in den betroffenen Tabellen besonders hoch ist. Datenbanken mit einer ODS 10 und niedriger, wo die Garbage Collection auf Indizes ineffectiv ist, sind für dieses Problem besonders anfällig. Mit dem GCPolicy Parameter in firebird.conf kann das alte Verhalten wieder eingestellt werden, sollte Ihre Datenbank unter diesem Problem leiden.

Seit Firebird 2.1 ihre virtuelle System- MON$-Tabellen einführte, weist das MON$GARBAGE_COLLECTION-Feld in der MON$ATTACHMENTS-Tabelle darauf hin, ob die Garbage Collection für eine bestimmte Verbindung (wie in dem DPB in isc_attach_database) erlaubt ist. Weitere Information finden Sie im Firebird 2.1 Release Notes Kapitel, Administrative features.

Firebird's Database housekeeping and garbage collection documentation includes the following definitions:

Siehe auch:

Woher weißt man, ob die Garbage Collection funktioniert? englischsprachig:
Firebird Database Housekeeping Utility: Database housekeeping and garbage collection
Garbage collectors
Firebird administration using IBExpert: Garbage collection
Firebird for the database expert: episode 4 - OAT, OIT and sweep: Garbage
Firebird 2.1.3 Release Notes: Garbage collector rationalisation
Forced writes
Multi-generational architecture and record versioning