DB2 Universal Database - Systemverwaltung


Datenbankagenten

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:

  1. Im ersten Beispiel stellen durchschnittlich 40 Benutzer über DB2 Connect gleichzeitig eine Verbindung zu fernen Host-Datenbanken her. Zuweilen erreicht die Anzahl gleichzeitig bestehender Verbindungen Spitzenwerte um 50, überschreitet 55 jedoch nie. Die Transaktionen sind von kurzer Dauer, und Benutzer stellen häufig Verbindungen her und trennen sie wieder.

    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.

  2. In diesem zweiten Beispiel ist die Auslastung mit ca. 1 000 eingehenden Client-Verbindungen wesentlich höher. Die Benutzerverbindungen sind ebenfalls von kurzer Dauer. Der Systemadministrator will außer diesen gleichzeitig bestehenden Verbindungen keine weiteren zulassen. Daher setzt der Systemadministrator sowohl MAX_COORDAGENTS als auch NUM_POOLAGENTS auf den Wert 1 000. Dies bedeutet, daß die maximale Anzahl eingehender Clients, die gleichzeitig mit der fernen Datenbank (oder fernen Datenbanken) verbunden sein können, 1 000 ist. Wenn alle Clients die Verbindung trennen, enthält der Pool genau 1 000 verbundene Agenten, die alle darauf warten, neue eingehende Clients zu bedienen.
  3. Das dritte Beispiel betrachtet eine einzelne Anwendung, die eine Verbindung zu nur einer fernen Datenbank über DB2 Connect herstellt. Die Anwendung bleibt über lange Zeiträume hinweg verbunden. In diesem Beispiel besteht die beste Konfiguration für den Agenten- und den Verbindungspool darin, MAX_COORDAGENTS auf den Wert 1 zu setzen, da bekannt ist, daß höchstens ein Client die Verbindung herstellt. Der Parameter NUM_POOLAGENTS kann in diesem Fall auf den Wert 0 gesetzt werden, da die Herstellung und Trennung der Verbindung zum fernen Host nicht häufig durchgeführt wird. Durch die Einstellung des Parameters NUM_POOLAGENTS auf den Wert 0 wird die Poolfunktion für Verbindungen effektiv inaktiviert, da keine Agenten mit aktiven Verbindungen zur fernen Datenbank in den Pool gesetzt werden. Für jeden neuen eingehenden Client, der die Verbindung herstellt, wird ein neuer Agent erstellt und eine neue Fernverbindung hergestellt.
  4. Das vierte Beispiel zeigt eine Variante, die von den drei vorigen Auslastungsbeispielen ausgeht. In diesem Beispiel will der Systemadministrator die gleichzeitigen Zugriffe auf ferne Datenbanken auf nur 100 beschränken. Aus diesem Grund werden MAX_COORDAGENTS und, um eine maximale Leistung bei der Verbindungsherstellung zu ermöglichen, NUM_POOLAGENTS auf den Wert 100 gesetzt. Später indes könnte sich die Notwendigkeit ergeben, lokal eine Verbindung herzustellen, um die Auslastung auf dem System, auf dem DB2 Connect installiert ist, zu überwachen. Es wird geschätzt, daß zu einem beliebigen Zeitpunkt nicht mehr als fünf Momentaufnahmen von Überwachungsprogrammen gleichzeitig erfolgen, so daß MAX_COORDAGENTS auf den Wert 105 gesetzt wird. Dieser neue Konfigurationswert ermöglicht, daß die maximale Anzahl gleichzeitig verbundener Anwendungen über die frühere Obergrenze von 100 hinaus anwachsen kann, um die gelegentlichen Verbindungen für Momentaufnahmen von Überwachungsprogrammen und/oder Verbindungen zum Exemplar aufzunehmen.

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:

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:

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.


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