Pufferpool

Der Pufferpool ist der Pufferspeicher eines Datenbankmanagementsystems (DBMS). Häufig verwendete Teile einer Datenbank werden im Arbeitsspeicher zwischengelagert. Dadurch kann die Anzahl langsamer Zugriffe auf die Festplatte reduziert werden.

Konzept des Pufferpools

Der Pufferpool ist ein Cache der Teile einer Datenbank im Arbeitsspeicher zwischen lagert. Dabei werden die Lokalitätseigenschaften der Prozesse ausgenutzt welche auf die Datenbank zugreifen. Die Geschwindigkeit kann so gegenüber dem direkten Festplattenzugriff deutlich gesteigert werden.

Funktionsweise

Ein DBMS verwaltet die Informationen der Datenbank in Dateneinheiten fester Größe. Diese werden als Seiten oder Pages bezeichnet. In einer Seite könnten z.B. mehrere Zeilen einer Tabelle enthalten sein. Auf dem Festspeicher werden Daten blockweise gespeichert. Die Größe einer Seite ist meist ein vielfaches der Größe eines Datenblockes der Festplatte.

Die Verdrängungsstrategie entscheidet welche Seite im Pufferpool ersetzt wird, falls eine Seite von der Festplatte in den Pufferpool geladen werden soll. In der Regel kommt LRU (Least Recently Used) zum Einsatz.

Anforderungen an den Pufferpool

Die vier ACID-Eigenschaften definieren die Anforderungen an Transaktionen. Insbesondere die beiden Eigenschaften Atomarität und Dauerhaftigkeit haben Auswirkungen auf den Pufferpool. Die Isolation ist nicht Aufgabe des Pufferpools. Diese muss über Locking-Algorithmen erreicht werden.

Bei dem Betrieb eines DBMS können viele Probleme auftreten welche dazu führen, dass der Arbeitsspeicher verloren geht. So zum Beispiel Ausfälle der Stromversorgung, defekte Computerkomponenten, Softwarefehler, etc. Geht der Arbeitsspeicher verloren, so verliert man den Pufferpool und insbesondere all jene Seiten, welche verändert, aber noch nicht zurück auf die Festplatte geschrieben wurden.

Gehörten diese Daten zu einer erfolgreich beendeten Transaktion, ist die ACID-Anforderung der Dauerhaftigkeit nicht erfüllt. Des Weiteren darf dabei die ACID-Eigenschaft der Atomarität nicht verletzt werden. Die Änderungen an der Datenbank von Transaktionen, welche zum Zeitpunkt des Ausfalls nicht erfolgreich abgeschlossen waren, müssen komplett Rückgängig gemacht werden können.

Verschiedene Pufferpool-Umsetzungen

Die Art wie ein Pufferpool umgesetzt wird kann sich von DBMS zu DBMS stark unterscheiden. Für einige Methoden und Strategien werden im Zusammenhang mit dem Pufferpool spezielle Begriffe eingesetzt.

Force / No-Force

Die Force-Methode ist eine einfache Methode um die Dauerhaftigkeit von Transaktionen zu gewährleisten. Dazu werden am Ende einer Transaktion (während des commit-Prozesses) alle Seiten, welche während der Transaktion verändert wurden, auf die Festplatte geschrieben. Die Verwendung der Force-Methode führt somit dazu dass für jede, Veränderungen vornehmende, Transaktion langsame Schreiboperationen notwendig sind.

Entsprechend gibt es die No-Force-Methode. Dabei müssen am Ende einer Transaktion keine Seiten auf die Festplatte geschrieben werden. Verändern mehrere Transaktionen dieselbe Seite, so muss diese nicht jedes mal gespeichert werden. Die Leistung des DBMS kann somit erhöht werden. Allerdings bietet No-Force keine garantierte Dauerhaftigkeit. Diese muss anderweitig sichergestellt werden.

Steal / No-Steal

Mit der No-Steal-Methode kann auf einfache Weise die Atomarität der Transaktionen gewährleistet werden. Solange die Transaktion noch aktiv ist, werden die veränderten Seiten der Transaktion nicht auf die Festplatte übertragen. Alle Veränderungen geschehen ausschließlich im Pufferpool. Bei einem Ausfall geht der Pufferpool verloren und die Veränderungen aller laufenden Transaktionen mit ihm. Dies kommt einem Rollback dieser Transaktionen gleich. Auf der Festplatte befinden sich somit nur Seiten vollständiger Transaktionen. Die Atomarität ist somit gewährleistet.

Die No-Steal-Methode hat den Nachteil, dass viele Seiten im Pufferpool blockiert sind. Denn wenn die Änderungen nicht auf die Festplatte übertragen werden dürfen, kann die Seite auch nicht aus dem Pufferpool entfernt werden, um einer anderen Seite Platz zu machen. Der Platz im Pufferpool kann dadurch schnell an seine Grenzen kommen. Die Menge der Daten, welche in einer Transaktion verändert werden kann, ist durch die Größe des Pufferpools beschränkt.

Die meisten Veränderungen müssen aber später sowieso in den Sekundärspeicher geschrieben werden, da Abbrüche von Transaktionen die Ausnahme darstellen. Diese Seiten im Pufferpool zu halten ist deshalb meistens unnötig. Entsprechend erlaubt die Steal-Methode Seiten laufender Transaktionen auf die Festplatte zu schreiben. Man stiehlt einer laufenden Transaktion sozusagen einen Platz im Pufferpool. Der Pufferpool kann dadurch effizienter genutzt werden. Die Atomarität ist aber nicht mehr gewährleistet und muss anders umgesetzt werden.

Kombinationen

In der Praxis wird meist die Kombinationen Force und No-Steal oder No-Force und Steal verwendet. Force und No-Steal ist einfach umzusetzen, erreicht aber nicht die Leistung von No-Force und Steal. Bei den großen DBMS Systemen wird aus diesem Grund meist No-Force und Steal verwendet, auch wenn dieses aufwendiger in der Entwicklung ist. Ein bekannter Algorithmus um die ACID-Eigenschaften trotz No-Force und Steal zu erhalten ist ARIES (Algorithms for Recovery and Isolation Exploiting Semantics). Dieser basiert auf einem Protokoll welches sowohl das Wiederherstellen als auch das Rückgängigmachen von Veränderungen ermöglicht, um nach einem Ausfall wieder einen den ACID-Eigenschaften entsprechenden Stand zu erhalten.

Konfiguration

Die meisten DBMS bieten Möglichkeiten den Pufferpool auf die eigenen Bedürfnisse anzupassen. Die wichtigste Option ist die Größe des Pufferpools. Je mehr Seiten er aufnehmen kann, desto schneller kann mit der Datenbank gearbeitet werden, allerdings steigt auch der Bedarf an Arbeitsspeicher.

Bei einigen DBMS können auch die Methoden zur Erhaltung der ACID-Eigenschaften manipuliert werden. Insbesondere Systeme welche die No-Force- und Steal-Methoden verwenden, bieten meistens eine Möglichkeit an um eine Datensicherung im laufenden Betrieb zu ermöglichen. Dabei werden die ACID-Eigenschaften auch erhalten wenn vom Festspeicher eine Kopie erstellt wird während das DBMS läuft. Dies wird als Hot-Backup bezeichnet.