Limites du débogage de routines

Cette page présente les limites que vous pouvez rencontrer lors du débogage de routines et les méthodes palliatives. Consultez également le readme du produit, qui peut indiquer des limitations supplémentaires pour ce débogueur.

Propriétés générales

Voir aussi Known problems with the Routine debugger for updates.

Noms de routines délimités
Le débogueur de routines prend en charge ces dernières de façon limitée, avec un schéma ou des noms de routines délimitées. De telles routines doivent être lancées à partir de la boîte de dialogue des configurations de lancement Déboguer, et non à partir du menu contextuel de la vue Définition de données.
Activation des actions d'avance pas à pas
Lorsqu'une session de débogage démarre, si les boutons d'action d'avance pas à pas (comme le bouton Avance d'un pas sans entrée) ne sont pas activés, sélectionnez le cadre de pile supérieur pour activer les boutons.
Gestionnaire de session
Utilisez le gestionnaire de session fourni avec le produit. Le gestionnaire de sessions peut figurer sur le serveur, le réseau ou le client. La procédure suivante présente la configuration du gestionnaire de sessions sur le client (gestionnaire inclus dans le produit). Cette instruction ne s'applique pas aux configurations PL/SQL DB2 et Oracle.
  1. Ouvrez une fenêtre de commandes, puis modifiez le répertoire d'installation du produit. Par défaut, sous Windows, le produit est installé dans le répertoire C:\Program Files\IBM\SDP70.
  2. Exécutez db2dbgm.bat à partir de la fenêtre de commandes, puis notez l'adresse IP et le numéro de port du gestionnaire de sessions.
  3. Démarrez le plan de travail, puis modifiez les préférences du débogueur pour utiliser le gestionnaire de sessions local :
    1. Cliquez sur Fenêtre > Préférences, développez le noeud Exécuter/Déboguer, puis cliquez sur DB2 Routine Debugger.
    2. Dans le panneau Débogueur, sélectionnez Utiliser un gestionnaire de sessions déjà actif.
    3. Dans la zone Hôte, indiquez l'adresse IP de la machine. L'adresse IP s'obtient également à partir de la fenêtre de commandes ou de terminal dans laquelle est exécuté le gestionnaire de sessions.
    4. Dans la zone Port, indiquez le port du gestionnaire de session local. Par défaut, le numéro de port est : 4554. Le numéro de port s'obtient également à partir de la fenêtre de commandes ou de terminal dans laquelle est exécuté le gestionnaire de sessions.
Noms de variables
Les noms de variables contenant des guillemets ne sont pas pris en charge pour le débogage de routines sur les bases de données DB2 for Linux, Unix, and Windows.
Points d'arrêt
Pour Optim Development Studio Version 2.2.1.1, les points d'arrêt individuels ne peuvent pas être désactivés.
Fonctions disponibles uniquement sur les bases de données DB2 for Linux, UNIX, and Windows Version 10.1 Fix Pack 2 ou version ultérieure
Ces fonctions de débogage sont disponibles uniquement lors du débogage de routines sur une base de données DB2 for Linux, UNIX, and Windows Version 10.1 Fix Pack 2 ou version ultérieure :
  • Débogage de routines déclarées
  • Débogage de déclencheurs
  • Débogage de blocs anonymes PL/SQL
  • Démarrage du débogueur depuis l'éditeur SQL et XQuery
  • Définition de points d'arrêt permanents dans l'éditeur de routines
  • Recompilation de routines avec l'option de débogage sans redéployer la routine
  • Affichage des types suivants de variables dans la vue Variables :
    • Variables globales et de package
    • Tableaux associatifs
    • Matrice de lignes
Variables matricielles
Le débogueur de routines répertorie uniquement les 100 000 premiers éléments d'une variable matricielle dans la vue Variables.
Rôle DB2 SYSDEBUG
Pour déboguer des routines déployées sur une base de données DB2 for Linux, UNIX, and Windows Version 10.1 Fix Pack 2 ou version ultérieure, l'ID de l'utilisateur de base de données déployant la routine doit être membre du rôle SYSDEBUG.

Routines SQL et Java

