Incidents liés à l'accès aux données
Les outils de diagnostic de WebSphere Application Server fournissent des services pour vous aider à résoudre les incidents de connexion de base de données. En outre, le site Web IBM® offre des capacités de recherche souples qui vous permettent de trouver des solutions documentées aux incidents de connexion spécifiques des bases de données.
Les étapes suivantes vous permettent d'isoler rapidement les problèmes de connectivité.
- Parcourez les fichiers journaux du serveur d'applications à la recherche d'indices.
Voir la rubrique Configuration du journal des erreurs.
Voir la rubrique Affichage des fichiers journaux de la machine virtuelle Java. Par défaut, ces fichiers sont racine_serveur_app/nom_serveur/SystemErr.log et SystemOut.log.
Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications. - Recherchez la propriété de la classe auxiliaire pour vérifier qu'elle est correcte et qu'elle correspond au chemin d'accès aux classes de WebSphere Application Server. Les erreurs ou fonctionnements incompréhensibles sont parfois liés à un nom de classe auxiliaire erroné ou manquant. Si WebSphere Application Server ne peut pas charger la classe indiquée, il utilise une classe auxiliaire par défaut qui est peut-être incompatible avec votre gestionnaire de bases de données.
- Vérifiez que le nom JNDI (Java™ Naming and Directory Interface) correspond à celui utilisé par le client que tente d'y accéder. Si les messages d'erreur indiquent que l'incident est peut-être lié à un nom (ils renvoient à un nom de serveur ou un service de nommage, ou l'ID erreur commence par NMSV), voir les rubriques Problèmes de dénomination et Résolution des incidents du service de nommage.
- Activez le traçage pour l'adaptateur de ressources à l'aide de la spécification de trace RRA=all=enabled. Suivez les instructions relatives au vidage et à la consultation des résultats de trace afin d'identifier l'origine de l'incident. Voir la rubrique Activation du traçage.
Pour obtenir une liste complète des conseils de dépannage spécifiques des bases de données, consultez la page du support de produit WebSphere Application Server. (Le lien se trouve à la fin de cet article). Dans la zone Support de recherche, saisissez un nom de fournisseur de base de données dans vos termes de recherche. Sélectionnez Résoudre un problème, puis cliquez sur Rechercher.
Rappelez-vous que vous pouvez toujours trouver des références de support dans l'article du Centre de documentation relatif à l'aide d'IBM pour la résolution des incidents.
Actuellement, ce Centre de documentation fournit un nombre limité de conseils de dépannage pour les bases de données suivantes :
Incidents lors de l'accès aux données
- Erreur "IllegalConnectionUseException"
- WTRN0062E : Tentative illégale d'inscription de plusieurs ressources à capacité de validation en une phase.
- ConnectionWaitTimeoutException.
- com.ibm.websphere.ce.cm.StaleConnectionException : [IBM][pilote CLI] SQL1013N Nom ou alias de base de données "NULL" introuvable. SQLSTATE=42705
- java.sql.SQLException: java.lang.UnsatisfiedLinkError:
- "J2CA0030E : Une méthode d'inscription (enlist) a intercepté une exception java.lang.IllegalStateException" encapsulée dans l'erreur "WTRN0063E : Tentative illégale d'inscription d'une ressource à capacité de validation en une phase auprès d'une transaction impliquant des ressources à validation en deux phases" lors de la tentative d'exécution d'une transaction.
- Exception java.lang.UnsatisfiedLinkError:xaConnect lors de la tentative d'une opération de base de données
- "J2CA0114W : Aucun alias d'authentification géré par conteneur n'a été trouvé pour la fabrique de connexions ou la source de données sourcedonnées" lors de la tentative d'une opération de base de données
- Une erreur est générée si vous utilisez la commande ws_ant pour personnaliser la base de données avec SQLJ (Structured Query Language) dans Java sur les plateformes HP.
- La persistance gérée par bean (CMP) ne peut pas obtenir la fonction d'accès de base de données telle que définie.
IllegalConnectionUseException
Cette erreur peut provenir du fait qu'une connexion obtenue d'une source de données WAS40 est utilisée sur plusieurs unités d'exécution. Or, c'est une violation des règles du modèle de programmation J2EE 1.3 et une exception est donc générée à sa détection sur le serveur. Cet incident touche les utilisateurs qui accèdent à une source de données via des servlets ou des beans enterprise de type BMP (bean-managed persistence).
Pour confirmer le problème, vérifiez le code de partage de la connexion. Ce code peut, par inadvertance, provoquer un partage s'il ne respecte pas les recommandations du modèle de programmation, par exemple en stockant une connexion dans une variable d'instance d'un servlet, ce qui entraîne l'utilisation de la connexion par plusieurs unités d'exécution en même temps.
WTRN0062E : Tentative illégale d"inscription de plusieurs ressources à capacité de validation en une phase
- Tentative de partage d'une connexion à une phase alors que les appels getConnection n'utilisent pas tous les mêmes propriétés de connexion, telles que la propriété AccessIntent.
- Tentative d'obtention de plusieurs connexions non partageables dans une transaction globale alors que la source de données n'est pas une ressource XA.
- Tentative de faire participer une ressource à une phase à une transaction globale
alors qu'une ressource XA ou une autre ressource à une phase a déjà participé
à cette transaction globale. Les informations suivantes peuvent permettre
d'identifier la raison de ce cas d'erreur :
- Si vous utilisez une source de données non XA et que vous prévoyez de partager une connexion, définissez toutes les références de ressource sur partageable. Si vous n'utilisez pas de de référence de ressource, est des connexions non partageables sont utilisées par défaut.
- Votre connexion n'est pas partagée si vous n'utilisez pas les mêmes propriétés de connexion, telles que IsolationLevel ou AccessIntent, pour chaque demande de connexion.
- Il se peut que vous connexions ne soient pas partagées si vous utilisez des beans CMP utilisant peut-être des paramètres AccessIntent différents. Pour en savoir plus sur les beans CMP (Persistance gérée par conteneur) partageant une connexion avec des composants non CMP, reportez-vous aux informations sur les extensions d'API d'accès aux données.
- Vérifiez que le code client a été transmis avec ses demandes getConnection et que celles-ci sont cohérentes entre elles.
- Vérifiez la portée du partage de la connexion
dans la liaison de ressource à l'aide d'un outil d'assemblage. Voir la rubrique relative aux outils d'assemblage.
- Si vous exécutez un environnement de connexion non partageable, vérifiez que votre source de données est de type XA.
- Si vous exécutez un environnement de connexion partageable, vérifiez que toutes les propriétés des connexions, telles que AccessIntent, sont partageables.
- Vérifiez que la classe d'implémentation du fournisseur JDBC indiquée dans la sous-fenêtre Gestion des ressources JDBC de la console d'administration prend en charge les transactions de type XA.
Exception ConnectionWaitTimeoutException lors de l"accès à une source de données ou un adaptateur de ressource
- Le nombre maximum de connexions défini pour un pool donné est trop faible. La demande d'utilisation simultanée des connexions est supérieure à la valeur maximale configurée pour le pool de connexions. La réception régulière de ces exceptions alors que le pourcentage d'utilisation de la CPU n'est pas trop élevé est un signe qu'il s'agit là de l'incident. Cette exception signifie que vous disposez de trop peu de connexions disponibles pour maintenir actives les unités d'exécution du serveur.
- Le délai d'attente de connexion est trop court. La requête en cours de connexions est suffisamment élevée pour que, parfois, aucune connexion ne soit disponible pendant de courts laps de temps. Si la valeur du délai d'attente de votre connexion est trop petite, vous risquez d'être en dépassement de délai avant qu'un utilisateur ne renvoie une connexion dans le pool. Le rallongement du délai d'attente de connexion vous donnera un peu de répit. La réception régulière de ce message d'erreur alors que vous utilisez presque le nombre maximum de connexions sur une longue période est un signe qu'il s'agit là de l'incident.
- Vous ne fermez pas certaines connexions ou vous en renvoyez dans le pool à un rythme lent. Cela peut se produire lorsque vous utilisez des connexions non partageables que vous oubliez de fermer ou que vous fermez longtemps après avoir cessé de les utiliser, ce qui empêche le retour de la connexion dans le pool pour réutilisation. Très vite le pool se vide et toutes les applications reçoivent l'exception ConnectionWaitTimeoutExceptions. Ce problème survient lorsque le pool ne contient plus de connexions et que vous recevez ce message d'erreur lors de la plupart des demandes.
- Vous entraînez plus de charge que le serveur ou le système dorsal n'a de ressources à traiter. Dans ce cas, vous devez déterminer les ressources dont vous avez le plus besoin et mettre les configurations ou le matériel à niveau de façon à répondre à ce besoin. Si le serveur d'applications ou le processeur du serveur de base de données est quasiment occupé à 100 %, c'est un signe que là réside l'incident.
- Modifiez une application de façon à utiliser moins de connexions.
- Fermez correctement les connexions.
- Modifiez les paramètres MaxConnections ou ConnnectionWaitTimeout du pool.
- Adaptez les ressources à leur configuration.
com.ibm.websphere.ce.cm.StaleConnectionException: [IBM][pilote CLI] SQL1013N Nom ou alias de base de données "NULL" introuvable.
com.ibm.websphere.ce.cm.StaleConnectionException: [IBM][pilote CLI] SQL1013N Nom ou alias de base de données "NULL" introuvable. SQLSTATE=42705. Cette erreur se produit lorsqu'une source de données a été définie mais que l'attribut databaseName et la valeur associée n'ont pas été ajoutés au panneau des propriétés personnalisées.
- Cliquez sur dans la console d'administration.
- Sélectionnez le fournisseur_JDBC chargé de la source de données qui pose problème.
- Sélectionnez Sources de données, puis la source liée à l'erreur.
- Sous Propriétés supplémentaires, cliquez sur Propriétés personnalisées.
- Sélectionnez la propriété databaseName ou ajoutez-la si elle n'existe pas, puis entrez le nom la base de données comme valeur de cette propriété.
- Cliquez sur Appliquer ou OK, puis sur Sauvegarder dans la barre de menus.
- Accédez de nouveau à la source de données.
java.sql.SQLException: java.lang.UnsatisfiedLinkError
Cette erreur indique que le répertoire contenant les bibliothèques binaires prenant en charge une base de données ne figure pas dans la variable d'environnement LIBPATH de l'environnement dans lequel WebSphere Application Server est démarré.
Le chemin contenant les bibliothèque du fournisseur de gestionnaire de bases de données varie selon les gestionnaires. L'une des façons de les découvrir consiste à balayer à la recherche de la bibliothèque manquante indiquée dans le message d'erreur. Vous pouvez ensuite rectifier la variable LIBPATH afin qu'elle intègre le répertoire manquant dans le fichier .profile du compte à partir duquel WebSphere Application Server est démarré, ou en ajoutant une instruction dans un fichier .sh qui lance ensuite le programme startServer.
Vous pouvez configurer la propriété Java LIBPATH (java.library.path) à l'aide de la variable d'environnement domaine_region_libpath (par exemple,
control_region_libpath, server_region_libpath ou adjunct_region_libpath). Voir la rubrique consacrée à la modification des valeurs des variables référencées dans les messages BBOM0001I pour savoir comment définir les variables libpath de région.
Erreur J2CA0030E encapsulée dans l'erreur WTRN0063E
"J2CA0030E : Une méthode d'inscription (enlist) a intercepté une exception java.lang.IllegalStateException" encapsulée dans l'erreur "WTRN0063E : Tentative illégale d'inscription d'une ressource à capacité de validation en une phase auprès de deux ressources à validation en deux phases existantes" lors de la tentative d'exécution d'une transaction. Cette erreur peut se produire lorsque le support du dernier participant est manquant ou désactivé. Ce support du dernier participant permet d'inscrire dans une même transaction une ressource en une phase et une ressource à deux phases.
- Les extensions du modèle de programmation WebSphere Application Server ont été installées. Elles sont incluses dans Application Server Integration Server.
- L'option des extensions Integration Server supplémentaires est activée lorsque les extensions du modèle de programmation sont installées. Si vous effectuez une installation normale, cette option est activée par défaut. Si vous effectuez une installation personnalisée, vous pouvez désactiver cette option, ce qui désactive le support du dernier participant.
- L'application faisant appel à la ressource en une phase est déployée avec l'option Accepter les dangers heuristiques activée. Ce déploiement s'effectue à l'aide d'un outil d'assemblage.
Exception java.lang.UnsatisfiedLinkError:xaConnect lors de la tentative d'une opération de base de données
- Le plus souvent, le pilote JDBC qui prend en charge la connectivité à la base de
données est manquant ou la version de ce pilote est incorrecte. Il se peut aussi que les bibliothèques natives prenant en charge le pilote se trouvent dans le chemin de système.
- Pour résoudre cet incident sous Windows, vérifiez que
le fichier JAR du pilote JDBC se trouve dans la variable d'environnement PATH du système :
- Si vous utilisez DB2, vérifiez qu'au moins un produit client
DB2 a été installé sur l'hôte
WebSphere.
- Sur DB2version 7.2 ou une version antérieure, le fichier dans lequel se trouve le produit client, sur WebSphere Application Server est db2java.zip. Vérifiez que le programme usejdbc2.bat a été exécuté après l'installation de la base de données et après toute mise à niveau de la base de données.
- Sur DB2 version 8.1 ou une version ultérieure, utilisez le pilote
de fournisseur JDBC DB2 lors de la définition d'un fournisseur JDBC
dans WebSphere Application Server. Le fichier du pilote est
db2jcc.jar. Si vous utilisez l'option type 2 (par défaut), vérifiez qu'au moins un produit client
DB2 est installé sur l'hôte
WebSphere Application Server. Si vous spécifiez l'option type 4,
il n'est pas nécessaire d'installer le client DB2 mais le fichier
db2jcc.jar doit quand même être présent.
Lors de la spécification de l'emplacement du fichier du pilote, il est recommandé de préciser le chemin et le nom de fichier de l'installation DB2 cible, plutôt que de copier le fichier dans un répertoire local, lorsque cela est possible. Si vous ne le faites pas, vous risquez de rencontrer des difficultés si l'installation DB2 cible est mise à niveau et que le pilote utilisé par WebSphere Application Server ne l'est pas.
- Si vous utilisez DB2, vérifiez qu'au moins un produit client
DB2 a été installé sur l'hôte
WebSphere.
- Sur les systèmes d'exploitation AIX ou
Linux, vérifiez que les bibliothèques natives requises pour
prendre en charge le client de votre base de données sont spécifiées dans la variable d'environnement LD_LIBRARY_PATH du profil du compte sous lequel
WebSphere Application Server démarre. Si vous utilisez DB2 la bibliothèque native est libdb2jdbc.so. Le meilleur moyen de garantir que WebSphere accède correctement à cette bibliothèque consiste à appeler le script db2profile fourni avec DB2 à partir du script .profile du compte (tel que "root") sous lequel WebSphere est exécuté.
- Si vous utilisez DB2 version 7.2 ou une version antérieure, vérifiez que le script usejdbc2,script fourni avec DB2 est appelé à partir du profil du compte sous lequel WebSphere Application Server est démarré.
- Si vous utilisez DB2 version 8.1 ou une version ultérieure, reportez-vous aux instructions précédentes pour le système d'exploitation Windows.
- Pour résoudre cet incident sous Windows, vérifiez que
le fichier JAR du pilote JDBC se trouve dans la variable d'environnement PATH du système :
- Si le gestionnaire de bases de données est DB2, vous pouvez
choisir l'option permettant de créer une instance 64 bits. Une configuration 64 bits n'est pas toujours prise en charge. Si cela se produit, supprimez l'instance de base de données et
créez-en une avec le paramètre par défaut (32 bits).
Si vous utilisez un pilote T2 JDBC Universal, WebSphere Application Server prend en charge l'interaction avec un serveur 64 bits UDB DB2 mais cela doit se faire par l'intermédiaire d'un client 32 bits UDB DB2. L'environnement WebSphere Application Server (CLASSPATH, etc.) doit utiliser le code du client 32 bits pour garantir un bon fonctionnement.
Avec un pilote T4 JDBC Universal, vous n'avez pas besoin du client DB2 32 bits. Il vous suffit de configurer le chemin d'accès aux classes pour inclure db2jcc.jar et ses fichiers de licence dans l'environnement WebSphere Application Server.
Remarque : Pour obtenir de l'aide sur la configuration des pilotes JDBC et des sources de données dans WebSphere Application Server, voir la rubrique Accès aux données à partir des applications.
"J2CA0114W : Aucun alias d'identification par conteneur n'a été trouvé pour la fabrique de connexions ou la source de données source_données" lors d'une opération de base de données
Il est possible que cette erreur se produise dans le fichier SystemOut.log lorsque vous exécutez une application pour accéder à une source de données créée au moyen du script JACL.
$AdminConfig create MappingModule $cmpConnectorFactory "{mappingConfigAlias
DefaultPrincipalMapping} {authDataAlias $authDataAlias}
Pour remédier à ce problème, ajoutez la ligne manquante, puis exécutez de nouveau le script JACL. Pour obtenir un exemple de script JACL, voir la rubrique "Exemple : Création d'un fournisseur JDBC et d'une source de données utilisant l'API Java Management Extensions et l'outil de scriptage".
Une erreur se produit lorsque vous utilisez la commande ws_ant pour personnaliser la base de données pour SQLJ sur les plateformes HP
[java] [ibm][db2][jcc][sqlj]
[java] [ibm][db2][jcc][sqlj] Begin customization
[java] [ibm][db2][jcc][sqlj] encoding not supported!!
Cette erreur peut être provoquée par le fait que vos bases de données ont été créées à l'aide du jeu de caractères HP par défaut. Le pilote JCC (Java Common Client) a besoin du SDK (Software Development Kit) pour effectuer les conversions de page de codes. Toutefois, le kit SDK fourni avec ce logiciel ne prend pas en charge la page de codes HP par défaut.export LANG=en_US.iso88591
Pour accéder aux notes techniques les plus récentes de DB2, accédez au
site de support IBM correspondant au logiciel de gestion d'information.La persistance gérée par bean (CMP) ne peut pas obtenir la fonction d'accès de base de données telle que définie.
Lorsque WebSphere met en cache un code généré accessible dans la base de données de la fabrique de connexions, et si des modifications effectuées dans le fichier d'archive Java (JAR) nécessitent une régénération de l'accès à la base de données, ces modifications prendront effet uniquement lorsque vous aurez arrêté et redémarré le serveur.
- Ajout d'une méthode de recherche personnalisée des beans enterprise ; une exception NullPointerException est alors créée.
- Mise à jour d'une méthode de recherche personnalisée des beans enterprise ; la nouvelle instruction SQL ne s'exécute pas.
- Modification du mappage de modification ; la nouvelle instruction SQL ne s'exécute pas.
En résumé, si vous ajoutez ou mettez à jour un bean enterprise qui contient une méthode de recherche personnalisée, vous devez arrêter et redémarrer le serveur.