Firebird 2.0 Garbage Collector

Engine kennt jede Record-Version, die durch UPDATE/DELETE-Anweisungen erzeugt wurde, und kann diese entfernen, sobald die älteste Snapshot-Transaktion (OST) dies erlaubt. Dadurch entfällt die Notwendigkeit, diese Versionen bei Benutzeranfragen erneut zu lesen (z. B. SELECT COUNT(*) FROM table), und es wird vermieden, dass diese Versionen nie gelesen werden (natürlich hat Sweep immer alle ungenutzten Record-Versionen entfernt). Außerdem ist die Wahrscheinlichkeit hoch, dass benötigte Seiten noch im Buffer-Cache liegen, sodass weniger zusätzliche Disk-I/O erforderlich ist.

Zwischen der Benachrichtigung des Garbage Collectors über eine Seite mit ungenutzten Versionen und dem Zeitpunkt, zu dem der Garbage Collector diese Seite liest, kann eine neue Transaktion einen Record aktualisieren, und der Garbage Collector kann diesen Record nicht bereinigen, wenn die Transaktionsnummer über der OST liegt oder noch aktiv ist. In diesem Fall benachrichtigt der Engine den Garbage Collector erneut mit dieser Seitennummer, und dieser räumt den Garbage zu einem späteren Zeitpunkt auf (der alte Garbage Collector “vergisst” diese Seite, bis der Benutzer sie erneut liest).

Sowohl kooperative als auch Hintergrund-Garbage-Collection sind nun möglich. Zur Verwaltung wurde der neue Konfigurationsparameter “GCPolicy” eingeführt. Er kann wie folgt gesetzt werden:

a) kooperativ - Garbage Collection wird nur im kooperativen Modus durchgeführt, wie vor IB6. Jede Benutzeranfrage ist für das Entfernen ungenutzter Record-Versionen verantwortlich. So arbeitet der Engine vor IB6. Dies ist die einzige Option für den Classic-Server-Modus. Der Engine verfolgt keine Versionen, die durch UPDATE- und DELETE-Anweisungen erzeugt wurden.
b) Hintergrund - Garbage Collection wird nur durch einen Hintergrund-Thread durchgeführt, wie in IB6 und später. Keine Benutzeranfragen entfernen ungenutzte Record-Versionen. Stattdessen benachrichtigt die Benutzeranfrage einen dedizierten Garbage-Collector-Thread mit der Seitennummer, auf der eine ungenutzte Record-Version erkannt wurde. Außerdem merkt sich der Engine Seitennummern, auf denen UPDATE/DELETE-Anweisungen Back-Versionen erzeugt haben.
c) kombiniert - sowohl Hintergrund- als auch kooperative Garbage Collection werden durchgeführt.

Standard ist “kombiniert” für SuperServer. ClassicServer ignoriert diesen Parameter und arbeitet immer im “kooperativen” Modus.