Déclencheurs

Lors du débogage de déclencheurs dans une base de données DB2, vous ne pouvez déboguer qu'un seul déclencheur à la fois. Le débogage de deux ou plusieurs déclencheurs de manière simultanée n'est pas pris en charge.

Types de données PL/SQL et Oracle

Voir Types de données PL/SQL et Oracle non pris en charge par le débogueur de routines.

Routines PL/SQL

Limite Oracle

Lorsqu'une procédure de débogage est de type CURSOR et qu'elle s'arrête à un point d'arrêt au cours de la procédure, si vous cliquez sur Terminer, l'entrée de la vue de sortie se bloque parfois. Pour contourner cette limite, cliquez sur Reprendre au lieu de Terminer.

Limites Informix

La liste suivante décrit les limites lors du débogage de procédures mémorisées sur une base de données Informix :
  • Lors du débogage d'une procédure mémorisée sur une base de données Informix, vous pouvez utiliser le débogueur intégré ou un gestionnaire de session déjà en cours d'exécution. La préférence par défaut pour l'exécution du gestionnaire de session sur chaque serveur connecté n'est pas prise en charge.

    Pour modifier la préférence pour l'emplacement du gestionnaire de session du débogueur de routines, sélectionnez Fenêtre > Préférences. Dans Préférences, choisissez Exécuter/Déboguer > Débogueur de routines pour sélectionner les préférences de débogage. Sélectionnez le serveur de base de données des routines à déboguer. Dans la section Emplacement du gestionnaire de session de débogage de routine, sélectionnez Utiliser le gestionnaire de sessions intégré ou Utiliser un gestionnaire de sessions déjà actif.

  • Dans la vue Explorateur de projets de données, si vous cliquez avec le bouton droit de la souris sur une procédure mémorisée Informix et que la base de données Informix est déconnectée, le débogage n'est pas activé. Pour activer le débogage, connectez-vous à la base de données. Vous pouvez également déboguer la procédure mémorisée depuis la vue Explorateur de sources de données.

Limitation Linux

Lorsque vous déboguez une routine sur une base de données DB2 locale, il est possible que le numéro d'erreur SQL1224N s'affiche :

COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL1224N Un agent de base de données n'a pas pu être démarré pour satisfaire une demande ou a été interrompu à la suite d'un arrêt normal du système ou d'une commande FORCE. SQLSTATE=55032

