Limitaciones de la depuración de rutinas

Esta página describe las limitaciones que puede encontrar al depurar rutinas y los métodos sugeridos para eludir esas limitaciones. Lea también el archivo readme del producto, que puede contener limitaciones adicionales para este depurador.

General

Consulte también los problemas conocidos del depurador de rutinas para obtener actualizaciones.

Nombres de rutina delimitados
El depurador de rutinas proporciona un soporte limitado para las rutinas que utilizan nombres de esquema o nombres de rutina delimitados. Tales rutinas se deben iniciar desde el cuadro de diálogo Depurar de configuraciones de inicio y no desde el menú contextual de la vista Definición de datos.
Habilitación de acciones de paso
Cuando se inicia una sesión de depuración, si los botones de acciones de pasos (por ejemplo el botón Recorrer) no están habilitados, seleccione el marco de pila para habilitar los botones.
Gestor de sesiones
Utilice el gestor de sesión que se incluye en el producto. El gestor de sesiones puede estar en el servidor, en la red o en el cliente. Los pasos siguientes describen cómo configurar el gestor de sesiones en el cliente, utilizando el gestor de sesiones que se incluye con el producto. Estas instrucciones no son aplicables a configuraciones de PL/SQL para DB2 ni a configuraciones Oracle.
  1. Abra una ventana de mandatos y vaya al directorio de instalación del producto. En Windows, el directorio de instalación predeterminado del producto es C:\Archivos de programa\IBM\SDP70.
  2. Ejecute db2dbgm.bat desde la ventana de mandatos, y anote la dirección IP y número de puerto del gestor de sesiones.
  3. Inicie el entorno de trabajo y modifique las preferencias del depurador para utilizar el gestor de sesiones local:
    1. Pulse Ventana > Preferences, expanda el nodo Ejecutar/depurar y pulse Depurador de rutinas DB2.
    2. En el panel Depurador, seleccione Utilizar gestor de sesiones en ejecución.
    3. En el campo Host, especifique la dirección IP de la máquina. Puede también obtener la dirección IP a partir de la ventana de mandatos o ventana de terminal donde se ejecuta el gestor de sesiones.
    4. En el campo Puerto, especifique el puerto del gestor de sesiones local. El número de puerto predeterminado es 4554. Puede también obtener el número de puerto a partir de la ventana de mandatos o ventana de terminal donde se ejecuta el gestor de sesiones.
Nombres de variable
Los nombres de variables que contienen comillas no están soportados para las rutinas de depuración en las bases de datos DB2 para Linux, Unix y Windows.
Puntos de interrupción
Para Optim Development Studio Versión 2.2.1.1, no se pueden inhabilitar los puntos de interrupción individuales.
Características disponibles solo en la base de datos DB2 para Linux, UNIX y Windows Versión 10.1 Fix Pack 2 o posterior
Estas características de depuración están disponibles solo al depurar rutinas en una base de datos DB2 para Linux, UNIX y Windows Versión 10.1 Fix Pack 2 o posterior:
  • Rutinas declaradas de depuración
  • Desencadenantes de depuración
  • Depuración de bloques PL/SQL anónimos
  • Inicio del depurador desde el editor SQL y XQuery
  • Configuración de puntos de interrupción persistentes en el editor de rutinas
  • Recompilación de rutinas con la opción de depuración sin volver a desplegar la rutina
  • Visualización de los siguientes tipos de variables en la vista Variables:
    • Variables globales y de paquetes
    • Conjuntos asociativos
    • Matriz de filas
Variables de matriz
El depurador de rutinas lista solo los primeros 100.000 elementos de una variable de matriz en la vista Variables.
Tipos de datos BLOB
Si el tipo de datos de un parámetro de salida es BLOB (objeto binario grande), la salida se devuelve en mayúsculas. Dado que el valor devuelto representa un número hexadecimal, esto no supone un problema.
Rol DB2 SYSDEBUG
Para depurar rutinas desplegadas en la base de datos DB2 para Linux, UNIX y Windows Versión 10.1 Fix Pack 2 o posterior, el ID de usuario de base de datos que despliega la rutina debe ser un miembro del rol SYSDEBUG.

Rutinas SQL y Java

Desencadenantes

Al depurar desencadenantes en una base de datos DB2, puede depurar solo un desencadenante a la vez. No es posible depurar dos o más desencadenantes de forma simultánea.

Tipos de datos de PL/SQL y Oracle

Consulte Tipos de datos de PL/SQL y Oracle no compatibles con el depurador de rutinas.

Rutinas PL/SQL

Limitación Oracle

Cuando depura un procedimiento que tiene un tipo CURSOR, cuando se detiene en un punto de interrupción en medio del procedimiento, si pulsa Terminar, la entrada de la vista Salida a veces se bloquea. Para solucionar esta limitación, pulse Reanudar en lugar de Terminar.

Limitaciones Informix

