Anwendungen für Datenzugriff verwalten

Die folgenden Verwaltungstasks beziehen sich hauptsächlich auf die Konfiguration der Objekte oder Ressourcen, die Anwendungen mit einem Back-End verbinden, und auf die Optimierung dieser Ressourcen für die Bewältigung der eingehenden Verbindungsanforderungen.

Vorgehensweise

  1. Wenn Ihre Anwendung Webmodule oder EJB-Module enthält, die Zugriff auf ein Back-End erfordern, konfigurieren Sie die Ressourcen entsprechend des Typs Ihres unternehmensweiten Informationssystems:
    • Für eine relationale Datenbank führen Sie die Schritte aus, die im Artikel "JDBC-Provider und Datenquelle konfigurieren" beschrieben sind. Wenn Sie eine DB2-Datenbank verwenden, können Sie auch den Artikel "Anwendungsserver für die Verwendung von pureQuery konfigurieren" zu Rate ziehen. IBM Optim PureQuery Runtime ist hinsichtlich des Zugriffs auf die DB2-Datenbank eine Alternative zu JDBC.
    • Für eine nicht relationale Datenbank oder einen anderen Typ von unternehmensweitem Informationssystem, wie z. B. Customer Information Control System (CICS), müssen Sie einen Ressourcenadapter und Verbindungsfactorys konfigurieren. Der Artikel zum Zugriff auf Daten mit einem JCA-Connector enthält Informationen zum Konfigurieren dieser Objekte.
    Fehler vermeiden Fehler vermeiden: Beachten Sie beim Angeben des JNDI-Namens (Java Naming and Directory Interface) für Ressourcen die folgenden Anforderungen:
    • Verwenden Sie für unterschiedliche Ressourcentypen nicht dieselben JNDI-Namen (z. B. für Datenquellen und J2C-Verbindungsfactorys oder JMS-Verbindungsfactorys).
    • Verwenden Sie für mehrere Ressourcen desselben Typs in demselben Geltungsbereich nicht denselben JNDI-Namen.
    gotcha
  2. Konfigurieren Sie einen Authentifizierungsalias für die neue Webmodul- oder EJB-Modulressource nur dann, wenn der Anwendungscode und nicht WebSphere Application Server Verbindungen zum Back-End authentifiziert. Diese Sicherheitskonfiguration wird als komponentengesteuerte Berechtigung bezeichnet und wird im Implementierungsdeskriptor der Anwendung mit res-auth = Application definiert.

    Bei der containergesteuerten Berechtigung, die mit res-auth = Container definiert wird, führt Application Server die Anmeldung für Back-End-Verbindungen durch. Der Alias für containergesteuerte Authentifizierung muss in der Referenz auf die Anwendungsressource angegeben werden. Diese Task kann während der Anwendungsassemblierung oder -implementierung zusammen mit der Zuordnung der Ressourcenreferenz zu einer Datenquellen- oder Verbindungsfactory-Ressource ausgeführt werden. Nach der Anwendungsimplementierung können Sie den Alias für containerstützte Authentifizierung in der Administrationskonsole ändern. Klicken Sie auf Anwendungen > Websphere-Unternehmensanwendungen > Anwendungsname, und wählen Sie den Link zur entsprechenden Zuordnungsseite aus. Wenn Sie beispielsweise den Alias einer EJB-Modulressource ändern möchten, können Sie auf Datenquellen für alle 2.x-CMP-Beans zuordnen klicken. Für eine Webmodulressource klicken Sie auf Ressourcenreferenzen.

    Ausführliche Referenzinformationen zur Ressourcenauthentifizierung finden Sie im Artikel zur J2EE-Connector-Sicherheit.

  3. Wenn Ihre Anwendung ein Clientmodul enthält, das Datenzugriff erfordert, lesen Sie den Artikel "Datenzugriff für Anwendungsclients konfigurieren". In diesem einen Konfigurationsprozess können Sie Authentifizierungsdaten für komponenten- oder containergesteuerte Anmeldung definieren.
  4. Geben Sie die Einstellungen für den Verbindungspool an.
  5. Testen Sie eine Verbindung zur neuen Datenquelle. Weitere Informationen zu den verfügbaren Methoden für das Testen von Verbindungen finden Sie im Artikel zum Service für Verbindungstests. Dieser Artikel beschreibt außerdem wichtige Datenquelleneinstellungen, die sich auf die Genauigkeit ihrer Verbindungstestergebnisse auswirken.
  6. Definieren Sie den JDBC-Trace-Service. Die JVM-Protokolldaten werden bei Datenquellenfehlern um JDBC-Traceprotokolldaten erweitert.

    Informationen zum Aktivieren dieser Traceerstellung über die Administrationskonsole finden Sie im Artikel "Traceerstellung beim Serverstart aktivieren". Geben Sie WAS.database als Tracegruppe an, und wählen Sie com.ibm.ws.db2.logwriter als Tracezeichenfolge aus.

  7. Erfassen Sie die Verbindungspoolstatistiken, indem Sie die JDBC-Verbindungspoolzähler bzw. J2C-Verbindungspoolzähler aktivieren. Alternativ können Sie PMI-Methodenaufrufe (Performance Monitoring Infrastructure) verwenden, um Verbindungsstatistiken zu erfassen. Weitere Informationen finden Sie im Artikel zu den Verbindungs- und Verbindungspoolstatistiken.
  8. [AIX Solaris HP-UX Linux Windows][z/OS]Optimieren Sie die Ressourcen für das Aufkommen der Verbindungsanforderungen. Weitere Informationen finden Sie im Artikel zu den Optimierungsparametern für den Datenzugriff.
  9. [IBM i]Optimieren Sie Ihre Datenbank für das Verbindungsaufkommen. Wenn Sie DB2 UDB for iSeries verwenden, können Sie den Artikel "Leistungstipps für DB2 Universal Database" als Ausgangspunkt verwenden.
