DB2 Connect Benutzerhandbuch


Verbindungszusammenschluß

DB2 Connect Enterprise Edition-Server stellen häufig Datenbankverbindungen für Tausende gleichzeitiger Client-Anforderungen zur Verfügung. Das Herstellen und Trennen von Verbindungen zu Datenbank-Servern ist ein Prozeß, der sehr viele Ressourcen verbrauchen kann und einen negativen Einfluß sowohl auf die Leistung von Datenbank-Servern als auch von DB2 Connect-Servern hat. Dies zeigt sich insbesondere in Web-Umgebungen, in denen bei jedem Besuch auf einer Web-Seite der Aufbau einer neuen Verbindung zum Datenbank-Server, die Ausführung einer Abfrage und die Trennung der Verbindung erforderlich werden kann. Um diesen Systemaufwand zu reduzieren, verwendet DB2 Connect Enterprise Edition den Verbindungszusammenschluß, um offene Verbindungen zu Datenbanken in einem leicht verfügbaren Pool zu verwalten.

Funktionsweise des Verbindungszusammenschlusses

Der Verbindungszusammenschluß ist für Anwendungen transparent, die über DB2 Connect eine Verbindung zum Host herstellen. Wenn eine Anwendung das Trennen der Verbindung zum Host anfordert, löscht DB2 Connect die eingehende Verbindung zur Anwendung, beläßt die abgehende Verbindung zum Host jedoch in einem Pool. Wenn eine neue Anwendung eine Verbindung anfordert, verwendet DB2 Connect eine Verbindung aus dem bestehenden Pool. Die Verwendung der bereits bestehenden Verbindung reduziert die allgemeine Anschlußzeit sowie den hohen Ressourcenverbrauch für die CPU-Verbindung auf dem Host.

Für die Verwendung des Verbindungszusammenschlusses muß folgendes APAR auf DB2 für OS/390 Version 6.1 angewandt werden:

     APAR PQ33473

DB2 Connect-Agenten können sich in einem von zwei Status befinden: inaktiv oder aktiv. Ein Agent ist aktiv, wenn er eine Aktion für eine Anwendung ausführt. Sobald diese Aktion beendet ist, geht der Agent in den inaktiven Status über und wartet auf weitere Aktionen von derselben oder einer anderen Anwendung. Alle inaktiven Agenten werden zusammen in einem Pool für inaktive Agenten verwaltet. Sie können die Größe dieses Pools über den Konfigurationsparameter NUM_POOLAGENTS ändern. Dieser Parameter entspricht der maximalen Anzahl der inaktiven Agenten, die das System verwalten soll. Wird der Parameter auf Null gesetzt, bedeutet dies, daß die Funktion des Verbindungszusammenschlusses ausgeschaltet ist.

DB2 Connect stellt Verbindungen zur Datenbank erst dann her, wenn die erste Client-Anforderung empfangen wird. Wenn Sie möchten, können Sie den Pool der inaktiven Agenten jedoch füllen, bevor Anforderungen von Clients ausgegeben werden. Der Pool kann beim Initialisieren über den Konfigurationsparameter NUM_INITAGENTS gefüllt werden. Dieser Parameter gibt an, wieviele inaktive Agenten beim Initialisieren erstellt werden sollen. Diese inaktiven Agenten haben zunächst keine Verbindung zum Host-Datenbank-Server.

Wenn ein Client eine Verbindung zum Host anfordert, versucht DB2 Connect, aus dem Pool einen Agenten abzurufen, der bereits über eine Verbindung zum Host-Datenbank-Server verfügt. Schlägt dies fehl, sucht DB2 Connect einen Agenten im Pool der inaktiven Agenten. Wenn der Pool leer ist, erstellt DB2 Connect einen neuen Agenten.

Sie können die maximale Anzahl der gleichzeitig aktiven Agenten über den Konfigurationsparameter MAX_COORDAGENTS steuern. Sobald diese Anzahl überschritten wird, schlagen neue Verbindungen mit dem SQL-Fehlercode SQL1226 fehl. (Dieser Code bedeutet, daß die maximale Anzahl der gleichzeitig bestehenden abgehenden Verbindungen überschritten wurde.)

