Pour éviter ce problème, nous vous recommandons d'importer la base de données avant de déboguer une procédure mémorisée.
Lorsque vous déboguez une procédure mémorisée SQL sur une base de données locale, il est possible que vous receviez l'erreur SQL1224N :
COM.ibm.db2.jdbc.DB2Exception : [IBM][Pilote CLI] SQL1224N Un agent de base de données n'a pas pu être lancé pour répondre à une requête ou a été arrêté par un arrêt du système de bases de données ou une commande forcée. SQLSTATE=55032
Il s'agit d'un problème lié au noyau Linux (bogue Bugzilla #351 du noyau Linux). Les instructions suivantes permettent de résoudre le problème en utilisant la méthode de connexion TCPIP DB2 (en tant que boucle) au lieu de l'interface CLI (Call Level Interface). Cette procédure permet au débogueur d'utiliser le même alias de base de données que précédemment :
Pour effectuer les étapes 2 à 7, vous devez vous connecter en tant que propriétaire de l'instance DB2.
db2set db2comm
Si la sortie ne contient pas le mot-clé tcpip, vous devez saisir la commande suivante pour mettre à jour la variable de registre db2comm afin qu'elle inclue tcpip :
db2set db2comm=<noms des protocoles existants>,tcpip
La variable du registre db2comm détermine quel gestionnaire de connexion de protocole va être activé au démarrage du gestionnaire de bases de données. Vous pouvez définir cette variable pour plusieurs protocoles de communication en séparant les mots-clés par des virgules. Par exemple, db2set db2comm=tcpip,appc.
Vous devez relancer la commande db2start pour démarrer les gestionnaires de connexion pour les protocoles spécifiés dans le paramètre de registre db2comm. DB2 sera redémarré à l'étape 7 ; il n'est donc pas utile de le faire ici.
.Pour vérifier le paramétrage actuel de SVCENAME, saisissez la commande suivante :
db2 get dbm cfg | grep -i svcename
Si vous devez mettre à jour le paramétrage de SVCENAME, saisissez la commande suivante :
db2 update dbm cfg using svcename <nom du service de connexion>
où <nom du service de connexion> respecte la casse et doit correspondre au nom du port de service indiqué dans /etc/services (par exemple, db2 update dbm cfg using svcename db2c_db2inst1).
La mise a jour de la configuration du gestionnaire de bases de données ne sera effective qu'au prochain recours à la prochaine commande db2start. Cette opération est décrite à l'étape 7 ci-après.
db2 catalog tcpip node <nom du noeud> remote <nom de l'hôte> server <nom du service de connexion>
où,
Pour vérifier que la commande de catalogue a correctement fonctionné, saisissez la commande suivante :
db2 list node directory
Voici un exemple de sortie de cette commande (les lignes vides ont été supprimées pour plus de lisibilité) :
Node Directory Number of entries in the directory = 1 Node 1 entry: Node name = MYNODE Comment = Protocol = TCPIP Hostname = 127.0.0.1 Service name = db2c_db2inst1
Par exemple :db2 catalog db WAS as WASLOOP db2 uncatalog db WAS db2 catalog db WASLOOP as WAS at node MYNODE
Remarques :
Exemple de sortie pour les étapes 5a à 5c
Avant l'étape 5a, une base de données appelée WAS a déjà été créée. La sortie de la commande db2 list db directory est similaire à l'exemple suivant :
System Database Directory Number of entries in the directory = 1 Database 1 entry: Database alias = WAS Database name = WAS Local database directory = /home/ctsui Database release level = 9.00 Comment = Directory entry type = Indirect Catalog node number = 0
Après l'étape 5a, la sortie de db2 list db directory est similaire à l'exemple suivant :
System Database Directory Number of entries in the directory = 2 Database 1 entry: Database alias = WAS Database name = WAS Local database directory = /home/ctsui Database release level = 9.00 Comment = Directory entry type = Indirect Catalog node number = 0 Database 2 entry: Database alias = WASLOOP Database name = WAS Local database directory = /home/ctsui Database release level = 9.00 Comment = Directory entry type = Indirect Catalog node number = 0
Après l'étape 5b, la sortie de db2 list db directory est similaire à l'exemple suivant :
System Database Directory Number of entries in the directory = 1 Database 1 entry: Database alias = WASLOOP Database name = WAS Local database directory = /home/ctsui Database release level = 9.00 Comment = Directory entry type = Indirect Catalog node number = 0
Après l'étape 5c, la sortie de db2 list db directory est similaire à l'exemple suivant :
System Database Directory Number of entries in the directory = 2 Database 1 entry: Database alias = WAS Database name = WASLOOP Node name = MYNODE Database release level = 9.00 Comment = Directory entry type = Remote Catalog node number = -1 Database 2 entry: Database alias = WASLOOP Database name = WAS Local database directory = /home/ctsui Database release level = 9.00 Comment = Directory entry type = Indirect Catalog node number = 0
Pour vérifier que la commande catalog db a correctement fonctionné, saisissez les deux commandes suivantes (et consultez les deux exemples de sortie suivants) :
db2 connect to wasloop db2 connect to was
où db2 connect to wasloop doit imprimer les informations de connexion et db2 connect to was doit renvoyer SQL1403N.
Voici un exemple de sortie de db2 connect to wasloop :
Database Connection Information System Database Directory Database server = DB2/6000 6.1.0 SQL authorization ID = CTSUI Local database alias = WASLOOP
Voici un exemple de sortie de db2 connect to was :
Database Connection Information System Database Directory Database server = DB2/6000 6.1.0 SQL authorization ID = CTSUI Local database alias = WAS
db2 update dbm cfg using authentication client
Pour vérifier que la commande a correctement fonctionné, affichez le nouveau paramètre en utilisant la commande suivante :
db2 get dbm cfg
Exemple de sortie :
.... Authentification du gestionnaire de bases de données (AUTHENTICATION) = CLIENT ....
db2stop db2start
Remarque : il peut être nécessaire d'utiliser db2stop force pour fermer toutes les connexions de bases de données actives.
par exemple,db2 attach to MYNODE user myid using mypasswd db2 drop db WAS