DB2 Universal Database - Systemverwaltung


Prozeßmodell

Lokale und ferne Anwendungsprozesse können mit derselben Datenbank arbeiten. Eine ferne Datenbank initiiert eine Datenbankaktion von einer Maschine aus, die sich von der Datenbankmaschine entfernt befindet. Lokale Anwendungen sind an der Server-Maschine direkt mit der Datenbank verbunden.

Alle Kreise in der folgenden Abbildung stellen EDUs (Engine Dispatchable Units, zuteilbare Einheiten der Steuerkomponente) dar, die auf UNIX-Plattformen als "Prozesse" und auf Windows NT- und OS/2-Plattformen als "Threads" bekannt sind.

Abbildung 73. Prozeßmodell - Übersicht

PMSP0000

Bevor die Arbeit ausgeführt werden kann, die für die Anwendung in der Datenbank durchgeführt werden soll, muß zwischen einer Anwendung und dem Datenbankmanager muß ein Kommunikationsmittel eingerichtet werden.

In der obenstehenden Abbildung richtet ein lokaler Client bei A1 die Kommunikation ein, indem er zuerst mit der EDU "db2ipccm" (Engine Dispatchable Unit, zuteilbare Einheit der Steuerkomponente) arbeitet. Diese EDU arbeitet bei A2 mit einer EDU "db2agent", die zum Koordinationsagenten für die Anwendungsanforderungen vom lokalen Client wird. Der Koordinationsagent nimmt bei A3 mit der Client-Anwendung Kontakt auf und richtet bei A4 zwischen der Client-Anwendung und der Datenbank eine Kommunikation mit gemeinsam benutztem Speicher und Semaphors ein. Zwischen der Anwendung auf dem lokalen Client und der Datenbank wird eine Verbindung hergestellt.

In der obenstehenden Abbildung richtet ein ferner Client bei B1 die Kommunikation ein, indem er zuerst mit der EDU "db2tcpcm" arbeitet. Wenn ein anderes Kommunikationsprotokoll ausgewählt worden wäre, würde die entsprechende EDU verwendet werden. Die EDU "db2tcpcm" arbeitet bei B2 mit einem logischen Agenten. Diese EDU arbeitet bei B3 mit einer EDU "db2agent", die zum Koordinationsagenten für die Anwendungsanforderungen vom fernen Client wird. Der Koordinationsagent nimmt bei B4 mit der Client-Anwendung Kontakt auf und richtet bei B5 zwischen der Client-Anwendung und der Datenbank eine TCP/IP-Kommunikation ein. Zwischen der Anwendung auf dem fernen Client und der Datenbank wird eine Verbindung hergestellt.

Im folgenden sind weitere wichtige Details dieser Abbildung aufgeführt:

Abbildung 74. Prozeßmodell Teil 2

PMSP0002

In dieser Abbildung werden zusätzliche EDUs gezeigt (Engine Dispatchable Units, zuteilbare Einheiten der Steuerkomponente), die Teil der Server-Maschinenumgebung sind. Alle aktiven Datenbanken verfügen über eigene gemeinsam benutzte Pools von Vorablesezugriffen ("db2pfchr") und Seitenlöschfunktionen ("db2pclnr") sowie eigene Protokollfunktionen ("db2loggr") und Detektoren für gegenseitiges Sperren ("db2dlock").

Die Kreise mit den Namen "db2udfp" und "db2dari" in der Abbildung unten rechts stellen Prozesse dar, die in DB2 Universal Database als abgeschirmte UDFs (User-defined Functions, benutzerdefinierte Funktionen) bzw. gespeicherte Prozeduren ausgeführt werden. Diese Prozesse werden verwaltet, um den Aufwand in Zusammenhang mit ihrer Erstellung und Zerstörung zu minimieren. Die Standardeinstellung für den Konfigurationsparameter keepdari des Datenbankmanagers ist "YES" (Ja), wodurch der Prozeß der gespeicherten Prozedur zur erneuten Verwendung beim nächsten Aufruf einer gespeicherten Prozedur verfügbar bleibt.
Anmerkung:Es gibt auch nicht abgeschirmte UDFs und gespeicherte Prozeduren, die direkt im Adreßraum eines Agenten ausgeführt werden. Diese Vorgehensweise führt zu einer besseren Leistung. Da diese UDFs und gespeicherten Prozeduren jedoch über unbeschränkten Zugriff auf den Adreßraum des Agenten verfügen, müssen sie vor ihrer Verwendung umfassend getestet werden.