Die DB2-Registrierungsvariable DB2CONNECT_IN_APP_PROCESS läßt zu, daß für Anwendungen, die auf derselben Maschine wie DB2 Connect EE ausgeführt werden, entweder DB2 Connect innerhalb des Anwendungsprozesses ausgeführt wird (Standardverhalten), oder daß eine Verbindung zum DB2 Connect EE-Server hergestellt wird und die Host-Verbindung dann innerhalb des Agenten ausgeführt wird. Damit eine Anwendung den Verbindungszusammenschluß verwenden kann, müssen die Verbindungen zum Host aus den DB2 Connect EE Server-Agenten heraus erfolgen. Demnach muß der Parameter DB2CONNECT_IN_APP_PROCESS auf NO (Nein) gesetzt werden.

DB2 Connect - Verbindungskonzentrator

Mit Hilfe der Technologie des Verbindungskonzentrators von DB2 Connect können DB2 Connect Enterprise Edition-Server Unterstützung für Tausende von Benutzern zur Verfügung stellen, die gleichzeitig Geschäftstransaktionen ausführen, während der Ressourcenverbrauch auf den S/390-Host- oder AS/400-Datenbank-Servern drastisch reduziert wird. Dieses Ziel wird durch eine Konzentration der Arbeitsbelastung aller Anwendungen auf eine viel kleinere Anzahl von Verbindungen zu S/390-Host oder AS/400-Datenbank-Servern erreicht. Diese Methode scheint der oben beschriebenen Funktion des Verbindungszusammenschlusses zu ähneln. Es handelt sich jedoch um eine anspruchsvollere Methode zur Reduzierung des Ressourcenverbrauchs für OLTP-Anwendungen (Online-Transaktionsverarbeitung) mit sehr hohem Volumen.

Der Verbindungszusammenschluß spart Ressourcen bei der Herstellung einer Verbindung, wenn eine verwendet wird, die von einer beendeten Anwendung nicht mehr benötigt wird. Mit anderen Worten: Eine Anwendung muß ihre Verbindung erst trennen, bevor eine andere Anwendung diese in den Pool zurückgestellte Verbindung erneut verwenden kann.

Der Verbindungskonzentrator ermöglicht es DB2 Connect jedoch, einer Anwendung eine Verbindung zur Verfügung zu stellen, sobald eine andere Anwendung eine Transaktion beendet hat. Dazu muß diese andere Anwendung ihre Verbindung jedoch nicht trennen. Kurz gesagt: Eine Verbindung zu einem Datenbank-Server und die damit verbundenen Host- und DB2 Connect-Ressourcen werden von einer Anwendung nur für den Zeitraum einer aktiven Transaktion verwendet. Sobald die Transaktion beendet wird, stehen die Verbindung und die zugeordneten Ressourcen einer beliebigen anderen Anwendung zur Verfügung, die eine Transaktion ausführen muß.

Implementieren des Verbindungskonzentrators

In früheren Versionen von DB2 Connect verfügte jede aktive Anwendung über eine Engine Dispatchable Unit (EDU), die sowohl die Datenbankverbindung als auch alle Anwendungsanforderungen verwaltete. Diese EDU wurde normalerweise als Koordinationsagent bezeichnet. Jeder Koordinationsagent protokollierte den Status oder den Kontext der Anwendung und EDU. Jede EDU verbraucht mit zunehmender Anzahl an Verbindungen eine beträchtliche Menge an Speicherkapazität, und der Kontextwechsel zwischen den Agenten führt zu einem zusätzlichen Systemaufwand.

In der oben beschriebenen Architektur besteht eine Eins-zu-eins-Beziehung zwischen Verbindungen und EDUs. Der Verbindungskonzentrator läßt jedoch eine Viele-zu-eins-Beziehung zwischen Verbindungen und EDUs zu. Dies bedeutet, daß die Beziehung von Verbindungen (X) zu EDUs (Y) jetzt X >= Y ist.

Der Verbindungskonzentrator teilt den Agenten in zwei Definitionseinheiten auf: einen logischen Agenten und einen Verarbeitungsagenten. Logische Agenten stellen eine Anwendung dar, jedoch ohne Verweis auf eine bestimmte EDU. Der logische Agent enthält alle Informationen und Steuerblöcke, die eine Anwendung benötigt. Wenn n Anwendungen mit einem Server verbunden sind, sind auch n logische Agenten auf dem Server vorhanden. Verarbeitungsagenten sind physische EDUs, die Anforderungen von Anwendungen ausführen, jedoch keiner bestimmten Anwendung permanent zugeordnet sind. Zwecks Ausführung von Transaktionen werden Verarbeitungsagenten logischen Agenten zugeordnet. An der Transaktionsgrenze wird diese Zuordnung wieder beendet, und die Verarbeitungsagenten werden erneut in den verfügbaren Pool gestellt.

Eine als Scheduler für logische Agenten bezeichnete Definitionseinheit ordnet Verarbeitungsagenten logischen Agenten zu. Einschränkungen bei der Anzahl der offenen Dateikennungen auf bestimmten Datenverarbeitungsplattformen können zu mehr als einem Scheduler-Exemplar führen, wenn die Anzahl der logischen Agenten den Grenzwert für Dateikennungen überschreitet.

Aktivieren des Konzentrators

Für die Verwendung des Verbindungskonzentrators muß folgendes APAR auf DB2 für OS/390 Version 6.1 angewandt werden:

     
APAR PQ33473

Über den Konfigurationsparameter des Datenbankmanagers MAX_LOGICAGENTS wird die maximale Anzahl der logischen Agenten festgelegt. Sie können die Konzentratorfunktion aktivieren, indem Sie den Wert für MAX_LOGICAGENTS auf irgendeinen Wert über dem Standardwert festlegen. Der Standardwert für MAX_LOGICAGENTS entspricht dem Wert von MAX_COORDAGENTS. Da jede Anwendung über einen logischen Agenten verfügen wird, steuert MAX_LOGICAGENTS eigentlich die Anzahl der Anwendungen, die mit dem Datenbankexemplar verbunden werden können, während MAX_COORDAGENTS die Anzahl der eingehenden Verbindungen steuert, die gleichzeitig aktiv sein können. MAX_LOGICAGENTS nimmt einen numerischen Bereich von MAX_COORDAGENTS bis 64.000 an. Die Standardanzahl an logischen Agenten entspricht dem Wert von MAX_COORDAGENTS.

Für die Konfiguration von Agenten werden verschiedene Konfigurationsparameter verwendet. Hierbei handelt es sich um folgende Parameter:

MAXAGENTS
Maximale Anzahl an Verarbeitungsagenten

MAX_COORDAGENTS
Maximale Anzahl an aktiven Koordinationsagenten

NUM_POOLAGENTS
Größe des Agentenpools. Der Agentenpool umfaßt inaktive Agenten und Agenten im Bereitschaftsmodus.

NUM_INITAGENTS
Anfängliche Anzahl an Verarbeitungsagenten im Pool. Hierbei handelt es sich um inaktive Agenten.

XA-Transaktionsunterstützung

Über die Architektur des Verbindungskonzentrators kann DB2 Connect eine eng gekoppelte XA-Transaktionsunterstützung für DB2 für OS/390 und DB2 für AS/400 zur Verfügung stellen. Wie bei allen anderen Transaktionen auch, ordnet der Konzentrator einem Verarbeitungsagenten eine bestimmte XA-Transaktion (einzelne Transaktions-ID, XID) zu. Wenn die XA-Transaktion jedoch durch xa_end() (Verzweigungsgrenze) beendet wird, erfolgt für den Verarbeitungsagenten keine Freigabe für den allgemeinen Pool. Statt dessen bleibt der Verarbeitungsagent dieser bestimmten XA-Transaktion zugeordnet. Wenn eine andere Anwendung derselben XA-Transaktion zugeordnet wird, wird der Verarbeitungsagent dieser Anwendung zugeordnet.

Durch einen Transaktionsgrenzenaufruf wird der Agent an den Pool zurückgegeben. Beispielsweise durch xa_prepare() mit Lesezugriff, xa_rollback(), xa_recover(), xa_forget(), xa_commit() oder einen beliebigen XA-Fehler, der eine ROLLBACK-Operation verursacht, wird der Agent an den normalen Pool zurückgegeben. Xa_end() selbst beendet lediglich die Transaktionsverzweigung, und dies reicht nicht für eine Beendigung der Zuordnung mit der XID aus.

