Administration d'applications d'accès aux données

Les tâches d'administration suivantes consistent principalement à configurer des objets (ou ressources) pour permettre aux applications de se connecter à un système dorsal et paramétrer ces ressources pour prendre en charge le nombre de demandes de connexion.

Procédure

  1. Si l'application contient des modules Web ou EJB nécessitant l'accès à un système d'arrière-plan, configurez les ressources en fonction du type de ce système (également appelé EIS, de l'anglais Enterprise Information System).
    • Pour une base de données relationnelle, suivez les étapes indiquées à la rubrique Configuration d'un fournisseur JDBC et d'une source de données. Si vous utilisez une base de données DB2, la rubrique Configuration d'une application pour utiliser PureQuery, constitue une autre option. IBM Optim PureQuery Runtime offre une alternative à JDBC comme moyen d'accès à la base de données DB2.
    • Pour une base de données non relationnelle ou un autre type d'EIS, tel que CICS (Customer Information Control System), vous devez configurer des adaptateurs de ressources et des fabriques de connexions. La rubrique Accès aux données à l'aide des connecteurs JCA (Java EE Connector Architecture) fournit des informations sur la configuration de ces objets.
    Eviter les incidents Eviter les incidents: Lorsque vous spécifiez le nom JNDI (Java™ Naming and Directory Interface) de ressources, respectez les points suivants :
    • N'affectez pas de noms JNDI en double sur différents types de ressource (sources de données par rapport aux fabriques de connexions J2C ou JMS).
    • N'affectez pas de nom JNDI en double à plusieurs ressources d'un même type dans la même portée.
    gotcha
  2. Configurez un alias d'authentification pour la nouvelle ressource de module Web ou EJB uniquement si les connexions au système d'arrière-plan sont authentifiées non pas par WebSphere Application Server, mais par le code de l'application. Cette configuration de sécurité représente une autorisation gérée par composant et est définie dans le descripteur de déploiement d'application sous la forme res-auth = Application.

    L'autorisation gérée par conteneur, qui est définie sous la forme res-auth = Container, indique que le système WebSphere Application Server effectue les ouvertures de session pour les connexions au système dorsal. L'alias d'authentification géré par conteneur doit être défini sur la référence de la ressource de l'application. Cette tâche peut être effectuée lors de l'assemblage ou le déploiement de l'application, avec le mappage de la référence de la ressource à la ressource d'une source de données ou d'une fabrique de connexions. Toutefois, à l'issue du déploiement de l'application, vous pouvez modifier l'alias d'authentification géré par conteneur à l'aide de la console d'administration. Cliquez sur Applications > Applications d'entreprise Websphere > nom_application et sélectionnez le lien de la page de mappage approprié. Par exemple, si vous souhaitez modifier l'alias d'une ressource de module EJB, vous pouvez cliquer sur Mappage des sources de données pour tous les beans CMP 2.x. Pour une ressource de module Web, cliquez sur Références de ressources.

    Pour des références détaillées sur l'authentification des ressources, voir la rubrique relative à la sécurité des connecteurs J2EE.

  3. Si l'application contient un module client qui requiert l'accès aux données, voir la rubrique Configuration de l'accès aux données pour les clients d'applications. Dans cette procédure de configuration unique, vous pouvez définir les données d'authentification pour chaque connexion gérée par composant ou par conteneur.
  4. Spécifiez les paramètres de pool de connections.
  5. Testez une connexion à la nouvelle source de données. Pour plus d'informations sur les méthodes disponibles de test des connexions, reportez-vous à l'article Service de tests de connexions. Cet article mentionne également les paramètres de source de données importants pouvant avoir un impact sur la précision des résultats de vos tests de connexions.
  6. Définissez le service de trace JDBC. Les informations du journal de trace JDBC vient en plus des données de journalisation JVM en cas d'échec de la source de données.

    Pour activer la trace au moyen de la console d'administration, consultez la rubrique Activation de la trace au démarrage du serveur. Spécifiez WAS.database comme groupe de trace et sélectionnez com.ibm.ws.db2.logwriter comme chaîne de trace.

  7. Collectez les statistiques du pool de connexions en activant les compteurs de pool de connexions JDBC ou les compteurs de pool de connexions J2C. Vous pouvez également utiliser les appels de méthode PMI (Performance Monitoring Infrastructure) pour collecter des statistiques de connexion; voir la rubrique Statistiques de connexion et de pool de connexions.
  8. [AIX Solaris HP-UX Linux Windows][z/OS]Adaptez les ressources en fonction du volume des connexions. Voir la rubrique Paramètres de réglage d'accès aux données.
  9. [IBM i]Adaptez la base de données en fonction du volume des connexions. Si vous utilisez DB2 UDB for iSeries, voir la rubrique Remarques sur les performances de la base de données Universal DB2, comme référence de démarrage.
[z/OS]

Résultats

Si votre application z/OS se connecte à une version z/OS de DB2 qui dessert plusieurs versions de plateforme de WebSphere Application Server, l'application z/OS peut conduire à un vidage EC3 pendant l'exécution. Pour résoudre le problème, définissez le paramètre CMTSTAT sur INACTIVE lorsque vous prévoyez d'exécuter les charges de travail distribuées.
Eviter les incidents Eviter les incidents: Dans la version 7.0 de DB2 pour un système z/OS, la valeur par défaut de CMTSTAT est ACTIVE. Pour DB2 Version 9.0 sur un système z/OS, le réglage par défaut est INACTIVE.gotcha
Les charges de travail distribuées sont généralement lourdes. Le réglage CMTSTAT=INACTIVE déclenche la libération, par DB2, des ressources nécessaires pour contrebalancer le drain provoqué par la lourdeur de telles charges de travail. DB2 désactive les unités d'exécution après qu'elles aient validé ou annulé les tâches de la base de données et libéré les curseurs.
Si vous configurez CMTSTAT=INACTIVE, vous devrez peut être également régler les paramètres CONDBAT et MAXDBAT. Essayez la combinaison de valeurs suivante pour optimiser les performances de DB2 et minimiser les demandes de connexions suspendues :
  • Définissez MAXDBAT à une valeur basse, comme par exemple 100, pour que DB2 puisse la prendre en charge en tant qu'unité d'exécution active. MAXDBAT indique le nombre maximum d'unités d'exécution pouvant être actives simultanément et continuant d'exécuter les tâches dans DB2.
  • Définissez CONDBAT à une valeur élevée, comme par exemple 5000. CONDBAT indique le nombre maximum d'unités d'exécution de demandes de connexion que votre serveur DB2 peut recevoir. Lorsque vous définissez CMTSTAT sur INACTIVE, DB2 désactive plusieurs unités d'exécution après avoir satisfait les demandes de connexion initiales. Lorsque le nombre d'unités d'exécution nécessitant un traitement supplémentaire atteint le paramètre MAXDBAT, DB2 peut mettre d'autres unités d'exécution en attente jusqu'à ce qu'il puisse les traiter.

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tdat_daadmin
Nom du fichier : tdat_daadmin.html