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.

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.

Les étapes suivantes vous permettent d'isoler rapidement les problèmes de connectivité.

  1. Parcourez les fichiers journaux du serveur d'applications à la recherche d'indices.

    [z/OS]Voir la rubrique Configuration du journal des erreurs.

    [AIX Solaris HP-UX Linux Windows][IBM i]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.
  2. 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.
  3. 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.
  4. 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 :

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

Cette erreur se produit dans l'un des cas suivants :
  • 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.
Pour rectifier cette erreur, procédez comme suit :
  • 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

Si votre application reçoit des exceptions telles que com.ibm.websphere.ce.cm.ConnectionWaitTimeoutException ou com.ibm.websphere.ce.j2c.ConnectionWaitTimeoutException lorsqu'elle tente d'accéder à une source de données WebSphere Application Server ou à un adaptateur de ressource compatible JCA, les causes possibles sont les suivantes :
  • 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.
Pour résoudre ces incidents, procédez comme suit :
  • 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.

Pour ajouter la propriété databaseName, procédez comme suit :
  1. Cliquez sur Ressources > Gestion des fournisseurs JDBC dans la console d'administration.
  2. Sélectionnez le fournisseur_JDBC chargé de la source de données qui pose problème.
  3. Sélectionnez Sources de données, puis la source liée à l'erreur.
  4. Sous Propriétés supplémentaires, cliquez sur Propriétés personnalisées.
  5. 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é.
  6. Cliquez sur Appliquer ou OK, puis sur Sauvegarder dans la barre de menus.
  7. 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.

[z/OS]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.

Ce support n'est disponible que si les points suivants sont respectés :
  • 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.

"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.

Ce message d'erreur s'affiche car le script JACL n'a pas défini d'alias d'identification par conteneur pour la fabrique de connexions CMP. Dans le script JACL, il manque la ligne suivante :
$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

Si vous utilisez la commande ws_ant pour la personnalisation de base de données avec SQLJ (Structured Query Language) dans Java sur des plateformes HP, il se peut qu'une erreur semblable à ce qui suit soit générée :
[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.
Avant de créer les bases de données, il vous faut régler la variable d'environnement local LANG sur ISO. Elle doit être similaire à la chaîne suivante :
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.

Voici des exemples susceptibles de provoquer cette erreur :
  • 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.


Icône indiquant le type de rubrique Rubrique de référence



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=rtrb_dsaccess
Nom du fichier : rtrb_dsaccess.html