Beispiele

  1. Stellen Sie sich eine Umgebung vor, in der mindestens 4.000 gleichzeitig bestehende Verbindungen benötigt werden. Web-Server, die CGI-Anwendungen verwenden, oder Büroanwendungen mit vielen Desktop-Benutzern können diese Anforderung überschreiten. In diesen Fällen ist aus Effizienzgründen normalerweise erforderlich, daß DB2 Connect als eigenständiger Gateway fungiert. Dies bedeutet, daß die Datenbank und das DB2 Connect-System sich auf getrennten Maschinen befinden.

    Das DB2 Connect-Server-System ist unter Umständen nicht in der Lage, 4.000 gleichzeitig offene Verbindungen zur Datenbankmaschine zu verwalten. In den meisten Fällen ist die Anzahl der Transaktionen, die zu einem bestimmten Zeitpunkt ausgeführt werden, weitaus geringer als die Anzahl der gleichzeitig bestehenden Verbindungen. Der Systemadministrator könnte die Effizienz des Systems maximieren, indem er die Datenbankkonfigurationsparameter wie folgt einstellt:

         MAX_LOGICAGENTS =  4000
         MAX_AGENTS      =  1000
         MAX_COORDAGENTS =  1000
         NUM_POOLAGENTS  =  1000
    

    Der Konzentrator hält bis zu 4.000 gleichzeitig ablaufende Sitzungen offen, obwohl der Gateway lediglich 1.000 Transaktionen zur Zeit verwaltet.

  2. Im oben beschriebenen Beispiel werden von Verarbeitungsagenten ständig Zuordnungen zu logischen Agenten erstellt und aufgehoben. Diejenigen Agenten, die aktiv sind, können eine Verbindung zur Datenbank verwalten, nehmen jedoch an keiner bestimmten Transaktion teil; also stehen sie allen logischen Agenten (Anwendungen) zur Verfügung, die eine Verbindung anfordern.

    Bei den XA-Transaktionen sieht es etwas anders aus. Zum Zwecke dieses Beispiels nehmen wir an, daß ein TP-Monitor mit einem DB2 Connect-Gateway und einer OS/390- oder AS/400-Datenbank verwendet wird. Wenn eine Anwendung eine Verbindung anfordert, übergibt der Konzentrator entweder einen inaktiven Agenten, um diese Anforderung zu bedienen, oder er erstellt einen neuen Verarbeitungsagenten. Nehmen wir an, eine Anwendung fordert eine XA-Transaktion an. Für diese Transaktion wird eine XID erstellt, und der Verarbeitungsagent wird der Transaktion zugeordnet.

    Nachdem die Anforderung der Anwendung ausgeführt wurde, wird xa_end() ausgegeben, und die Zuordnung zum Verarbeitungsagenten wird aufgehoben. Der Verarbeitungsagent bleibt der XID der Transaktion zugeordnet. Er kann jetzt lediglich mit der ihm zugeordneten XID Anforderungen für Transaktionen ausführen.

    Zu diesem Zeitpunkt kann eine weitere Anwendung eine Anforderung für eine Nicht-XA-Transaktion ausgeben. Selbst wenn keine anderen Verarbeitungsagenten verfügbar sind, wird der für die XID zugeordnete Agent der zweiten Anwendung nicht zur Verfügung gestellt. Er wird als aktiv angesehen. Für die zweite Anwendung wird ein neuer Verarbeitungsagent erstellt. Wenn die zweite Anwendung ihre Transaktion beendet hat, wird ihr Verarbeitungsagent für den verfügbaren Pool freigegeben.

    Währenddessen können andere Anwendungen, die die Transaktion anfordern, die der XID des ersten Agenten zugeordnet ist, eine Verbindung zu diesem Agenten herstellen oder unterbrechen. Dieser Agent führt seine dedizierte XA-Transaktion für sie aus. Alle Anwendungen, die diese bestimmte Transaktion anfordern, werden an diesen Verarbeitungsagenten gesendet, sofern er frei ist.

    Der Verarbeitungsagent wird erst dann für den allgemeinen Pool freigegeben, wenn eine Anwendung einen Transaktionsgrenzenaufruf (nicht xa_end()) ausgibt. Beispielsweise kann eine Anwendung die Transaktion mit xa_commit() beenden. Sobald dies geschieht löscht der Verarbeitungsagent seine Zuordnung zur XID und wird in den verfügbaren Pool zurückgestellt. Ab diesem Zeitpunkt können alle Anwendungen, die eine Anforderung ausgeben, diesen Agenten entweder für eine weitere XA-Transaktion oder eine Nicht-XA-Transaktion verwenden.

