Escenario: Después de actualizar el servidor a DB2 Universal
Database (DB2 UDB) Versión 8.1
FixPack 10 (conocido también como la Versión 8.2 FixPack 3), se emite un mensaje de error de DB2, SQL0443N, si invoca una función de catálogo de la Interfaz a nivel de llamada (CLI) de DB2 como SQLTables(), SQLColumns(),
o SQLStatistics(). Un ejemplo del mensaje de error es:
SQL0443N La rutina "SYSIBM.SQLTABLES" (nombre específico
"TABLES") ha devuelto un error SQLSTATE con el texto de diagnóstico
SYSIBM:CLI:-805".
SQLSTATE=38553.
Solución: Vincule el archivo db2schema.bnd
a cada base de datos entrando los siguientes mandatos en un
indicador de mandatos:
db2 terminate
db2 connect to nombre-basedatos
db2 bind víaacceso\db2schema.bnd blocking all grant public sqlerror continue
db2 terminate
donde nombre-basedatos es el nombre de la
base de datos a la que deben vincularse los programas de utilidad,
y víaacceso es el nombre completo de la vía de acceso al directorio
donde están ubicados los archivos de vinculación.
Por ejemplo, la ubicación predeterminada en Windows es C:\Program
Files\IBM\SQLLIB\bnd\.
Para ver
una lista de todos los nombres de base de datos para una instancia de
DB2 específica, ejecute el mandato de CLI de DB2: db2 list
database directory. Para obtener más información, consulte la documentación de DB2.
Aparece el mensaje de error
de DB2 SQL0805N
Escenario: Cuando ejecuta el mandato mqsicreatebroker,
SQL: SQL0805N NULLID.SQLLF000.
Solución: Abra una ventana de procesador de línea de
mandatos de DB2 y emita un
mandato de vinculación a la base de datos.
En sistemas Linux
y UNIX, entre los mandatos:
connect to db
bind ~/sqllib/bnd/@db2cli.lst grant public CLIPKG 5
connect reset
donde
db es el nombre de la base de
datos.
En sistemas
Windows, entre los mandatos:
connect to db
bind x:\sqllib\bnd\@db2cli.lst blocking all grant public
connect reset
donde x: identifica la
unidad en la que ha instalado DB2 y
db es el nombre de la base de
datos.
Aparece el mensaje de error de
DB2 SQL0998N
Escenario: Cuando utiliza un flujo de mensajes
coordinado globalmente con una base de datos DB2
8.1, aparece un error SQL0998N con código de razón 09 y subcódigo 02.
Solución: Utilice el siguiente procedimiento para
establecer el parámetro TP_MON_NAME
de configuración del gestor de base
de datos DB2 en
MQ y modifique
XAOpenString en el archivo qm.ini para su gestor
de colas:
Para establecer el parámetro TP_MON_NAME,
utilice el siguiente mandato desde un inicio de sesión que tenga
autorización de administración para la instancia de
DB2:
db2 update dbm cfg using TP_MON_NAME MQ
Detenga y reinicie la instancia de
DB2 de forma que surta efecto el
valor.
Para establecer el valor AXLIB en el archivo
qm.ini, modifique XAOpenString de forma que
coincida con el ejemplo siguiente:
Establezca la vía de acceso de biblioteca AXLIB en uno de
los valores siguientes, dependiendo del sistema operativo:
En Windows:
AXLIB=mqmax
En AIX:
AXLIB=usr/mqm/lib/libmqmax_r.a
En HP-UX:
AXLIB=/opt/mqm/lib/libmqmax_r.sl
En Linux:
AXLIB=/opt/mqm/lib/libmqmax_r.so
En Solaris:
AXLIB=/opt/mqm/lib/libmqmax.so
Detenga y reinicie el intermediario y el gestor de colas
para que estos cambios surtan efecto.
Aparece el mensaje de error de
DB2 SQL1040N
Escenario: Está utilizando
DB2 y aparece el mensaje de error
BIP2322 con el error SQL1040N.
Explicación: El siguiente mensaje de
DB2 indica que se ha alcanzado el
valor del parámetro de configuración
maxappls de base de datos
DB2:
SQL1040N Ya están conectados a la base de datos el número máximo de aplicaciones.
SQLSTATE=57030"
DB2
ha rechazado el intento de conexión.
Si esta base de datos es una
de las bases de datos de intermediario definidas, que implica que una
petición de conexión de hebra de intermediario ha fallado, probablemente
el intermediario no funciona correctamente.
Solución:
Detenga todos los intermediarios que se conectan a la
base de datos afectada.
Aumente el valor del parámetro de configuración
maxappls. Además,
compruebe el valor del parámetro asociado maxagents y auméntelo de forma paralela
a maxappls.
Reinicie la base de datos
DB2.
Se emite el mensaje de error de DB2 SQL1224N cuando se conecta a DB2
Escenario: Se emite el mensaje de error de DB2: SQL1224N cuando se conecta a DB2. Este error indica que no se ha podido iniciar un agente de base de datos o que ha finalizado como resultado de un mandato shutdown (concluir) o force (forzar) de la base de datos.
Solución: En AIX,
utilice TCP/IP para conectar a DB2 con el fin de evitar el límite de memoria compartida de 10 conexiones. Para configurar el bucle de retorno de AIX y DB2 para utilizar una conexión TCP/IP:
Utilice el mandato mqsideletebroker
para suprimir el intermediario.
Configure DB2 para
utilizar TCP/IP y para iniciar el escucha TCP/IP. En la máquina servidor,
inicie la sesión como el propietario de la instancia de DB2, normalmente
db2inst1, y emita los mandatos siguientes:
db2set DB2COMM=tcpip
db2stop
db2start
Si el puerto de conexión de
DB2 no está definido en
/etc/services, edite el archivo
services para añadir los puertos de conexión e
interrupción de DB2. Debe utilizar nombres exclusivos y números de puertos que todavía no estén
definidos en el archivo services; por ejemplo:
db2svc1 3700/tcp # Servicio de conexión de DB2
db2isvc1 3701/tcp # Servicio de interrupción de DB2
Actualice la configuración de
DB2; por ejemplo:
db2 update dbm cfg using svcenamedb2svc1
donde
db2svc1 es el nombre del servicio del puerto de conexión de
DB2 en /etc/services.
De
forma alternativa, puede especificar directamente un número de puerto.
Detenga y reinicie la base de datos mediante los mandatos siguientes:
db2stop
db2start
Catalogue un nuevo nodo de conexión TCP/IP:
db2 catalog tcpip node NODENAME remote HOSTNAME server db2svc1
donde:
NODENAME
es el nombre del nuevo nodo de conexión TCP/IP. Puede utilizar local como nombre de nodo, siempre y cuando sea un identificador exclusivo.
HOSTNAME
es el nombre del sistema.
db2svc1
es el nombre del servicio del puerto de conexión de
DB2
en /etc/services.
Cuando el mandato se completa satisfactoriamente, aparece el mensaje DB20000I.
Catalogue la base de datos con un nuevo nombre de alias; por
ejemplo:
db2 catalog database DATABASE as DBALIAS at node NODENAME
donde:
DATABASE
es el nombre físico de la base de datos.
DBALIAS
es el nombre de alias de base de datos que desea utilizar.
Especifique el nuevo
nombre de alias en todas las referencias posteriores a la base de datos
local; por ejemplo, cuando ejecute el mandato mqsicreatebroker.
Detenga e inicie DB2:
db2 terminate
db2stop
db2start
Inicie una sesión con el ID de usuario de servicio o de intermediario.
Actualice el archivo de configuración ODBC para cada intermediario para añadir definiciones para la base de datos (el archivo predeterminado odbc.ini se encuentra en el directorio /var/wmqi/odbc):
En la parte superior del archivo, añada una definición para el nombre
de alias de base de datos:
DBALIAS=IBM DB2 ODBC Driver
Añada una nueva sección para el alias de base de datos:
[DBALIAS]
Driver=INSTHOME/sqllib/lib/libdb2.a
Description=Alias de base de datos de intermediario
Database=DBALIAS
donde
INSTHOME es la vía de acceso al directorio de la
instancia de DB2.
Cree un nuevo intermediario mediante DBALIAS en el parámetro -n; por ejemplo:
Inicie el intermediario y vuelva a definirlo en el entorno de trabajo.
Despliegue el intermediario y pruebe los flujos.
Se emite el mensaje de error
de DB2SQLSTATE=58005
Escenario: Se emite el error de DB2SQLSTATE=58005 cuando se utiliza WebSphere Event
Broker en Linux con DB2 Versión
8.1 y fixpack 9.
Explicación: Este error se emite cuando los valores de
los parámetros del kernel (msgmni, sem) son demasiado bajos.
Solución: Aumente el valor de los parámetros del
kernel (msgmni, sem).
Estos parámetros de kernel deberían estar muy por encima de sus
valores mínimos y ser, como mínimo, el más alto de los valores
recomendados para DB2, WebSphere MQ y WebSphere Event
Broker.
El ejemplo siguiente muestra posibles valores para un entorno
con una gran carga de trabajo, donde el intermediario tiene dos grupos de
ejecución con 200 flujos de mensajes desplegados y aproximadamente 45
aplicaciones que están utilizando estos flujos de mensajes:
Escenario: Se emiten mensajes de
DB2 u ODBC en z/OS
indicando que:
Se ha recibido una excepción al emitir el mandato connect de SQL de base
de datos.
Se ha producido un error de base de datos con un código de retorno
ODBC de -1, un estado SQL de 58004 y un código de error nativo de -99999.
El intermediario ha intentado sin éxito acceder
a su base de datos utilizando un ID de usuario específico.
Solución: Si aparece un mensaje de ODBC:
Active el rastreo de aplicaciones ODBC para que
genere el archivo traceodbc.
Localice el archivo traceodbc. Se encuentra en el subdirectorio /output. Por ejemplo, /u/argo/VCP0BRK/output/traceodbc.
Vaya al final de este archivo y busque apariciones de
SQLerror anteriores.
Los problemas de DB2
comunes incluyen:
Código de retorno ODBC -1, estado de SQL 58004, Código de error
nativo -99999
Esto puede deberse a lo siguiente:
No hay código SQL. No se ha iniciado el subsistema de
DB2
No se ha iniciado RRS.
SQLCODE 922.
El ID de usuario de la tarea iniciada no está
autorizado a utilizar un plan DSNACLI.
Código de retorno ODBC -1, estado de SQL 42503, Código de error nativo
-553
Esto puede deberse a que el ID de usuario de la tarea iniciada
no está autorizado a utilizar el ID de SQL actual. Vuelva a configurar el
intermediario y especifique DB2_TABLE_NAME como nombre
válido, o cree un grupo RACF y conecte el ID de usuario de tarea iniciada a este grupo.
Se emite el mensaje de error BIP1780 en
AIX
Escenario: Se emite el mensaje de error
BIP1780 en AIX, que
indica que el ID de usuario no se ha podido validar.
Explicación: Si cambia la contraseña de su sistema
operativo AIX después de crear el
intermediario, cuando realiza una acción, como por ejemplo desplegar un
archivo bar, ésta no se ejecuta correctamente porque el cambio de contraseña
impide establecer la conexión con la base de datos
DB2.
Solución: Ejecute el mandato mqsichangebroker
para el ID de usuario que se utiliza para conectar con la base de
datos:
mqsichangebrokerintermediario -p contraseña
Esto
permite que DB2 pueda autenticar el
ID de usuario correctamente.
No sabe cuántas conexiones de base de datos requiere un intermediario
Escenario: No sabe cuántas conexiones de base de datos
establecer para su intermediario.
Solución: Determine el número de conexiones de base
de datos que requiere un intermediario para la planificación de recursos y
capacidad. En DB2, la acción
predeterminada que se toma es limitar el número de conexiones simultáneas a una base de datos al
valor del parámetro de configuración
maxappls; el valor predeterminado
de maxappls es 40. El
parámetro asociado maxagents
también afecta a las conexiones actuales.
Los requisitos de
conexiones para un solo intermediario de mensajes son los siguientes:
Las hebras de intermediario internas necesitan cinco.
Se necesita una para cada intermediario contiguo de
publicación/suscripción, si se ha desplegado la topología.
Se necesita una para cada hebra de flujo de mensajes que analiza
mensajes MRM.
Desea utilizar XA con DB2
Escenario: Desea utilizar XA con DB2.
Solución: Si desea utilizar la coordinación XA con DB2 V8.1, asegúrese de que su gestor de colas está configurado para utilizar ThreadOfControl=THREAD.
En
Linux o
UNIX puede configurar este parámetro
en la sección XAResourceManager de qm.ini. En
Windows
puede configurar este parámetro utilizando el componente de explorador
o de servicios de WebSphere MQ, según la
versión de WebSphere MQ que utilice.
Error de coordinación XA con
DB2 V8 Fix Pack 2
Escenario: Se produce un error de coordinación XA con
DB2 V8 Fix Pack 2 en
AIX,
HP-UX,
Linux,
Solaris o
Windows.
Explicación: Si un flujo de mensajes no coordinado XA
intenta acceder a una base de datos que anteriormente ha utilizado un
flujo de mensajes coordinado XA, puede producirse un error porque
DB2 cree que el flujo posterior
todavía está coordinado a partir del flujo anterior.
Solución: Se ha arreglado en
DB2 V8 Fix Pack 3 con el APAR IY44711.
La coordinación XA falla si se reinicia la base de datos mientras el intermediario está en ejecución
Escenario: La coordinación XA global falla y recibe un error similar al del ejemplo siguiente, que procede de una base de datos de DB2:
Error de base de datos: Estado SQL '40003'; Código de error nativo '-900'; Texto de error '[IBM]
[Controlador CLI] SQL0900N El estado de aplicación es erróneo. No existe una conexión de base de datos. SQLSTATE=08003'.
Explicación: Un flujo de mensajes coordinado globalmente no puede volverse a conectar automáticamente a una base de datos
de usuario si ésta se reinicia la base de datos mientras el intermediario está en ejecución.
Solución: Detenga y reinicie el intermediario si el usuario de base de datos está inactivo o queda inactivo debido a
una tarea de mantenimiento planificada.
En Oracle, una operación de base de datos no devuelve ninguna fila,
aunque la fila exista
Escenario: Está utilizando bases de datos Oracle en los
flujos de mensajes y el ESQL se enlaza con columnas declaradas como de
tipo de datos CHAR, y se hace referencia a esos marcadores de parámetros
en una cláusula WHERE. La
operación de base de datos no devuelve ninguna fila, aunque la fila exista.
Explicación: En Oracle, las series de caracteres de longitud fija han de
rellenarse con caracteres
en blanco para poder realizar correctamente una comparación de este tipo.
Solución: Defina las columnas CHAR como columnas
VARCHAR2 o rellene la variable ESQL con caracteres en blanco hasta la
longitud de columna requerida, de forma que el proceso de comparación
encuentra las filas deseadas de la tabla.
Hay una pérdida de memoria desde la interfaz de cliente
Oracle en HP-UX 11
Escenario: Se ha observado una pérdida de memoria desde
la interfaz OCI (Oracle Client Interface) al utiliza Oracle 9i Release 2
(9.2.0.1) en HP-UX 11.
Solución: Oracle ha solucionado este problema y el
arreglo está disponible actualizando a Oracle 9i Release 2 Database Server Patch
Set 2 para HP9000 Series HP-UX (64 bits). Tiene el número de parche de Oracle 2761332. Para instalar este parche de
Oracle, quizá tenga que actualizar primero el instalador de Oracle (OUI) a
la versión 2.2.0.18.0. El número de parche de Oracle para esta actualización es 2878462.
Se emite el mensaje de error de Oracle ORA-12500 en Solaris 8 con
Oracle 9
Escenario: Se emite el mensaje de error de Oracle
ORA-12500 en Solaris 8 con Oracle 9 cuando ejecuta aplicaciones de
carga de trabajo que están realizando operaciones de inserción,
actualización o supresión de base de datos.
Explicación: Este error se emite cuando los valores de
los parámetros de ajuste son demasiado bajos.
Solución: Aumente el valor de los siguientes parámetros
de ajuste SGA de Oracle 9i Release 2 en el archivo
initSID.ora:
JAVA_POOL_SIZE
SHARED_POOL_SIZE
SORT_AREA_SIZE
El ejemplo siguiente muestra posibles valores
incrementados para una configuración de carga de trabajo con un
solo intermediario que tiene dos grupos de ejecución, cada uno con 92
flujos de mensajes:
Se emiten los mensajes de error BIP2731,
BIP2321 y BIP2322 cuando utiliza
publicaciones retenidas con una base de datos Sybase
Escenario: Aparecen los siguientes mensajes de error
cuando utiliza publicaciones retenidas y una base de datos de
intermediario Sybase:
BIP2731 La sentencia de base de datos 'INSERT INTO dbo.BRETAINEDPUBS
VALUES(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)' no se ha podido ejecutar.
BIP2321 Error de base de datos: Código de retorno ODBC '-1'.
BIP2322 Error de base de datos: Estado SQL '40001'; Código de error nativo '1205'.
Texto '[SYBASE][ODBC Sybase Driver][SQL Server]El mandato de servidor
(id de familia #0, id de proceso #234) ha encontrado una situación de punto muerto.
Por favor, vuelva a ejecutar el mandato.'
Explicación: Probablemente estos errores se producen sólo
cuando utiliza publicaciones retenidas con varios temas, con una carga de
trabajo sustancial.
Solución: Aplique el bloqueo a nivel de fila a una
de las tablas de base de datos del intermediario:
En un indicador de mandatos de Sybase, entre el mandato:
isql -Unombusuario -Pcontraseña
Conecte a la base de datos del intermediario:
use DSN intermediario
donde
DSN intermediario es el Nombre de origen de
datos (DNS) ODBC para la base de datos de intermediario.
Entre el mandato:
alter table dbo.BRETAINEDPUBS lock datarows
donde
dbo es el nombre de esquema.
Entre el mandato:
go
Se emite el mensaje de error BIP2275 cuando se despliega un flujo de mensajes de gran tamaño a la base de datos del intermediario Sybase
Escenario: Está utilizando Sybase como la base de datos de intermediario y se emiten los mensajes de error BIP2275, BIP5009 y BIP5004 durante el arranque del intermediario.
Explicación: Los mensajes de error BIP2275, BIP5009 y BIP5004 indican que una definición XML del flujo de mensajes recuperada desde la base de datos del intermediario durante el arranque tiene XML no válido. Esto puede ser debido a que una definición del flujo de mensajes que tiene una longitud superior a 1 MB se trunca cuando se recupera de la tabla BROKERRESOURCES durante el arranque del intermediario. El motivo por el que se trunca es que la longitud máxima de datos por omisión, para
Sybase, que se puede recuperar durante el arranque del intermediario desde la columna RESOURCEDATA
(donde se almacenan las definiciones del flujo de mensajes) de la tabla BROKERRESOURCES es de
1 MB.
Solución:
Detenga todos los intermediarios que se conectan a la
base de datos afectada.
Añada DefaultLongDataBuffLen=2048 a la definición DSN
del o de los archivos de configuración ODBC ($ODBCINI o $ODBCINI64 o ambos).
Reinicie el intermediario.
El sistema de rastreo DataDirect no puede abrir el archivo de
rastreo ODBC
Escenario: Mandatos como
mqsichangetrace y
mqsicreatebroker,
fallan y aparece un mensaje indicando que no se ha podido abrir el archivo
de rastreo ODBC.
Explicación: El archivo ODBC de DataDirect es
inaccesible o su tamaño ha sobrepasado los 2 GB y se ha activado el
rastreo.
Solución: Para resolver este problema:
Desactive el rastreo en el archivo al que apunta la variable de
entorno ODBCINI.
Localice el archivo de rastreo ODBC al que apunta
'TraceFile' en la sección ODBC. Si tiene que conservar el rastreo, mueva el archivo de rastreo
ODBC a otra ubicación. Si no tiene que conservar el rastreo, suprima el archivo de rastreo ODBC.
Si todavía tiene que recopilar datos de rastreo
ODBC, restablezca TRACE=1 en el archivo
odbc.ini.
Terminación anómala al desplegar un flujo de mensajes
Escenario: Está ejecutando DB2 versión 9 en HP-UX en PA-RISC. Intenta desplegar un flujo de mensajes, pero el despliegue falla.
Solución: Exporte la variable de entorno MQSI_SIGNAL_EXCLUSIONS
al entorno de intermediario: