Für den Umgang mit der Leistung der Datenbankoperationen für DB2 benötigen Sie ein Verständnis für die grundlegenden Konzepte, die mit der DB2-Architektur und den DB2-Prozessen in Zusammenhang stehen. Dieses Kapitel enthält ausreichende Informationen zur Arbeitsweise von DB2 Universal Database. Nachfolgende Kapitel bieten ausführlichere Einzelheiten zu einigen der hier dargestellten Themen, wobei jedoch die in diesem Kapitel enthaltenen Informationen den Kontext für das spätere Verständnis bieten.
Die erste Abbildung zeigt eine Übersicht zur Architektur und den Prozessen für DB2 UDB.
Abbildung 67. Übersicht zu Architektur und Prozessen
Auf der Client-Seite gibt es lokale und/oder ferne Anwendungen, die mit der DB2 Universal Database-Client-Bibliothek verbunden sind.
Zwischen den Clients und dem DB2 Universal Database-Server befindet sich eine "Wolke", die die Kommunikationsmittel zwischen den lokalen oder fernen Clients und dem Server darstellt. Lokale Clients kommunizieren mit Hilfe von gemeinsam benutztem Speicher und Semaphors; ferne Clients verwenden ein Protokoll wie beispielsweise "Benannte Pipes" (Named Pipes, NPIPE), TCP/IP, NetBIOS, IPX/SPX oder SNA.
Auf der Server-Seite wird die Aktivität durch EDUs (Engine Dispatchable Units, zuteilbare Einheiten der Steuerkomponente) gesteuert. In allen Abbildungen in diesem Kapitel werden EDUs als Kreise oder Gruppen von Kreisen dargestellt. EDUs werden unter Windows NT und unter OS/2 als Threads (alle in einem einzigen Prozeß) und unter UNIX als Prozesse implementiert. Die am weitesten verbreitete Art von EDUs sind DB2-Agenten. Diese EDUs führen den Großteil der SQL-Verarbeitung für Anwendungen durch. Andere Beispiele für EDUs sind die DB2-Vorablesezugriffe und -Seitenlöschfunktionen, die für verschiedene Arten von E/A-Verarbeitung verantwortlich sind. Weitere Informationen finden Sie im Abschnitt Datenbankagenten.
Jede Client-Anwendung wird einer eindeutigen EDU mit dem Namen "Koordinationsagent" zugeordnet, die die Verarbeitung für die betreffende Anwendung koordiniert und mit ihr kommuniziert. Es kann auch eine Gruppe von Subagenten geben, die gemeinsam dafür zugeordnet sind, die Verarbeitung von Anforderungen der Client-Anwendung zu bearbeiten. Es können mehrere Subagenten zugeordnet werden, so daß die Anforderungen der Client-Anwendung die Prozessoren auf der Maschine nutzen können, auf der sich der Server befindet, wenn diese über mehrere Prozessoren (wie beispielsweise eine symmetrische Mehrprozessorumgebung) verfügt.
Alle Agenten und Subagenten werden unter Verwendung eines Algorithmus für eine Poolfunktion verwaltet, der die Erstellung und/oder Zerstörung von EDUs so gering wie möglich hält.
Ein Pufferpool ist ein Speicherbereich, in den Datenbankseiten mit Benutzertabellen-, Index- und Katalogdaten temporär verschoben und darin möglicherweise geändert werden. Der Pufferpool ist bei der Beeinflussung der Gesamtleistung einer Datenbank von zentraler Bedeutung, da der Zugriff auf Daten im Speicher weit schneller erfolgen kann als auf Platte. Wenn sich größere Mengen der von Anwendungen benötigten Daten im Pufferpool befinden würden, würde im Vergleich zu der Zeit, die für das Finden der Daten im Plattenspeicher aufgewendet werden muß, weniger Zeit zum Zugriff auf diese Daten benötigt werden. Weitere Informationen hierzu finden Sie im Abschnitt Verwalten des Datenbankpufferpools.
Die Konfiguration des Pufferpools steuert gemeinsam mit EDUs für Vorablesezugriff und Seitenlöschfunktionen die Verfügbarkeit von Daten, die von den Anwendungen benötigt werden.
Die Vorablesezugriffe sind dazu vorhanden, Daten von Platte abzurufen und in den Pufferpool zu verschieben, bevor diese Daten von Anwendungen benötigt werden. Beispielsweise würden Anwendungen, die große Volumen von Daten durchsuchen müssen, darauf warten müssen, daß Daten von Platte in den Pufferpool verschoben werden, wenn es keine Vorablesezugriffe für Daten geben würde. Agenten der Anwendung senden asynchrone Vorausleseanforderungen an eine allgemeine Bereitstellungswarteschlange. Wenn Vorablesezugriffe verfügbar werden, implementieren sie diese Anforderungen. Dabei verwenden sie Eingabeoperationen für große Blöcke (Big-Block) oder gestreutes Lesen (Scatter Read), um die angeforderten Seiten von Platte in den Pufferpool zu verschieben. Wenn mehrere Platten zur Speicherung der Datenbankdaten verfügbar sind, bedeutet dies, daß die Daten einheitenübergreifend gespeichert werden können. Mit Hilfe des einheitenübergreifenden Speicherns von Daten können die Vorablesezugriffe mehrere Platten gleichzeitig zum Abruf von Daten verwenden. Weitere Informationen finden Sie in den Abschnitten Vorablesen von Daten in den Pufferpool und Konfigurieren von E/A-Servern für Vorablesezugriff und parallele E/A.
Vorablesezugriffe werden dazu verwendet, Daten in den Pufferpool zu verschieben. Seitenlöschfunktionen werden dazu verwendet, Daten vom Pufferpool zurück auf die jeweilige Platte zu verschieben.
Seitenlöschfunktionen sind Hintergrund-EDUs, die von den Anwendungsagenten unabhängig sind. Sie suchen Seiten im Pufferpool, die nicht mehr benötigt werden, und lagern diese aus. Seitenlöschfunktionen können sicherstellen, daß im Pufferpool Platz für die Seiten ist, die von den Vorabzugriffen abgerufen werden.
Wenn die unabhängigen Vorablesezugriffe und Seitenlöschfunktions-EDUs nicht vorhanden wären, würden die Anwendungsagenten alle Lese- und Schreiboperationen für Daten zwischen Pufferpool und Plattenspeicher selbst ausführen müssen.
Wenn mehrere Anwendungen mit Daten aus der Datenbank arbeiten, kann zwischen zwei oder mehreren von ihnen "gegenseitiges Sperren" auftreten. Ein solches gegenseitiges Sperren ist in der folgenden Abbildung dargestellt.
Abbildung 68. Detektor für gegenseitiges Sperren
"Gegenseitiges Sperren" bedeutet, daß mehr als eine Anwendung darauf wartet, daß eine andere Anwendung eine Sperre für Daten freigibt. Alle wartenden Anwendungen sperren Daten, die von anderen Anwendungen benötigt werden. Diese gesperrten Daten werden von einer oder mehreren Anwendungen benötigt, die ihrerseits Daten sperren, die von anderen Anwendungen benötigt werden. Dieses gegenseitige Warten darauf, daß die andere Anwendung eine Sperre für gesperrte Daten freigibt, führt zu gegenseitigem Sperren: Die Anwendungen können unbegrenzt darauf warten, daß die jeweils "andere" Anwendung die aktive Sperre für die Daten freigibt. Die anderen Anwendungen geben die Sperren für Daten, die sie benötigen, nicht freiwillig frei. Zum Beenden dieser Situationen des gegenseitigen Sperrens ist ein Prozeß erforderlich.
Wie der Name schon sagt, überwacht der Detektor für gegenseitiges Sperren die Informationen zu Agenten, die an Sperren warten. Der Detektor für gegenseitiges Sperren wählt eine beliebige der Anwendungen aus, die sich gegenseitig sperren, um die Sperren freizugeben, die momentan von der "freiwilligen" Anwendung verwendet werden. Das Freigeben der Sperren dieser Anwendung führt dazu, daß die Daten wieder verfügbar gemacht werden, die von anderen wartenden Anwendungen benötigt werden. Die bis dahin wartenden Anwendungen können dann die Daten verwenden, die zum Durchführen von Aktionen in bezug auf Daten in der Datenbank erforderlich sind.
Änderungen an Datenseiten im Pufferpool werden protokolliert. Ein Protokollpuffer ist vorhanden und einer Protokollfunktions-EDU zugeordnet. Agenten, die einen Datensatz in der Datenbank aktualisieren, aktualisieren die zugeordnete Seite im Pufferpool und schreiben einen Protokollsatz. Dieser Protokollsatz enthält die Informationen, die zum Wiederholen bzw. Wiederrufen der Änderung notwendig sind. Weder die Seite im Pufferpool noch der Protokollsatz im Protokollpuffer werden sofort auf Platte geschrieben, damit die Leistung optimiert wird. Die Protokollfunktions-EDU und der Manager des Pufferpools implementieren gemeinsam ein WAL-Protokoll (Write Ahead Logging, vorausschreibende Protokollierung), das sicherstellt, daß die Datenseite nicht auf Platte geschrieben wird, bevor der zugehörige Protokollsatz in das Protokoll geschrieben wird. Das WAL-Protokoll gewährleistet, daß immer genügend Informationen im Protokoll sind, um die Wiederherstellung nach einem Absturz durchzuführen und die Datenbankkonsistenz wiederherzustellen. Wenn eine nicht festgeschriebene Aktualisierung einer Seite auf Platte geschrieben wurde, werden bei der Wiederherstellung nach einem Systemabsturz zum Widerrufen der Aktualisierung Widerrufsinformationen im zugehörigen Protokollsatz verwendet. Wenn eine festgeschriebene Aktualisierung (COMMIT-Operation) nicht auf Platte gespeichert wurde, werden bei der Wiederherstellung nach einem Systemabsturz die Wiederholungsinformationen im zugehörigen Protokollsatz zum Wiederholen der Aktualisierung verwendet.
Anmerkung: | Mit Hilfe einer COMMIT-Operation werden alle Protokollsätze in der Transaktion auf Platte geschrieben, wenn dies nicht bereits geschehen ist. |