Einschränkungen

Die Verwendung des Gateway-Konzentrators unterliegt einigen wesentlichen Einschränkungen. Bitte lesen Sie die folgenden Informationen zunächst vollständig durch, bevor Sie versuchen, den Verbindungskonzentrator auf Ihrem System zu verwenden.

Optimieren der Datenbank

Die Systemleistung wird durch die Leistung der Datenbank des Host- oder AS/400-Datenbank-Servers beeinflußt.

Verschiedene Datenbankverwaltungssysteme haben verschiedene Leistungsmerkmale. SQL-Optimierungsprogramme verschiedener Systeme können sich z. B. bei derselben Anwendung unterschiedlich verhalten. Weitere Informationen können Sie der Leistungsbeschreibung in der Dokumentation des verwendeten Host- oder AS/400-Datenbank-Server-Systems entnehmen.

Bei DB2 Universal Database für AS/400 kann möglicherweise eine Leistungssteigerung erzielt werden, indem die Bindeoption für den nicht festgeschriebenen Lesevorgang (UR, Uncommitted Read) oder für keine COMMIT-Operation (NC, No Commit) verwendet wird, so daß keine Aufzeichnung stattfindet.

Anmerkung:Wird UR verwendet, können nicht aufgezeichnete Daten nur gelesen, jedoch nicht aktualisiert werden, und dies auch nur dann, wenn die Blockung auf ALL eingestellt ist.

Je nach dem verwendeten Anwendungs-Server und der von ihm zur Verfügung gestellten Unterteilung für Sperren kann die für eine Abfrage oder Anwendung verwendete Isolationsstufe einen erheblichen Einfluß auf die Leistung ausüben.

Die Datenbank sollte über eine geeignete Normalisierungsstufe, eine effiziente Verwendung von Indizes und eine sinnvolle Zuordnung von Datenbankbereich verfügen. Die Leistung kann auch durch die verwendeten Datentypen beeinflußt werden, wie in den nachfolgenden Abschnitten beschrieben wird.

Optimieren von DB2 für OS/390

OS/390 V1R3 stellt die Mindestanforderung für TCP/IP-Unterstützung dar. OS/390 V2R5 oder höher wird dringend empfohlen.

DDF (Distributed Data Facility) ist für das Herstellen der Verbindung von verteilten Anwendungen zu DB2 für OS/390 zuständig. DDF muß als Anwendungs-Server definiert werden. Dazu können Sie entweder den LU-Namen des fernen Systems in die Tabelle SYSIBM.LUNAMES oder die Werte für LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT und USERNAMES in die Tabelle SYSIBM.SYSLUNAME einfügen. Führen Sie dann eine DDF-Aktualisierung für den BSDS (Boot Strap Data Set) aus. Dies kann folgendermaßen aussehen:

   DDF LOCATION=LOC1,LUNAME=LU1,PORT=8000,RESPORT=8001

Sie erzielen die beste Leistung, wenn Sie die empfohlene DDF-Adreßraumpriorität verwenden (bei aktivem Modus COMPAT etwas niedriger als oder gleich DBM1). Verwenden Sie RACF-Caching von Berechtigungen in VLF und das Caching der Version 5 für Paketberechtigungen, sofern möglich. Der Wert CACHEPAC=32768 reicht für die meisten Operationen aus.

Da DDF versucht, eine Verbindung zu VTAM herzustellen, muß VTAM beim Start von DDF aktiv sein. Es folgt eine VTAM APPL-Beispieldefinition:

   
     SYD51TC* APPL  AUTH=(ACQ),                                X
              PARSESS=YES,                                     X
              HAVAIL=YES,                                      X
              EAS=1600,                                        X
              APPC=YES,                                        X
              DSESLIM=1024,                                    X
              DMINWNL=512,                                     X
              DMINWNR=512,                                     X
              AUTOSES=1,                                       X
              SECACPT=ALREADYV,                                X
              SRBEXIT=YES,                                     X
              SYNCLVL=SYNCPT,                                  X
              MODETAB=DB2MODET,                                X
              VPACING=63                                       X