Cette erreur est due à un problème qui survient dans le noyau Linux (problème Bugzilla lié au noyau Linux / bogue n°351). Les instructions suivantes permettent d'appliquer une solution palliative qui utilise la méthode de connexion TCPIP de DB2 (comme bouclage) au lieu de l'interface CLI (Call Level Interface). Dans cette procédure, le débogueur utilise le même alias de base de données que précédemment :

  1. Si aucun port n'a été défini pour les clients DB2 éloignés, connectez-vous en tant que root et créez un port TCP/IP dans /etc/services (db2c_db2inst1 50000/tcp par exemple). Vous pouvez aussi utiliser le centre de contrôle pour créer un port TCP/IP (en définissant les propriétés de communication pour l'instance de base de données). Vous pouvez utiliser un port existant pour les clients DB2 éloignés.

    Les étapes 2 à 7 requièrent que vous vous connectiez en tant que propriétaire de l'instance DB2.

  2. Configurez le gestionnaire de la base de données de sorte qu'il démarre le gestionnaire de connexions pour le protocole de communication TCP/IP. Si vous ne savez pas si cette opération a déjà été effectuée, émettez la commande suivante :
    db2set db2comm

    Si la sortie ne contient pas le mot clé tcpip, vous devez entrer la commande suivante pour mettre à jour la variable de registre db2comm afin d'inclure tcpip :

    db2set db2comm=<noms des protocoles existants>,tcpip

    La variable de registre db2comm détermine quel gestionnaire de connexions de protocole est activé lorsque le gestionnaire de la base de données est démarré. Vous pouvez définir cette variable pour plusieurs protocoles de communication en séparant les mots clés par une virgule.

    Vous devez émettre à nouveau la commande db2start afin de démarrer les gestionnaires de connexions pour les protocoles spécifiés par le paramètre de registre db2comm. Vous allez redémarrer DB2 à l'étape 7 ; il n'est donc pas nécessaire d'effectuer cette opération maintenant.

    .
  3. Mettez à jour le paramètre de configuration du gestionnaire de la base de données SVCENAME avec le nom du service de connexion défini dans /etc/services (étape 1).

    Pour consulter la valeur actuelle de SVCENAME, entrez la commande suivante :

    db2 get dbm cfg | grep -i svcename

    Si vous devez mettre à jour la valeur de SVCENAME, entrez la commande suivante :

    db2 update dbm cfg using svcename <nom du service de connexion>

    où la distinction minuscules/majuscules est appliquée au <nom du service de connexion> et où cette valeur correspond au nom du port du service que vous avez placé dans /etc/services (par exemple db2 update dbm cfg using svcename db2c_db2inst1).

    La mise à jour de la configuration du gestionnaire de la base de données n'est pas appliquée tant qu'une nouvelle commande db2start n'a pas été émise. Vous effectuerez cette opération à l'étape 7.

  4. Cataloguez le noeud de bouclage en entrant la commande suivante :
    db2 catalog tcpip node <nom_noeud> remote <nom_hôte> server <nom du service de connexion>

    • <nom_noeud> est un alias local pour le noeud à cataloguer. Il s'agit d'un nom arbitraire sur le poste de travail, utilisé pour identifier le noeud (par exemple db2 catalog tcpip node mynode remote 127.0.0.1 server db2c_db2inst1).
    • <nom_hôte> est le nom de la machine sur laquelle DB2 est installé. Lorsque vous spécifiez le nom d'hôte, vous devez indiquer le nom exact de la machine et distinguer les minuscules des majuscules. Si vous ne savez pas quel est le nom de la machine, consultez le centre de contrôle.

    Pour vérifier que la commande catalog a abouti, émettez la commande suivante :

    db2 list node directory

    Exemple de sortie de cette commande (les lignes vierges ont été supprimées pour une meilleure lisibilité) :

    Répertoire des noeuds
    Nombre d'entrées dans le répertoire = 1
    Entrée du noeud 1 :
    Nom du noeud = MYNODE
    Commentaire =
    Protocole = TCPIP
    Nom d'hôte = 127.0.0.1
    Nom de service = db2c_db2inst1
  5. Cataloguez la base de données conformément aux instructions ci-après. Les commandes suivantes permettent de générer une sortie exemple pour faire le suivi des effets de chaque commande :
    1. db2 catalog db <nom de la base de données> as <alias de la base de données>
    2. db2 uncatalog db <nom de la base de données>
    3. db2 catalog db <alias de la base de données as <nom de la base de données> at node <nom du noeud>
    Exemple :
    db2 catalog db WAS as WASLOOP
    db2 uncatalog db WAS
    db2 catalog db WASLOOP as WAS at node MYNODE

    Remarques :

    • L'alias de base de données peut correspondre à n'importe quel nom de votre choix mais il ne peut pas être identique au nom de la base de données. Il ne peut pas comporter plus de 8 caractères.
    • L'erreur SQL1334N s'affiche si vous n'avez pas catalogué la base de données correctement.
    • Répétez les étapes 5a à 5c pour chaque base de données dans laquelle vous souhaitez déboguer une routine.

    Sortie exemple pour les étapes 5a à 5c

    Une base de données locale appelée WAS a été créée avant l'étape 5a. La sortie de la commande db2 list db directory est similaire au message suivant :

    Répertoire système des bases de données
    Nombre d'entrées dans le répertoire = 1
    
    Entrée de la base de données 1 :
    
    Alias de la base de données = WAS
    Nom de la base de données = WAS
    Répertoire des bases de données locales = /home/ctsui
    Niveau d'édition de la base de données = 9.00
    Commentaire =
    Type d'entrée du répertoire = Indirect
    Numéro de noeud catalogue = 0

    Après l'étape 5a, la sortie de la commande db2 list db directory est similaire au message suivant :

    Répertoire système des bases de données
    Nombre d'entrées dans le répertoire = 2
    
    Entrée de la base de données 1 :
    
    Alias de la base de données = WAS
    Nom de la base de données = WAS
    Répertoire des bases de données locales = /home/ctsui
    Niveau d'édition de la base de données = 9.00
    Commentaire =
    Type d'entrée du répertoire = Indirect
    Numéro de noeud catalogue = 0
    
    Entrée de la base de données 2 :
    
    Alias de la base de données = WASLOOP
    Nom de la base de données = WAS
    Répertoire des bases de données locales = /home/ctsui
    Niveau d'édition de la base de données = 9.00
    Commentaire =
    Type d'entrée du répertoire = Indirect
    Numéro de noeud catalogue = 0

    Après l'étape 5b, la sortie de la commande db2 list db directory est similaire au message suivant :

    Répertoire système des bases de données
    Nombre d'entrées dans le répertoire = 1
    
    Entrée de la base de données 1 :
    
    Alias de la base de données = WASLOOP
    Nom de la base de données = WAS
    Répertoire des bases de données locales = /home/ctsui
    Niveau d'édition de la base de données = 9.00
    Commentaire =
    Type d'entrée du répertoire = Indirect
    Numéro de noeud catalogue = 0

    Après l'étape 5c, la sortie de la commande db2 list db directory est similaire au message suivant :

    Répertoire système des bases de données
    Nombre d'entrées dans le répertoire = 2
    
    Entrée de la base de données 1 :
    
    Alias de la base de données = WAS
    Nom de la base de données = WASLOOP
    Nom du noeud = MYNODE
    Niveau d'édition de la base de données = 9.00
    Commentaire =
    Type d'entrée du répertoire = Remote
    Numéro de noeud catalogue = -1
    
    Entrée de la base de données 2 :
    
    Alias de la base de données = WASLOOP
    Nom de la base de données = WAS
    Répertoire des bases de données locales = /home/ctsui
    Niveau d'édition de la base de données = 9.00
    Commentaire =
    Type d'entrée du répertoire = Indirect
    Numéro de noeud catalogue = 0

    Pour vérifier que la commande catalog db a abouti, émettez les deux commandes suivantes (et consultez la sortie exemple ci-dessous) :

    db2 connect to wasloop
    db2 connect to was

    db2 connect to wasloop émet une sortie des informations de connexion et db2 connect to was génère le message SQL1403N.

    Sortie exemple de db2 connect to wasloop :

    Informations de connexion à la base de données
    Répertoire système des bases de données
    
    Serveur de base de données = DB2/6000 6.1.0
    ID utilisateur SQL = CTSUI
    Alias local de la base de données = WASLOOP

    Sortie exemple de db2 connect to was:

    Informations de connexion à la base de données
    Répertoire système des bases de données
    
    Serveur de base de données = DB2/6000 6.1.0
    ID utilisateur SQL = CTSUI
    Alias local de la base de données = WAS
  6. Mettez à jour le mécanisme d'authentification en indiquant l'authentification client. Entrez la commande suivante :
    db2 update dbm cfg using authentication client

    Pour vérifier que la commande a abouti, affichez le nouveau paramètre avec la commande suivante :

    db2 get dbm cfg

    Sortie exemple :

    ....
    Authentification du gestionnaire de BDD     (AUTHENTICATION) = CLIENT
    ....
  7. Redémarrez DB2 pour actualiser la mémoire cache des répertoires. Exemple :
    db2stop
    db2start

    Remarque : il se peut que vous deviez utiliser db2stop force pour fermer toutes les connexions de base de données actives.

  8. Pour WAS, il n'est pas nécessaire de mettre à jour le fichier admin.config. Dans le cas d'une application WebSphere, il n'est pas nécessaire de changer la configuration de la source de données existante.
  9. Pour supprimer la base de données, émettez les commandes suivantes :
    1. db2 attach to <nom_noeud> user <id_utilisateur> using <mot_de_passe>
    2. db2 drop db <nom_base_de_données>
      Exemple :
      db2 attach to MYNODE user myid using mypasswd
      db2 drop db WAS

Commentaires