DB2-Server müssen die Kommunikation zwischen dem Datenbankmanager und Client-Anwendungen sowie lokalen Anwendungen unterstützen. Auf UNIX basierende Umgebungen verwenden eine mit Prozessen arbeitende Architektur. Zum Beispiel werden die kommunikationsbereiten DB2-Agenten (Listeners) als Prozesse erstellt. Intel-Betriebssysteme wie OS/2 und Windows NT verwenden eine Architektur, die auf Threads basiert. Zum Beispiel werden die kommunikationsbereiten DB2-Agenten innerhalb des Systemsteuerprozesses des DB2-Servers als Threads erstellt. Für jede Datenbank, auf die zugegriffen wird, werden verschiedene Prozesse/Threads gestartet, um die verschiedenen Datenbankoperationen (z. B. Vorablesen, Übertragung und Protokollieren) durchzuführen.
Eine der wichtigsten Arten von Prozessen/Threads sind die Datenbankagenten, die die Operationen von Anwendungen mit Datenbanken vollziehen.
Ein logischer Agent stellt eine mit dem Datenbankmanager verbundene Anwendung dar. Der logische Agent verfügt über alle Informationen und Steuerblöcke, die von einer Anwendung benötigt werden. Die maximale Anzahl logischer Agenten wird durch den Konfigurationsparameter max_logicagents des Datenbankmanagers gesteuert. Da alle Anwendungen über einen logischen Agenten verfügen, steuert dieser Parameter die maximale Anzahl von Anwendungen, von denen aus eine Verbindung zum Exemplar hergestellt werden kann.
Ein Verarbeitungsagent führt Anwendungsanforderungen aus, ist aber nicht dauerhaft mit einer bestimmten Anwendung verbunden. Der Verarbeitungsagent verfügt über alle Informationen und Steuerblöcke, die zum Beenden von Aktionen im Datenbankmanager erforderlich sind, die von der Anwendung angefordert wurden.
Es gibt vier Arten von Verarbeitungsagenten: aktive Korrdinationsagenten (Active Coordinator Agents), Subagenten (Subagents), inaktive Agenten (Inactive Agents) sowie Agenten im Bereitschaftsmodus (Idle Agents).
Der Agent im Bereitschaftsmodus ist die einfachste Form eines Verarbeitungsagenten: Es ist nicht mit einem logischen Agenten verbunden, hat keine abgehende Verbindung und verfügt nicht über eine Verbindung zu einer lokalen Datenbank oder eine Exemplarverbindung.
Der inaktive Agent ist ein Verarbeitungsagent, der sich nicht in einer aktiven Transaktion befindet, nicht mit einem logischen Agenten verbunden ist, keine abgehende Verbindung hat und nicht über eine Verbindung zu einer lokalen Datenbank oder eine Exemplarverbindung verfügt. Ein inaktiver Agent kann sich mit einem anderen logischen Agenten verbinden und dadurch für die Anwendung arbeiten, die durch diesen logischen Agenten repräsentiert wird.
Jeder Prozeß/Thread einer Client-Anwendung verfügt über einen einzigen aktiven Koordinationsagenten, der mit einer Datenbank arbeitet. Wenn der Koordinationsagent gestartet ist, führt er alle Datenbankanforderungen für die zugehörige Anwendung aus und kommuniziert mit anderen Agenten über die Interprozeßkommunikation (IPC) oder über Protokolle zur Fernverbindung. Jeder Agent arbeitet in einem eigenem privaten Speicher und benutzt globale Ressourcen des Datenbankmanagers und der Datenbank wie den Pufferpool mit anderen Agenten gemeinsam. Wenn eine Transaktion vollständig abgeschlossen wird, kann sich der aktive Koordinationsagent vom logischen Agenten lösen und so ein inaktiver Agent werden.
In Umgebungen mit partitionierten Datenbanken und Umgebungen mit aktivierter partitionsinterner Parallelität verteilt der Koordinationsagent die Datenbankanforderungen an Subagenten, die ihrerseits die Anforderungen für die Anwendungen ausführen. Wenn der koordinierende Agent erstellt ist, verarbeitet er alle Datenbankanforderungen für seine Anwendung, indem er die Subagenten koordiniert, die die Anforderungen in der Datenbank ausführen.
Wenn ein Client die Verbindung zu einer Datenbank oder einem Exemplar beendet, geschieht mit dem koordinierenden Agenten folgendes:
Die Agenten, die keine Arbeit für Anwendungen ausführen und darauf warten, zugeordnet zu werden, gelten als Agenten im Bereitschaftsmodus und befinden sich in einem Agentenpool. Diese Agenten sind für Anforderungen von Koordinationsagenten, die für Client-Programme aktiv sind, oder für Subagenten, die für vorhandene Koordinationsagenten aktiv sind, verfügbar. Die Anzahl der verfügbaren Agenten hängt vom Wert der Konfigurationsparameter maxagents und num_poolagents des Datenbankmanagers ab.
Agenten aus dem Agentenpool (num_poolagents) werden als Koordinationsagenten für einen der folgenden Zwecke erneut verwendet:
Andernfalls erstellen ferne Anwendungen immer einen neuen Agenten.
Falls kein Agent im Bereitschaftsmodus vorhanden ist, wenn ein Agent angefordert wird, muß ein neuer Agent dynamisch erstellt werden. Die Erstellung eines neuen Agenten verursacht einen bestimmten Systemaufwand, so daß die Leistung bei CONNECT- und ATTACH-Anweisungen merklich besser ist, wenn bereits ein Agent im Bereitschaftsmodus vorhanden ist, der für einen Client aktiviert werden kann.
Wenn ein Subagent für eine Anwendung aktiv ist, wird er als dieser Anwendung zugeordnet betrachtet. Nach Beendigung der angeforderten Operationen kann er in den Agentenpool gesetzt werden, bleibt jedoch der ursprünglichen Anwendung zugeordnet. Wenn die Anwendung eine weitere Operation anfordert, überprüft der Datenbankmanager bei der Suche nach einem Agenten für die Anwendung zunächst den Agentenpool nach zugeordneten freien Agenten.
Die Möglichkeit, die Zahl der verbundenen Anwendungen (unter Verwendung der Zahl der logischen Agenten, die in max_logicagents definiert wird) und die Zahl der Anwendungsanforderungen, die verarbeitet werden können (unter Verwendung der Zahl der aktiven Koordinationsagenten, die in max_coordagents definiert wird), getrennt zu steuern, schafft Flexibilität in den in der Datenbank verarbeiteten Auslastungen. Eine Eins-zu-eins-Beziehung zwischen der Zahl der verbundenen Anwendungen und der Zahl der Anwendungsanforderungen, die verarbeitet werden können, ist die normale Methode, in der Anwendungen mit der Datenbank arbeiten. Es kann jedoch sein, daß Sie aufgrund Ihrer Arbeitsumgebung eine Viele-zu-eins-Beziehung zwischen der Zahl der verbundenen Anwendungen und der Zahl der Anwendungsanforderungen benötigen, die verarbeitet werden können.
Da der globale Ressourcensystemaufwand der Datenbank den aktiven Koordinationsagenten zugeordnet ist, bedeutet eine größere Zahl dieser Agenten, daß eine größere Möglichkeit dafür besteht, daß die obere Begrenzung der verfügbaren globalen Ressourcen der Datenbank erreicht wird. Sie können mehr verbundene Anwendungen als aktive Koordinationsagenten zulassen, damit die obere Begrenzung der verfügbaren globale Ressourcen der Datenbank nicht erreicht werden. Wenn Sie für max_logicagents einen größeren Wert als für max_coordagents festlegen, konzentrieren Sie Ihre Datenbankarbeit.
Weitere Informationen und Beispiele zur Verwendung von DB2 Connect als XA-Transaktionsunterstützungskonzentrator finden Sie im Handbuch DB2 Connect Benutzerhandbuch.
In einer Umgebung, für die die Verwendung von DB2 Connect zur Verbindung mit fernen Systemen erforderlich ist, gibt es einen Pool abgehender Verbindungen (Outbound Connect Pool). Dieser Verbindungspool verringert die Zeit, die (im Anschluß an die erste Verbindung) zur Herstellung der Verbindung zu einem Host benötigt wird. Wenn eine Trennung von einem Host angefordert wird, beendet DB2 Connect die eingehende Verbindung (Inbound Connection), behält die abgehende Verbindung (Outbound Connection) zum Host jedoch in einem Pool. Wenn eine neue Anforderung zur Herstellung einer Verbindung zu diesem Host erfolgt, greift DB2 Connect auf eine vorhandene abgehende Verbindung (falls verfügbar) aus dem Pool zurück.
Anmerkung: | Beim Einsatz der Poolfunktion für Verbindungen ist DB2 Connect auf eingehende TCP/IP- und abgehende TCP/IP- und SNA-Verbindungen beschränkt. Bei Verwendung von SNA muß die Sicherheitsart auf den Wert NONE (Keine) eingestellt sein, damit die Verbindung in den Pool gesetzt werden kann. |
Bei der Verwendung des Verbindungspools schließt der aktive Agent seine abgehende Verbindung nach einer Trennung nicht, sondern wird mit einer aktiven Verbindung zum fernen Host in den Agentenpool versetzt. Diese Art von Agent wird als inaktiver DRDA-Agent bezeichnet. Der Pool für inaktive DRDA-Agenten ist mit dem Pool für abgehende Verbindungen identisch.
Betrachten Sie die folgenden Beispiele für vier verschiedene Verwendungs- und Auslastungsanforderungen:
Unter diesen Bedingungen sollte der Systemadministrator den Parameter MAX_COORDAGENTS mit dem Wert 55 konfigurieren, da er weiß, daß die maximale Anzahl von Benutzern, die gleichzeitig versuchen könnten, eine Verbindung über DB2 Connect herzustellen, 55 beträgt. Der Wert für NUM_POOLAGENTS, die Größe des Agentenpools, sollte auf 40 gesetzt werden, da dies zu einem beliebigen Zeitpunkt die durchschnittliche Anzahl von Benutzern ist, die verbunden sind bzw. versuchen, eine Verbindung herzustellen. Diese Poolgröße sorgt für ausreichend vorhandene Verbindungen zur fernen Datenbank, um alle eingehenden Client-Anforderungen zu erfüllen, ohne, abgesehen von den Spitzenauslastungszeiten, neue Verbindungen erstellen zu müssen.
In Umgebungen mit partitionierten Datenbanken und Umgebungen mit aktivierter partitionsinterner Parallelität besitzt jede Partition (d. h. jeder Datenbank-Server oder Knoten) einen eigenen Pool von Agenten, aus dem Subagenten entnommen werden. Durch die Verwendung dieses Pools müssen Subagenten nicht jedesmal erstellt und wieder gelöscht werden, wenn ein Subagent benötigt wird oder seine Arbeit beendet hat. Die Subagenten können als zugeordnete Agenten im Pool bleiben und vom Datenbankmanager für neue Anforderungen von der Anwendung, der sie zugeordnet sind, verwendet werden.
Die folgenden Konfigurationsparameter des Datenbankmanagers beeinflussen die Anzahl von Datenbankagenten:
Dieser Parameter kann in Umgebungen nützlich sein, in denen der Leistungsbedarf in Zeiten hoher Auslastung die Kapazität der vorhandenen Systemressourcen (Hauptspeicher, CPU und Plattenspeicher) übersteigt. In einer solchen Umgebung kann zu Spitzenzeiten z. B. durch Seitenwechselvorgänge ein starker Leistungsabfall auftreten. Mit diesem Parameter können Sie die Auslastung steuern und den Leistungsabfall verhindern.
In Umgebungen mit partitionierten Datenbanken und Umgebungen mit aktivierter partitionsinterner Parallelität besteht eine enge Beziehung zwischen dem Einfluß auf die Leistung und den Speicherbedarf innerhalb des Systems und der Optimierung des Agentenpools:
Außerdem kann eine Anwendung den Pool mit zugeordneten Subagenten füllen, wenn der Wert für den Parameter num_poolagents zu klein ist. Das bedeutet, wenn eine andere Anwendung einen neuen Subagenten benötigt und über keine Agenten im zugeordneten Pool verfügt, "stiehlt" sie Subagenten aus den Agentenpools anderer Anwendungen. In diesem Fall ist der Systemaufwand recht hoch und die Leistung gering.
Wenn der Wert des Parameters num_poolagents zum Beispiel zu groß ist, werden zugeordnete Subagenten lange Zeit ungenutzt im Pool behalten. Diese Subagenten verbrauchen Ressourcen des Datenbankmanagers, die dann nicht für andere Funktionen zur Verfügung stehen.
Neben den Datenbankagenten gibt es auch noch andere asynchrone Aktivitäten des Datenbankmanagers, die als eigene Prozesse (bzw. Threads) ausgeführt werden. Dazu gehören:
Weitere Informationen zur Identifizierung der verschiedenen DB2-Prozesse finden Sie im Handbuch Troubleshooting Guide.