Sie können die Verarbeitung inaktiver Threads in OS/390 optimieren. In Version 3 sind maximal 10.000 gleichzeitig verbundene Clients zulässig, und in Version 4 und Version 5 maximal 25.000. In allen Fällen beträgt die maximale Anzahl gleichzeitig aktiver Clients jedoch 1999. Jeder Workstation-Client kann verbunden bleiben, wenn er inaktiv ist; sein Thread wird bei jeder COMMIT-Operation in eine Kette inaktiver Clients gestellt.

Die DSNZPARM-Parameter CMTSTAT, CONDBAT und MAXDBAT beeinflussen die Thread-Verarbeitung. Setzen Sie CMTSTAT auf INACTIVE, passen Sie CONDBAT an die maximale Anzahl verbundener DBATs bei guter Leistung an, und setzen Sie MAXDBAT auf die maximal zulässige Anzahl aktiver DBATs, um die beste Leistung zu erzielen.

Eine vollständige Erläuterung der Schritte zum Herstellen einer Verbindung zu DB2 für OS/390 in einem DRDA-Netzwerk, einschließlich der VTAM-Konfiguration, finden Sie Handbuch Konnektivität Ergänzung.

Datenumsetzung

Wenn Daten von einer Umgebung in eine andere übertragen werden, müssen sie möglicherweise umgesetzt werden. Diese Umsetzung kann die Leistung beeinflussen.

Gehen Sie von folgenden Plattformen aus:

Gehen Sie außerdem von folgenden Typen für numerische Daten aus:

Tabelle 8 zeigt, wann die Umsetzung stattfindet.

Tabelle 8. Datenumsetzung

 


Intel


IEEE


S/370 & S/390


OS/400


Gepackt dezimale Daten


Intel
IEEE
S/370/390
OS/400


Nein
Nein
Nein
Nein


Nein
Nein
Nein
Nein


Nein
Nein
Nein
Nein


Nein
Nein
Nein
Nein


Gezont dezimale Daten


Intel
IEEE
S/370/390
OS/400


Nein
Nein
Ja
Ja


Nein
Nein
Ja
Ja


Ja
Ja
Nein
Nein


Ja
Ja
Nein
Nein


Ganzzahlige Daten


Intel
IEEE
S/370/390
OS/400


Nein
Ja
Ja
Ja


Ja
Nein
Nein
Nein


Ja
Nein
Nein
Nein


Ja
Nein
Nein
Nein


Gleitkommadaten


Intel
IEEE
S/370/390
OS/400


Nein
Ja
Ja
Ja


Ja
Nein
Ja
Nein


Ja
Ja
Nein
Ja


Ja
Nein
Ja
Nein

Die Datenumsetzung bei Einzelbytezeichen belastet die CPU in der Regel weniger als die Umsetzung numerischer Daten (wenn eine Datenumsetzung erforderlich ist).

Der Aufwand für die Datenumsetzung von Daten des Typs DATE/TIME/TIMESTAMP ist fast so groß wie der für Einzelbytezeichen des Datentyps CHAR. Die Umsetzung von Gleitkommadaten (Datentyp FLOATING) ist am aufwendigsten. Diese Überlegungen sollte ein Anwendungsentwickler berücksichtigen, wenn er eine Anwendung entwirft, die auf DB2 Connect basiert.

Wenn eine Datenbanktabelle eine Spalte hat, für die als Datentyp FOR BIT DATA definiert ist, müssen die zwischen der Anwendung und der Datenbank übertragenen Zeichendaten nicht umgesetzt werden. Dieses Verfahren kann zum Archivieren von Daten auf dem Host- oder AS/400-Datenbank-Server verwendet werden.

Datentypen für Zeichendaten

Zeichendaten können entweder den Datentyp CHAR oder VARCHAR haben. Welcher Datentyp effizienter ist, hängt von der durchschnittlichen Länge der Daten im Feld ab:

Netzwerkoptimierung

Die beste Methode, die Gesamtleistung in einer verteilten Datenbankumgebung zu verbessern, ist das Eliminieren von Verzögerungen, die durch das Netzwerk verursacht werden. Netzwerkadministratoren gehen in der Regel davon aus, daß ein Netzwerk effektiver ist, wenn es so viele Daten wie möglich zwischen Übertragungen sammelt. Dies wirkt sich jedoch nachteilig auf Anwendungen für verteilte Datenbanken aus, weil dadurch in das Netzwerk Verzögerungen eingebaut werden. Der Endbenutzer sieht die Effektivität des Netzwerks nicht, sondern lediglich die Verzögerungen.

