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 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 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.
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 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: 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.
[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]