La siguiente lista describe las limitaciones que supone depurar procedimientos almacenados en una base de datos Informix:
  • Al depurar un procedimiento almacenado en una base de datos Informix debe utilizar el depurador incorporado o utilizar un gestor de sesiones en ejecución. No se puede utilizar la preferencia predeterminada de ejecutar el gestor de sesiones en cada servidor conectado.

    Para cambiar la preferencia para la ubicación del gestor de sesiones del depurador de rutinas, seleccione Ventana > Preferencias. En Preferencias, seleccione Ejecutar/depurar > Depurador de rutinas para seleccionar las preferencias para la depuración. Seleccione el servidor de bases de datos para las rutinas que está depurando. En la sección, Ubicación del gestor de sesiones de depuración de rutinas, seleccione Utilizar el gestor de sesiones incorporado o Utilizar gestor de sesiones en ejecución.

  • En la vista Explorador de proyectos de datos, si pulsa con el botón derecho en un procedimiento almacenado Informix y se desconecta la base de datos Informix, Depurar no está habilitado. Para habilitar la depuración, conéctese a la base de datos. También puede depurar el procedimiento almacenado desde la vista Explorador de fuentes de datos.

Limitación para Linux

Si está depurando una rutina en una base de datos DB2 local, puede recibir 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 error número 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). Con este procedimiento, el depurador utilizará el mismo alias de base de datos que antes:

  1. Si no se ha configurado un puerto para clientes remotos DB2 inicie la sesión como root y cree un puerto TCP/IP en /etc/services, (por ejemplo, db2c_db2inst1 50000/tcp). Como alternativa, puede utilizar el Centro de control para crear un puerto TCP/IP (estableciendo las propiedades de comunicaciones para la instancia de base de datos). Se puede utilizar un puerto existente para clientes DB2 remotos.

    En los pasos del 2 al 7 debe iniciar la sesión como propietario de instancia de DB2.

  2. Configure el gestor de bases de datos de forma que inicie el gestor de conexiones para el protocolo de comunicaciones TCP/IP. Si no está seguro de si se ha realizado esta operación, emita el siguiente mandato:
    db2set db2comm

    Si la salida no contiene la palabra clave tcpip debe entrar 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.

    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.

    .
  3. Actualice el parámetro de configuración del gestor de bases de datos SVCENAME con el nombre del servicio de conexiones definido en /etc/services (paso 1).

    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.

  4. Catalogue el nodo de bucle de retorno especificando el siguiente mandato:
    db2 catalog tcpip node <nombrenodo> remote <nombre_de_host> server <nombre_servicio_conexiones>

    donde:

    • <nombrenodo> es un alias local del nodo que debe catalogarse. Se trata de un nombre arbitrario de la estación de trabajo, utilizado para identificar el nodo (por ejemplo, db2 catalog tcpip node minodo remote 127.0.0.1 server db2c_db2inst1).
    • <nombre_de_host> es el nombre de la máquina donde está instalado DB2. El nombre de host que especifica debe corresponder al mismo nombre de la máquina, incluyendo mayúsculas y minúsculas. Si no está seguro de cuál es el nombre de la máquina, consulte el Centro de control.

    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 host = 127.0.0.1
    Nombre servicio = db2c_db2inst1
  5. Catalogue la base de datos de la forma siguiente. Consulte los mandatos siguientes para generar salida de ejemplo si desea realizar un seguimiento de los efectos de cada mandato:
    1. db2 catalog db <nombre_base_datos> as <alias_base_datos>
    2. db2 uncatalog db <nombre_base_datos>
    3. db2 catalog db <alias_base_datos as <nombre_base_datos> at node <nombrenodo>
    Por ejemplo:
    db2 catalog db WAS as WASLOOP
    db2 uncatalog db WAS
    db2 catalog db WASLOOP as WAS at node MYNODE

    Notas:

    • El alias de base de datos puede ser cualquier nombre, pero no puede ser el mismo que el nombre de base de datos. El alias debe tener 8 caracteres como máximo.
    • Recibirá el número de error SQL1334N si no ha catalogado correctamente la base de datos.
    • Debe repetir los pasos 5a al 5c para cada base de datos en la que desee depurar una rutina.

    Ejemplo de salida para los pasos del 5a al 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 al mensaje 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 al mensaje 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 al mensaje 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 al mensaje 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 la salida de ejemplo siguiente):

    db2 connect to wasloop
    db2 connect to was

    donde db2 connect to wasloop imprimirá la información de conexión y db2 connect to was proporcionará SQL1403N.

    Ejemplo de salida de db2 connect to wasloop:

    Información de la conexión de 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 de 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
  6. Actualice el mecanismo de autenticación para que sea Autenticación de cliente. Especifique el mandato:
    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
    ....
  7. Reinicie DB2 para renovar la memoria caché del directorio. Por ejemplo:
    db2stop
    db2start

    Nota: puede que sea necesario utilizar db2stop force para cerrar todas las conexiones de base de datos activas.

  8. En WAS, no es necesario actualizar el archivo admin.config. En aplicaciones WebSphere, no es necesario cambiar la configuración de origen de datos existente.
  9. Si desea descartar la base de datos, emita los mandatos siguientes:
    1. db2 attach to <nombrenodo> user <IDusuario> using <contraseña>
    2. db2 drop db <nombre_base_datos>
      Por ejemplo:
      db2 attach to MINODO user idusuario using micontraseña
      db2 drop db WAS

Feedback