Für die meisten Netzwerkeinheiten gibt es Verzögerungsparameter, und die Mehrzahl der Parameter nimmt standardmäßig Werte an, die für verteilte Datenbanken sehr schlecht sind. Sie können die Leistung steigern, indem Sie diese Parameter suchen und, sofern möglich, auf Null setzen. Stellen Sie zudem sicher, daß die Puffergröße für die Einheit groß genug ist, um erneute Übertragungen aufgrund verlorener Daten zu verhindern. Zum Beispiel weisen UNIX-Systeme in der Regel den Standardwert 32 für die Warteschlangenlänge bei Übertragungs- bzw. Empfangsvorgängen auf. Setzen Sie die Warteschlangenlänge zum Erzielen besserer Ergebnisse auf 150. Ein entsprechender Parameter in den DLC-Einstellungen ist die Empfangslänge, die auch auf 150 gesetzt werden sollte.

Der Parameter IOBUF ist an den meisten Standorten zu niedrig eingestellt. Er ist gewöhnlich auf 500 gesetzt. Erfahrungsgemäß eignet sich jedoch der Wert 3992 am besten, wenn Sie große Datenmengen, besonders bei Kanalverbindungen wie ESCON oder 3172, übertragen.

Bei SNA-Verbindungen sollten Sie das Modusprofil jeder Workstation-Software auf 63 setzen. Im allgemeinen sollten die Werte für die Empfangsnachrichtendosierung im gesamten Netzwerk auf den Höchstwert gesetzt werden, d. h. die Parameter VPACING und PACING in der DB2-Anweisung APPL und die PU/LU für die Workstation in einem Hauptmodus für Wählverbindungen sollten ebenfalls auf 63 gesetzt werden. Dadurch kann die Anzahl von Nachrichtenströmen bis zu dem Zeitpunkt anwachsen, an dem der Sender auf eine Antwort warten muß.

In einem LAN-System kann sich die Größe der DLC- oder LLC-Übertragungs- und Empfangsfenster drastisch auf die Leistung auswirken. Der Sendewert sollte auf sieben oder mehr gesetzt werden, und für die meisten Konfigurationen ist ein Empfangswert von vier oder weniger am besten geeignet.

Wenn Sie Ethernet ausführen, sollten Sie die TCP-Segmentgröße auf 1500 Byte setzen. In einem Token-Ring- oder FDDI-Netzwerk sollte dieser Wert 4400 Byte sein, und wenn Sie einen ESCON-Adapter mit TCP/IP verwenden, sollte die Segmentgröße immer 4096 sein.

Schließlich sollte die Größe der Sende- und Empfangspuffer für TCP bei TCP/IP-Netzwerken auf einen höheren Wert als 32768 gesetzt werden. Der Wert 65536 ist im allgemeinen am besten.
Anmerkung:Das Herstellen einer Verbindung vom Gateway zum Server (abgehende Verbindung) ist wesentlich kostenintensiver als das Herstellen einer Verbindung von einem Client zum Gateway (eingehende Verbindung). In einer Umgebung, in der Tausende von Clients häufig über den Gateway eine Verbindung zum Server herstellen und trennen, wird ein hoher Prozentsatz der Verarbeitungszeit für das Herstellen von abgehenden Verbindungen benötigt. DB2 Connect stellt daher einen Verbindungszusammenschluß über TCP/IP bereit. Wenn ein Client das Trennen der Verbindung vom Server anfordert, löscht der Gateway die eingehende Verbindung mit dem Client, beläßt die abgehende Verbindung zum Server jedoch in einem Pool. Wenn ein neuer Client am Gateway eine Verbindung anfordert, stellt der Gateway eine vorhandene Verbindung aus dem Pool bereit. Dadurch wird die Verbindungszeit insgesamt verringert, und es entfällt der hohe CPU-Verbindungsaufwand auf dem Server.

Das Handbuch Systemverwaltung enthält weitere Informationen zum Verbindungszusammenschluß unter DB2.

