Para evitar este problema, es aconsejable importar la base de datos antes de depurar un procedimiento almacenado.
Si está depurando un procedimiento almacenado SQL en una base de datos local, es posible que reciba el número de error SQL1224N:
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL1224N No ha podido iniciarse un agente de bases de datos para dar servicio a una petición, o ha finalizado como resultado del cierre del sistema de bases de datos o de un mandato de forzado. SQLSTATE=55032
Esto se debe a un problema en el kernel Linux (Linux kernel Bugzilla bug #351). Las instrucciones siguientes indican una solución que utiliza el método de conexión TCPIP de DB2 (como bucle de retorno) en lugar de CLI (Interfaz a nivel de llamada). Este procedimiento permitirá al depurador utilizar el mismo alias de base de datos que antes:
Para los pasos 2 a 7 que se indican a continuación, es necesario iniciar la sesión como DB2.
db2set db2comm
Si la salida no contiene la palabra clave tcpip, es necesario especificar el mandato siguiente para actualizar la variable de registro db2comm a fin de que incluya tcpip:
db2set db2comm=<nombres de protocolo existentes>,tcpip
La variable de registro db2comm determina el gestor de conexiones del protocolo que se habilitará cuando se inicie el gestor de bases de datos. Puede establecer esta variable para varios protocolos de comunicaciones separando las palabras clave mediante comas, por ejemplo, db2set db2comm=tcpip,appc.
Es necesario volver a emitir el mandato db2start para poder iniciar los gestores de conexiones para los protocolos especificados en el parámetro de registro db2comm. Dado que reiniciaremos DB2 en el paso 7, no es necesario hacerlo ahora.
.Para comprobar el valor actual de SVCENAME, especifique el siguiente mandato:
db2 get dbm cfg | grep -i svcename
Si necesita actualizar el valor de SVCENAME, especifique el siguiente mandato:
db2 update dbm cfg using svcename <nombre_servicio_conexiones>
donde el <nombre_servicio_conexiones> es sensible a mayúsculas y minúsculas y debe coincidir con el nombre del puerto de servicio que ha indicado en /etc/services (por ejemplo, db2 update dbm cfg using svcename db2c_db2inst1).
La actualización de la configuración del gestor de bases de datos no entrará en vigor hasta que se emita el próximo mandato db2start. Realizaremos esta acción en el paso 7.
db2 catalog tcpip node <nombrenodo> remote <nombresistemaprincipal> server <nombre_servicio_conexiones>
donde:
Para comprobar que el mandato catalog ha funcionado correctamente, emita el siguiente mandato:
db2 list node directory
Ejemplo de salida de este mandato (se han eliminado las líneas en blanco a efectos de legibilidad):
Directorio de nodos Número de entradas del directorio = 1 Entrada 1 nodo: Nombre nodo = MYNODE Comentario = Protocolo = TCPIP Nombre del sistema principal = 127.0.0.1 Nombre servicio = db2c_db2inst1
por ejemplo:db2 catalog db WAS as WASLOOP db2 uncatalog db WAS db2 catalog db WASLOOP as WAS at node MYNODE
Notas:
Ejemplo de salida para los pasos 5a a 5c
Antes del paso 5a, ya se ha creado una base de datos local denominada WAS. La salida del mandato db2 list db directory es similar a la siguiente:
Directorio de bases de datos del sistema Número de entradas del directorio = 1 Entrada 1 en base de datos: Alias de base de datos = WAS Nombre de base de datos = WAS Directorio de base de datos local = /home/ctsui Nivel de release de base de datos = 9.00 Comentario = Tipo de entrada de directorio = Indirecto Número de nodo de catálogo = 0
Después del paso 5a, la salida del mandato db2 list db directory es similar a la siguiente:
Directorio de bases de datos del sistema Número de entradas del directorio = 2 Entrada 1 en base de datos: Alias de base de datos = WAS Nombre de base de datos = WAS Directorio de base de datos local = /home/ctsui Nivel de release de base de datos = 9.00 Comentario = Tipo de entrada de directorio = Indirecto Número de nodo de catálogo = 0 Entrada 2 en base de datos: Alias de base de datos = WASLOOP Nombre de base de datos = WAS Directorio de base de datos local = /home/ctsui Nivel de release de base de datos = 9.00 Comentario = Tipo de entrada de directorio = Indirecto Número de nodo de catálogo = 0
Después del paso 5b, la salida del mandato db2 list db directory es similar a la siguiente:
Directorio de bases de datos del sistema Número de entradas del directorio = 1 Entrada 1 en base de datos: Alias de base de datos = WASLOOP Nombre de base de datos = WAS Directorio de base de datos local = /home/ctsui Nivel de release de base de datos = 9.00 Comentario = Tipo de entrada de directorio = Indirecto Número de nodo de catálogo = 0
Después del paso 5c, la salida del mandato db2 list db directory es similar a la siguiente:
Directorio de bases de datos del sistema Número de entradas del directorio = 2 Entrada 1 en base de datos: Alias de base de datos = WAS Nombre de base de datos = WASLOOP Nombre nodo = MYNODE Nivel de release de base de datos = 9.00 Comentario = Tipo de entrada de directorio = Remota Número de nodo de catálogo = -1 Entrada 2 en base de datos: Alias de base de datos = WASLOOP Nombre de base de datos = WAS Directorio de base de datos local = /home/ctsui Nivel de release de base de datos = 9.00 Comentario = Tipo de entrada de directorio = Indirecto Número de nodo de catálogo = 0
Para comprobar que el mandato catalog db ha funcionado correctamente, emita los dos mandatos siguientes (y consulte el ejemplo de salida que figura más abajo).
db2 connect to wasloop db2 connect to was
donde db2 connect to wasloop debe imprimir la información de conexión y db2 connect to was debe proporcionar SQL1403N.
Ejemplo de salida de db2 connect to wasloop:
Información de la conexión con la base de datos Directorio de bases de datos del sistema Servidor bases datos = DB2/6000 6.1.0 ID autorización SQL = CTSUI Alias base datos local = WASLOOP
Ejemplo de salida de db2 connect to was:
Información de la conexión con la base de datos Directorio de bases de datos del sistema Servidor bases datos = DB2/6000 6.1.0 ID autorización SQL = CTSUI Alias base datos local = WAS
db2 update dbm cfg using authentication client
Para comprobar que el mandato ha funcionado correctamente, visualice el valor nuevo con el siguiente mandato:
db2 get dbm cfg
Ejemplo de salida:
.... Autenticación gestor bases de datos (AUTHENTICATION) = CLIENT ....
db2stop db2start
Nota: Puede que sea necesario utilizar db2stop force para cerrar todas las conexiones de base de datos activas.
por ejemplo:db2 attach to MINODO user myid using micontraseña db2 drop db WAS