Weiter Informationen hierzu finden Sie im Kapitel über gespeicherte Prozeduren im Handbuch Application Development Guide.

Das Prozeßmodell mit mehreren Partitionen ist eine logische Erweiterung des Prozeßmodells mit einer einzigen Partition. Beide Betriebsarten werden durch eine einzige allgemeine Codebasis unterstützt. Die folgende Abbildung stellt die Ähnlichkeiten und Unterschiede zwischen dem Prozeßmodell mit einer einzigen Partition, wie in den vorangehenden zwei Abbildungen gezeigt, und dem Prozeßmodell mit mehreren Partitionen dar.

Abbildung 75. Prozeßmodell und mehrere Partitionen

PMMP0000

Die Mehrzahl der EDUs entsprechen beim Prozeßmodell mit einer einzigen Partition denen beim Prozeßmodell mit mehreren Partitionen.

In einer Umgebung mit mehreren Partitionen (bzw. Knotenumgebung) ist eine der Partitionen der Katalogknoten. Der Katalog speichert alle Information in bezug auf Objekte in der Datenbank.

Wie in der obenstehenden Abbildung gezeigt, wird der Katalog der PROD-Datenbank im Knoten Node0000 erstellt, weil Anwendung A die PROD-Datenbank in diesem Knoten erstellt. Ebenso wird der Katalog für die TEST-Datenbank im Knoten Node0001 erstellt, weil Anwendung B die TEST-Datenbank in diesem Knoten erstellt. Die Datenbanken sollten in verschiedenen Knoten erstellt werden, um so die zusätzliche Aktivität in Zusammenhang mit den Katalogen für jede Datenbank gleichmäßig auf die Knoten in der Systemumgebung zu verteilen.

Dem Exemplar sind zusätzliche EDUs ("db2pdbc" und "db2fcmd") zugeordnet, die sich in jedem Knoten in einer Datenbankumgebung mit mehreren Partitionen befinden. Diese EDUs werden für die Koordination von Anforderungen zwischen Datenbankpartitionen und zum Aktivieren des FCM (Fast Communications Manager) benötigt.

Dem Katalogknoten der Datenbank ist ebenfalls eine zusätzliche EDU ("db2glock") zugeordnet. Diese EDU steuert globale Sperren für die Knoten, in denen sich die aktive Datenbank befindet.

Alle CONNECT-Operationen von Anweisungen werden durch einen logischen Agenten in der Datenbank repräsentiert und führen zu einem einzigen Koordinationsagenten. Der Koordinationsagent ist in der Partition vorhanden, zu der eine Verbindung von der Anwendung besteht. Diese Partition wird dann zum "Koordinatorknoten" für die betreffende Anwendung. Der Koordinatorknoten kann auch unter Verwendung des Befehls SET CLIENT CONNECT_NODE definiert werden. Teile der Datenbankanforderungen von der Anwendung werden durch den Koordinatorknoten auf Subagenten der anderen Partitionen aufgeteilt; zudem werden alle Ergebnisse der anderen Partitionen am Koordinatorknoten konsolidiert, bevor sie zurück zur Anwendung gesendet werden.

Die Datenbankpartition, in der der Befehl CREATE DATABASE ausgegeben wurde, wird "Katalogknoten" der Datenbank genannt. In dieser Datenbankpartition werden die Katalogtabellen gespeichert. Normalerweise werden alle Benutzertabellen über eine Reihe von Knoten hinweg partitioniert.
Anmerkung: Eine beliebige Anzahl von Partitionen kann zur Ausführung auf einer einzigen Maschine konfiguriert werden. Dies ist als Konfiguration mit "mehreren logischen Partitionen" oder mit "mehreren logischen Knoten" bekannt. Eine solche Konfiguration ist bei großen SMP-Maschinen (SMP - Symmetric Multiprocessor, symmetrischer Mehrprozessor) mit einem sehr großen Hauptspeicher sehr nützlich. In einer derartigen Umgebung kann die Kommunikation zwischen Partitionen durch die Verwendung von gemeinsam benutztem Speicher und Semaphors optimiert werden.


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