Die folgende Tabelle ist eine Zusammenfassung der Methoden für die Netzwerkdurchsatzverbesserung.
Kritischer Bereich Beispiel Einstellung Hinweise
Absichtliche Verzögerungen Verzögerungsparameter für Netzwerkeinheiten Auf 0 setzen. Die Standardwerte sind gewöhnlich höher.
Puffer Parameter IOBUF Auf 3992 setzen. Besonders hilfreich für ESCON- oder andere Kanaladapter
RUSIZE Optimale Größe ist 4096. Das Setzen von RUSIZE und RQRIOBLK auf die gleiche Größe ergibt möglicherweise die beste Leistung.
Nachrichtendosierung VPACING, PACING und Modusprofile sollten auf 63 gesetzt werden. Verwenden Sie adaptive Nachrichtendosierung, wo möglich.
Adaptereinstellungen Warteschlangenlänge für Senden/Empfangen Der empfohlene Wert ist 150. Der Standardwert ist gewöhnlich 32.
DLC-Fenstertechnik bei SNA Stellen Sie eine hohe Übertragungsfenstergröße ein (>7). Stellen Sie eine niedrige Empfangsfenstergröße ein (z. B. 1), testen und erhöhen Sie die Zahl wiederholt, bis Sie den Idealwert ermittelt haben. Jede logische Einheit fügt Verzögerungen hinzu. Vereinfachen Sie die Netzwerktopologie so stark wie möglich.
TCP-Einstellungen Segmentgrößen 1500 für Ethernet, 4400 für Token-Ring und FDDI. Für TCP/IP verwendete ESCON-Adapter sollten immer auf 4096 gesetzt werden.
Speicherbereichsgrößen für Senden/Empfangen Sollte für beide 64 KB sein. Der Standardwert für Windows ist nur 8192. Er kann in der Windows-Registrierungsdatenbank eingestellt werden.

Netzwerk-Hardware

Folgende Überlegungen gelten für die Hardware:

Konkurrenzsituationen beim Zugriff auf Systemressourcen

Die Leistung kann sich verschlechtern, wenn viele Tasks im System versuchen, gleichzeitig auf bestimmte Systemressourcen zuzugreifen. Folgende Fragen müssen beantwortet werden:

Fehlerbehebung bei Leistungsproblemen

Wenn DB2 Connect-Benutzer lange Antwortzeiten bei großen Abfragen von Host- oder AS/400-Servern haben, sollten folgende Bereiche auf mögliche Ursachen für das Leistungsproblem untersucht werden:

  1. Für Abfragen, die große Datenblöcke vom Host- oder AS/400-Server (gewöhnlich 32 KB Daten und mehr) zurückgeben, muß sichergestellt werden, daß der Konfigurationsparameter RQRIOBLK des Datenbankmanagers auf 32767 gesetzt ist. Dies kann folgendermaßen mit dem Befehlszeilenprozessor durchgeführt werden:
       db2 update database manager configuration using RQRIOBLK 32767
    
  2. Wird VTAM für die Verbindung zum Host- oder AS/400-Server verwendet, ist der Wert des PACING-Parameters der Konfiguration für "switched major node" zu entnehmen. Prüfen Sie auf der DB2 Connect-Workstation die Kommunikationsdefinition von "LU 6.2 Mode Profile" für die IBMRDB-Modusdefinition. In dieser Definition darf der Wert für den Parameter "Receive pacing window" höchstens dem für VTAM definierten PACING-Wert entsprechen. Ein allgemeiner Wert für "Receive pacing window" auf der DB2 Connect-Workstation und für "PACING" für VTAM ist 8.
  3. Die maximale RU-Größe in der IBMRDB-Modusdefinition muß auf einen geeigneten Wert eingestellt sein. Empfehlenswert sind mindestens 4 KB für Verbindungen mit Token-Ring-Hardware. Für Verbindungen mit Ethernet-Hardware beträgt die maximale Ethernet-Rahmengröße 1536 Byte. Dies kann ein einschränkender Faktor sein.
  4. Wenden Sie sich an den VTAM-Administrator in Ihrer Umgebung, um sicherzustellen, daß VTAM "angepaßte Nachrichtendosierung" in LU-LU-Sitzungen mit Ihrer DB2 Connect-Workstation verwendet.


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