DB2 Universal Database - Systemverwaltung


Verwalten des Datenbankpufferpools

Ein Pufferpool ist ein Speicherbereich, in den Datenbankseiten (mit Tabellenzeilen oder Indexeinträgen) temporär eingelesen und geändert werden. Zweck des Pufferpools ist die Verbesserung der Leistung des Datenbanksystems. Auf Daten im Hauptspeicher kann wesentlich schneller zugegriffen werden als auf Daten auf einer Platte. Daher ist die Leistung umso höher, je seltener der Datenbankmanager Daten von der Platte lesen bzw. auf Platte schreiben muß.

Die Konfiguration eines oder mehrerer Pufferpools ist der wichtigste Einzelbereich bei der Optimierung, da hier die meisten Datenoperationen, abgesehen von Operationen mit großen Objekten (LOB) und Langfeldern (LONG), für Anwendungen durchgeführt werden, die mit der Datenbank verbunden sind.

Wenn eine Anwendung auf eine Zeile einer Tabelle zum ersten Mal zugreift, liest der Datenbankmanager die Seite, die die Zeile enthält, in den Pufferpool ein. Wenn in der Folge eine Anwendung Daten anfordert, wird zuerst der Pufferpool nach den angeforderten Daten durchsucht. Werden die angeforderten Daten auf Seiten, die sich im Pufferpool befinden, gefunden, braucht der Datenbankmanager diese Daten nicht vom Plattenspeicher abzurufen. Durch Vermeidung von Datenabrufen vom Plattenspeicher wird eine schnellere Verarbeitungsleistung erzielt.

Der Speicherbereich für den Pufferpool wird zugeordnet, wenn eine Datenbank aktiviert wird oder wenn die erste Anwendung die Verbindung zur Datenbank herstellt. Anwendungen sind die Hauptnutznießer des Pufferpools. Wenn alle Anwendungen getrennt sind, wird der Speicherbereich für den Pufferpool wieder freigegeben.

Seiten verbleiben im Pufferpool, bis die Datenbank gestoppt wird oder der von einer Seite belegte Speicherbereich im Pufferpool für eine andere Seite benötigt wird. Die Auswahl des Bereichs, der im Pufferpool zum Einlesen einer anderen Seite ausgesucht wird, richtet sich nach Kriterien wie den folgenden:

Anmerkung:Nachdem geänderte Seiten auf Platte geschrieben wurden, werden sie nicht aus dem Pufferpool entfernt, sofern nicht der Speicherbereich, den sie belegen, von anderen Seiten benötigt wird. Bis zu ihrer Überschreibung kann auf die Seiten immer wieder zugegriffen werden, wenn die Daten benötigt werden.

Beim Erstellen eines Pufferpools wird standardmäßig eine Seitengröße von 4 KB verwendet. Sie können die Seitengröße beim Erstellen des Pufferpools aber auf 4 KB, 8 KB, 16 KB oder 32 KB setzen. Wenn Pufferpools mit einer bestimmten Seitengröße erstellt werden, können ihnen nur Tabellenbereiche zugeordnet werden, die mit einer identischen Seitengröße erstellt wurden. Die Seitengröße des Pufferpools kann nach seiner Erstellung nicht mehr geändert werden.

Seiten im Pufferpool können verschiedene Attribute haben:

Seiten können aus dem Pufferpool auf Platte geschrieben werden, wenn der Prozentsatz für den Bereich, der von geänderten Seiten im Pufferpool belegt wird, den Wert, der für den Konfigurationsparameter chngpgs_thresh angegeben ist, überschreitet. Außerdem müssen Sie eventuell die Datenbank so konfigurieren, daß sie über mehr als einen Agenten für eine Seitenlöschfunktion verfügt. Diese Agenten schreiben geänderte Seiten auf Platte, so daß die Datenbankagenten verwendbaren Speicherbereich im Pufferpool vorfinden.

Agenten von Seitenlöschfunktionen führen E/A-Operationen durch, die ansonsten von den Datenbankagenten durchgeführt werden müssen. Dadurch können die Anwendungen schneller ausgeführt werden, weil Transaktionen nicht warten müssen, während ihre Datenbankagenten Seiten auf Platte schreiben. (Agenten für Seitenlöschfunktionen können auch als asynchrone Seitenlöschfunktionen oder asynchrone Funktionen zum Auslagern von Pufferseiten bezeichnet werden, da sie parallel zu Datenbankagenten aktiv sein können.)

Zum Ändern der Anzahl der Agenten für Seitenlöschfunktionen wird der Konfigurationsparameter num_iocleaners verwendet (standardmäßig wird ein Agent für Seitenlöschfunktionen erstellt). Weitere Informationen hierzu finden Sie im Abschnitt Anzahl asynchroner Seitenlöschfunktionen (num_iocleaners). Legen Sie diesen Parameter auf einen Wert zwischen eins und der Zahl der physischen Platten in der Datenbank fest. Je größer diese Zahl ist, desto besser wird die Leistung bei der Ausführung von Auslastungen, die aufwendige Aktualisierungen erfordern. Dies trifft auch zu, wenn es eine große Zahl von Schreiboperationen für Daten oder Indexseiten in bezug auf die Zahl der asynchronen Schreiboperationen für Daten oder Indexseiten gibt.

Das Schreiben von Seiten auf Platte ermöglicht eine schnellere Wiederherstellung der Datenbank im Falle eines Systemabsturzes, da der Datenbankmanager in der Lage ist, größere Bereiche des Pufferpools von der Platte ohne Zuhilfenahme der Datenbankprotokolldateien wiederherzustellen. Infolgedessen wird die Seitenlöschfunktion angefordert, wenn die Größe des Protokolls, das während der Wiederherstellung gelesen werden müßte, den folgenden Maximalwert überschreitet:

   logfilsiz * softmax

Dabei gilt folgendes:

Mit dem Datenbanksystemmonitor können Sie die Anzahl von Anforderungen zum Seitenlöschen verfolgen, um die Zeit, die das Protokoll während einer Wiederherstellung gelesen wird, zu minimieren. Weitere Informationen finden Sie in der Beschreibung des Monitorelements pool_lsn_gap_clns (für Pufferpoolprotokollbereich ausgelöste Seitenlöschfunktionen) im Handbuch System Monitor Guide and Reference.

Die Größe des Protokolls, das während der Wiederherstellung gelesen werden müßte, errechnet sich aus der Differenz der Positionen der folgenden Sätze im Protokoll:

Die folgende Abbildung veranschaulicht, wie die Arbeit zur Verwaltung des Pufferpools zwischen den Agenten für die Seitenlöschfunktionen und den Datenbankagenten aufgeteilt werden kann im Vergleich zu der Situation, in der die Datenbankagenten die gesamte Ein-/Ausgabe selbst durchführen.

Abbildung 92. Asynchrone Seitenlöschfunktion. Benutzte Seiten werden auf Platte geschrieben.

SQLD0CLN


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]