[z/OS]

Ergebnisse

Wenn Ihre z/OS-Anwendung eine Verbindung zu einer z/OS-Version von DB2 herstellt, die mehrere Plattformenversionen von WebSphere Application Server bedient, wird zur Laufzeit möglicherweise ein EC3-Speicherauszug für die z/OS-Anwendung erstellt werden. Zur Behebung des Problems setzen Sie den Parameter CMTSTAT auf INACTIVE, wenn Sie mit verteilten Workloads arbeiten möchten.
Fehler vermeiden Fehler vermeiden: Für DB2 Version 7.0 auf einem z/OS-System hat CMTSTAT standardmäßig den Wert ACTIVE. Für DB2 Version 9.0 auf einem z/OS-System ist die Standardeinstellung INACTIVE.gotcha
Verteilte Workloads sind gewöhnlich sehr groß. Die Einstellung CMTSTAT=INACTIVE bewirkt, dass DB2 Ressourcen freigibt, um der Belastung entgegenzuwirken, die durch große Workloads entstehen können. DB2 inaktiviert Threads, nachdem diese Threads Datenbanktasks erfolgreich festgeschrieben oder rückgängig gemacht haben, und gibt die Cursor frei.
Wenn Sie CMTSTAT=INACTIVE definieren, müssen Sie unter Umständen auch die Parameter CONDBAT und MAXDBAT anpassen. Probieren Sie die folgende Kombination von Werten aus, um die Leistung von DB2 zu maximieren und ausgesetzte Verbindungsanforderungen zu minimieren:
  • Setzen Sie MAXDBAT auf eine kleine Zahl, z. B. 100, die DB2 als aktive Threads unterstützen kann. MAXDBAT gibt die maximale Anzahl an Threads an, die gleichzeitig aktiv sein und Tasks in DB2 ausführen können.
  • Setzen Sie CONDBAT auf eine höhere Zahl, z. B. 5000. CONDBAT gibt die maximale Anzahl an Verbindungsanforderungsthreads an, die Ihr DB2-Server empfangen kann. Wenn Sie CMTSTAT auf INACTIVE setzen, inaktiviert DB2 viele Threads nach der Abschluss der einleitenden Verbindungsanforderungen. Wenn die Anzahl der Threads, die eine weitere Verarbeitung erfordern, die MAXDBAT-Einstellung erreicht, kann DB2 weitere Threads in die Warteschlange einreihen, bis diese bearbeitet werden können.

Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tdat_daadmin
Dateiname:tdat_daadmin.html