Problemas de acceso a datos para bases de datos DB2
Este artículo proporciona sugerencias para la resolución de problemas de acceso a las bases de datos DB2.
¿Qué clase de problema tiene cuando accede a la base de datos DB2?
- Se produce un error de inicio de sesión Kerberos al conectar con la base de datos
- SQL0567N "DB2ADMIN" no es un ID de autorización válido. SQLSTATE=42602
- SQL0805N No se ha encontrado el paquete nombre-paquete
- SQL0805N No se ha encontrado el paquete "NULLID.SQLLC300". SQLSTATE=51002
- SQL30082N Attempt to establish connection failed with security reason ("17" ("UNSUPPORTED FUNCTION") SQLSTATE=08001 (SQL30082N No se ha podido establecer una conexión debido a la razón de seguridad "17" ("UNSUPPORTED FUNCTION') SQLSTATE=08001)
- SQLException, con ErrorCode -99,999 y SQLState 58004, con Java
- Mensaje de error java.lang.reflect.InvocationTargetException: com.ibm.ws.exception.WsException: DSRA0023E
- CLI0119E Error del sistema
- COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0911N
- No se ha podido encontrar "COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource“ para el origen de datos ("[nombre_origen_datos]“)"
Se devuelve el error 10500 (E_Fatal) cuando se intenta publicar o realizar una consulta sobre una entidad que excede los 255 caracteres en uno de sus campos
- java.sql.SQLException: ava.sql.SQLException: Failure in loading T2 native library db2jcct2 DSRA0010E: SQL State = null, Error Code = -99,999 (java.sql.SQLException: error al cargar la biblioteca nativa T2 db2jcct2 DSRA0010E: SQL State = null, Error Code = -99,999)
- Una excepción de contención de bloqueo ocurre en la base de datos cuando el tipo de implementación de origen de datos es XA
- “DSRA8050W: No se ha podido encontrar la clase DataStoreHelper especificada.“ Se produce la excepción cuando se intenta utilizar un origen de datos de DB2 Universal en una célula de release mixta
- Error "'SYSTEM' no es un ID de autorización válido" al intentar acceder a DB2 en una máquina Windows donde también se ha instalado WebSphere Application Server
- XAException: XAER_NOTA en llamada de preparación XA en el tipo de controlador JDBC 4 de DB2 Universal después de una restitución de transacción de una fase
- Se anota cronológicamente java.rmi.MarshalException para el cliente de aplicaciones debido a la incompatibilidad de las versiones de archivo del controlador JDBC.
- Un error de base de datos activa una excepción problemática de tipo -99999 para las aplicaciones que utilizan el tipo de controlador 4 de DB2 Universal
- No se puede acceder a DB2 en Linux cuando se utiliza el controlador JDBC de DB2 Universal
- Se produce una conversión no permitida en una columna VARCHAR FOR BIT DATA en un bean de persistencia gestionada por contenedor
Se produce un error de inicio de sesión Kerberos al conectar con la base de datos
- Las sentencias de inyección de un bean EJB (Enterprise JavaBeans) 3.0 se encuentran a nivel de atributo.
- El archivo persistence.xml no llama a información de metadatos relacionada con la base de datos con la que es ha establecido conexión.
- El alias gestionado de componente del origen de datos no es válido.
- La base de datos está configurada para utilizar un mecanismo de seguridad de un solo uso, por ejemplo, un mecanismo distinto del mecanismo típico de ID de usuario y contraseña, como kerberos.
Durante la inyección de un bean EJB 3.0, el archivo JPA (Java Persistence API) persistence.xml intenta conectarse a la base de datos para buscar metadatos. Para establecer la conexión, un conector Java™ 2 (J2C) solicita un sujeto del contexto de seguridad. En este escenario, la API de colaboración de seguridad que se llama para colocar la información en el contexto de seguridad no se ha llamado y el sujeto se devuelve sin ninguna credencial GSSCredential.
La llamada debería haber tenido lugar en el contenedor EJB, pero el contenedor EJB no ha llamado a la API de colaboración porque las API de seguridad requieren un bean completamente construido que no existía. Asimismo, la especificación EJB 3.0 indica de forma explícita que la construcción del bean no debe llevarse a cabo en un contexto de seguridad definido. Debido al diseño de la API de seguridad y de la dirección de la especificación EJB 3.0, el contenedor EJB no ha llamado a las API de colaboración de seguridad y, por consiguiente, el contexto de seguridad no ha sabido como configurar el sujeto y no ha habido ninguna credencial GSSCredential.
La ausencia de credenciales GSSCredential provoca que la implementación de RRA (Relational Resource Adapter) utilice una vía de acceso de código errónea; en lugar de indicar a DB2 que se conecte utilizando la GSSCredential, utiliza la identidad asociada con el alias gestionado del componente. Como resultado, el alias gestionado del componente se configura como una identidad que es desconocida para Kerberos y, por consiguiente, cuando el controlador DB2 ha enviado por relé esta identidad a la base de datos, se ha producido un error.
Causado por:
javax.security.auth.login.FailedLoginException: Error de inicio de sesión:
com.ibm.security.krb5.KrbException, código de estado: 6
message: Cliente no encontrado en la base de datos Kerberos
at com.ibm.security.jgss.i18n.I18NException.throwFailedLoginException(I18NException.java:25)
at com.ibm.security.auth.module.Krb5LoginModule.b(Krb5LoginModule.java:733)
at com.ibm.security.auth.module.Krb5LoginModule.c(Krb5LoginModule.java:610)
at com.ibm.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:433)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:795)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:209)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:709)
at java.security.AccessController.doPrivileged(AccessController.java:251)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:706)
at javax.security.auth.login.LoginContext.login(LoginContext.java:603)
at com.ibm.db2.jcc.a.ud.a(ud.java:25)
- Asegúrese de que las sentencias de inyección se encuentran a "nivel de clase".
De este modo evitará que se intente llevar a cabo la inyección cuando se crea el bean. Los elementos del contexto de persistencia siguen almacenados en JNDI (Java Naming and Directory Interface), pero no se colocan en las variables locales del objeto del bean. El método del bean busca estos elementos de contexto de persistencia en JNDI y, en ese momento, el bean debería estar ejecutándose en el contexto de seguridad correcto, ya que el contenedor de EJB ha llamado a las API de colaboración de seguridad.
- Haga que el archivo persistence.xml llame a la información de metadatos de
la base de datos.
Si el archivo persistence.xml llama a la información necesaria de metadatos de la base de datos, no es necesario que JPA se conecte a la base de datos para recuperar dicha información. Esto significa que no se establece ninguna conexión hasta que se ha accedido al método del bean. Mediante este paso, el contexto de seguridad de configura correctamente y la conexión funciona.
- Valide el alias gestionado del componente en el origen de datos.
Cuando JPA intenta conectarse a la base de datos para recopilar metadatos, el controlador vuelve a utilizar el alias gestionado del componente definido en el origen de datos porque el contexto de seguridad no se ha utilizado. Si valida el alias gestionado del componente, la conexión es satisfactoria.
- No utilice un mecanismo de seguridad de un solo uso para la seguridad de la
base de datos.
Esto no constituye una opción si desea utilizar un mecanismo de seguridad de un solo uso, como kerberos. Si la base de datos no está configurada para aceptar la autenticación estándar de ID de usuario y contraseña, este problema no se produce. Este problema sólo se produce cuando el sistema requiere una configuración de seguridad especial.
SQL0567N "DB2ADMIN" no es un ID de autorización válido. SQLSTATE=42602
- Compruebe que el nombre de usuario y la contraseña en las propiedades del origen de datos en la consola administrativa son los correctos.
- Asegúrese de que el ID de usuario y la contraseña no contienen caracteres en blanco antes, entre o después.
SQL0805N No se ha encontrado el paquete nombre-paquete
- Si el nombre del paquete es NULLID.SQLLC300, consulte SQL0805N No se ha encontrado el paquete "NULLID.SQLLC300". SQLSTATE=51002. para conocer las causas.
- Está intentando utilizar un controlador JDBC habilitado para XA en una base de datos DB2 que no está preparada para XA.
- DB2 bind @db2ubind.lst blocking all grant public
- DB2 bind @db2cli.lst blocking all grant public
Los archivos db2ubind.lst y db2cli.lst están en el directorio bnd de la raíz de instalación de DB2. Ejecute los mandatos desde ese directorio.
SQL0805N No se ha encontrado el paquete "NULLID.SQLLC300". SQLSTATE=51002
- La base de datos subyacente se ha desactivado y vuelto a crear.
- Se ha actualizado DB2 y no se han vuelto a enlazar correctamente sus paquetes.
Para solucionar este problema, vuelva a enlazar los paquetes de DB2 ejecutando el script db2cli.lst que se encuentra en el directorio bnd. Por ejemplo: db2>@db2cli.lst.
SQL30082N Attempt to establish connection failed with security reason ("17" ("UNSUPPORTED FUNCTION") SQLSTATE=08001 (SQL30082N No se ha podido establecer una conexión debido a la razón de seguridad "17" ("UNSUPPORTED FUNCTION') SQLSTATE=08001)
- El cliente ha enviado un nuevo valor de contraseña a un servidor que no da soporte a la función de cambio de contraseña.
- El cliente ha enviado información de autenticación de SERVER_ENCRYPT a un servidor que no da soporte a la función de cambio de contraseña.
- El cliente ha enviado un ID de usuario, pero no una contraseña, a un servidor que no da soporte a la autenticación únicamente mediante el ID de usuario.
- El cliente no ha especificado un tipo de autenticación y el servidor no responde con el tipo soportado. Puede incluir el caso en que el servidor devuelve varios tipos entre los que el cliente no es capaz de elegir.
Para solucionar este problema, asegúrese de que el cliente y el servidor utilicen el mismo mecanismo de seguridad. Por ejemplo, verifique que ha asignado un ID de usuario y una contraseña, o un alias de autenticación.
SQLException, con ErrorCode -99,999 y SQLState 58004, con Java
SQLException, con ErrorCode -99,999 y SQLState 58004, con Java™ " StaleConnectionException: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] CLI0119E Error inesperado del sistema. SQLSTATE=58004", cuando se utiliza el origen de datos de tipo WAS40
- Se ha proporcionado un nombre de usuario o contraseña no válidos.
- El nombre de la base de datos es incorrecto.
- Algunos paquetes de DB2 están dañados.
2002-07-26-14.19.32.762905 Instance:db2inst1 Node:000
PID:9086(java) Appid:*LOCAL.db2inst1.020726191932
XA DTP Support sqlxa_open Probe:101
DIA4701E La base de datos "POLICY2" no se ha podido abrir
para el proceso de transacciones distribuidas.
String Title: XA Interface SQLCA PID:9086 Node:000
SQLCODE = -1403
- Corrija el nombre de usuario y la contraseña. Si especifica la contraseña en la GUI del origen de datos, asegúrese de que el nombre de usuario y la contraseña especificados en el bean sean correctos. El nombre de usuario y la contraseña que se especifican en el bean sobrescriben los especificados al crear el origen de datos.
- Utilice el nombre de base de datos correcto.
- Vuelva a enlazar los paquetes (en el directorio bnd), como se indica a continuación:
db2connect to dbname c:\SQLLIB\bnd>DB2 bind @db2ubind.lst blocking all grant public c:\SQLLIB\bnd>DB2 bind @db2cli.lst blocking all grant public
- Compruebe que el archivo \WebSphere\AppServer\properties\wsj2cdpm.properties tenga el ID de usuario y la contraseña correctos.
Mensaje de error java.lang.reflect.InvocationTargetException: com.ibm.ws.exception.WsException: DSRA0023E
El mensaje de error java.lang.reflect.InvocationTargetException: com.ibm.ws.exception.WsException: DSRA0023E: No se ha encontrado la clase de implementación del origen de datos "COM.ibm.db2.jdbc.DB2XADataSource". cuando se accedía a una base de datos DB2
Una razón posible para esta excepción es que un usuario está intentando utilizar un origen de datos JDBC 2.0 pero DB2 no está habilitada para JDBC 2.0. Este problema suele producirse en las instalaciones nuevas de DB2 ya que DB2 proporciona controladores diferentes para JDBC 1.X y 2.0, con el mismo nombre de archivo físico. De forma predeterminada, el controlador JDBC 1.X está en la classpath.
- En los sistemas Windows, busque el archivo inuse en el directorio java12 de la raíz de instalación de DB2. Si no encuentra el archivo, está utilizando el controlador JDBC 1.x.
- En sistemas operativos como AIX o Linux, compruebe la vía de acceso a clase del origen de datos. Si la classpath no apunta al archivo db2java.zip del directorio java12, está utilizando el controlador JDBC 1.x.
- En sistemas Windows, detenga DB2. Ejecute el archivo usejdbc2.bat desde el directorio java12 de la raíz de instalación de DB2. Ejecute este archivo desde una línea de mandatos para comprobar que termina con éxito.
- En los sistemas operativos como, por ejemplo, AIX o Linux, cambie la classpath para que el origen de datos apunte al archivo db2java.zip del directorio java12 de la raíz de instalación DB2.
CLI0119E Error del sistema
CLI0119E Error del sistema. SQLSTATE=58004 - DSRA8100 :
No se ha podido obtener XAconnection ni DSRA0011E:
Excepción: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver]
CLI0119E Error inesperado del sistema. SQLSTATE=5800
- En la página de propiedades del origen de datos en la consola administrativa, compruebe que se haya especificado el nombre de base de datos correcto en el origen de datos.
- En la página de propiedades personalizadas, compruebe las propiedades personalizadas de nombre de usuario y contraseña. Compruebe que sean los correctos.
- Asegúrese de que el ID de usuario y la contraseña no contienen caracteres en blanco, antes, entre medias o después.
- Compruebe que el archivo WAS.policy existe para la aplicación , por ejemplo, D:\WebSphere\AppServer\installedApps\markSection.ear\META-INF\was.policy.
- Visualice toda la lista de excepciones para un error SQL subyacente y búsquelo utilizando la consulta de mensajes del proveedor de DBM.
Si encuentra este error durante la ejecución de DB2 en Red Hat Linux, el parámetro de número máximo de colas de todo el sistema es demasiado bajo para dar soporte a DB2 mientras obtiene los recursos necesarios para completar la transacción. Cuando existe este problema, las excepciones J2CA0046E y DSRA0010E pueden preceder a la excepción DSRA8100E.
Para corregir este problema, edite el archivo /proc/sys/kernal/msgmni y aumente el valor del parámetro de número máximo de colas de todo el sistema a un valor mayor que 128.
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0911N
ERROR CODE: -911
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0911N
La transacción actual se ha retrotraído debido a un punto muerto o a un tiempo de espera
excedido.
Código de razón "2". SSQLSTATE=40001
- Ejecute estos mandatos DB2:
- db2 update monitor switches using LOCK ON
- db2 get snapshot for LOCKS on dbName >
- Desactive el supervisor de bloqueo ejecutando: db2 update monitor switches using LOCK OFF.
- Busque un manejador de aplicaciones que esté en espera de bloqueo, y luego busque el ID del agente que retiene el bloqueo para verificar el ID del agente.
- Vaya a ese manejador para verificar que tiene un estado en espera de bloqueo, y el ID del agente que retiene el bloqueo. Si es el mismo ID de agente que el anterior, entonces se trata de un bloqueo circular (un punto muerto).
- Examine la aplicación y utilice un nivel de aislamiento menos restrictivo si no es necesario el acceso simultáneo.
- Tenga cuidado cuando cambie el valor accessIntent para pasar a un nivel de aislamiento menor. Este cambio puede generar problemas de integridad de datos.
- Para DB2/UDB Versión 7.2 y releases anteriores, puede establecer el distintivo
DB2_RR_TO_RS desde la ventana de línea de mandatos de DB2 para eliminar los puntos muertos innecesarios, como cuando el accessIntent definido en el método de bean es demasiado restrictivo, por ejemplo, PessimisticUpdate. El valor DB@_RR_TO_RS tiene dos efectos:
- Si el nivel de aislamiento elegido es RR, se baja a RS.
- Si elige otro nivel de aislamiento, y el valor DB2_RR_TO_RS está activado, la exploración ignora las filas que se han suprimido sin confirmar, aunque la fila esté capacitada para la exploración. El comportamiento afecta a los niveles de aislamiento RR, RS (Estabilidad de lectura) y CS (Estabilidad de cursor).
Por ejemplo, supongamos un caso en el que la transacción A suprime la fila con la columna1=10 y la transacción B realiza una exploración donde columna1>8 y columna1<12. Si DB2_RR_TO_RS está desactivado, la transacción B espera a que la transacción A se confirme o se retrotraiga. Si la transacción A se retrotrae, la fila con la columna1=10 se incluye en el conjunto de resultados de la consulta de la transacción B. Si DB2_RR_TO_RS está activado, la transacción B no espera a que la transacción A se confirme o se retrotraiga. La transacción B recibe inmediatamente los resultados de la consulta que no incluyen la fila suprimida. El establecimiento de DB2_RR_TO_RS mejora el comportamiento del bloqueo, y evita los puntos muertos.
No se ha podido encontrar "COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource“ para el origen de datos ("[nombre_origen_datos]“)"
Este error se indica con el mensaje DSRA8040I: No se ha podido conectar con DataSource.
Generalmente este error se produce cuando la classpath del controlador DB2 JDBC se ha establecido correctamente en ${DB2_JDBC_DRIVER_PATH}/db2java.zip pero no se ha establecido la variable de entorno DB2_JDBC_DRIVER_PATH.
Este error sólo puede ocurrir si está utilizando DB2 Versión 7.1 o 7.2 y no ha ejecutado usejdbc2 todavía. Es posible que este sea el problema si la vía de acceso es correcta, pero sigue recibiendo el mensaje.
- Vaya a la página Gestionar variables de WebSphere.
- Seleccione Entorno para verificar que no hay ninguna entrada de la variable DB2_JDBC_DRIVER_PATH.
Para corregir este problema: añada la variable DB2_JDBC_DRIVER_PATH con el valor igual a la vía de acceso del directorio que contiene el archivo db2java.zip.
![[z/OS]](../images/ngzos.gif)
Se devuelve el error 10500 (E_Fatal) cuando se intenta publicar o realizar una consulta sobre una entidad que excede los 255 caracteres en uno de sus campos
Este error se produce normalmente cuando se intenta publicar o realizar una consulta sobre una entidad que sobrepasa los 255 caracteres en uno de sus campos. Es menos obvio cuando se utilizan caracteres que no son del inglés, ya que el límite real se alcanza antes de que se muestren 255 caracteres visuales.
Para corregir este problema: acéptelo como una limitación del uso de DB2 Versión 7 en z/OS. No sobrepase el límite de 255 caracteres.
java.sql.SQLException: ava.sql.SQLException: Failure in loading T2 native library db2jcct2 DSRA0010E: SQL State = null, Error Code = -99,999 (java.sql.SQLException: error al cargar la biblioteca nativa T2 db2jcct2 DSRA0010E: SQL State = null, Error Code = -99,999)
- Una máquina no se ha reiniciado después de instalar DB2. Reinicie la máquina que ha obtenido el error e inténtelo de nuevo.
- Se ha llevado a cabo una operación de base de datos que utiliza un ámbito distinto del origen de datos configurado. Por ejemplo, el mandato testConnection se ejecuta a nivel de nodo para un origen de datos que existe a nivel de servidor. Establezca el origen del script db2profile de la máquina y asegúrese de que el entorno contiene punteros para las bibliotecas nativas de DB2. El script db2profile se encuentra en el directorio raíz del ID de usuario de DB2.Para obtener más información sobre el mandato testConnection, consulte Servicio conexión de prueba.
- El contexto DB2 no se está configurando correctamente para el usuario que está ejecutando WebSphere Application Server. Establezca el origen del script db2profile de la máquina y asegúrese de que el entorno contiene punteros para las bibliotecas nativas de DB2.
Una excepción de contención de bloqueo ocurre en la base de datos cuando el tipo de implementación de origen de datos es XA
Síntoma | Problema | Descripción | Respuesta recomendada |
---|---|---|---|
Una excepción de contención de bloqueo ocurre en una base de datos DB2 a la que la aplicación acceda a través de un origen de datos de tipo de implementación XA. | La aplicación está intentando acceder a los registros de base de datos que están bloqueados por una transacción XA que está en el estado finalizado, pero el gestor de transacciones no puede prepararla. | Una transacción XA a DB2 que finaliza, pero no se puede
preparar, está en el estado finalizado. Como no se considera
que esté en duda, el gestor de transacciones no puede recuperar
esta transacción. DB2 no la devuelve en la lista de transacciones en duda. Asimismo, DB2 no retrotrae la transacción inmediatamente, espera hasta que se liberan todas las conexiones a la base de datos. Durante este periodo de inactividad, la transacción continúa bloqueando la base datos. Si el servidor de aplicaciones no desconecta todas las conexiones de la base de datos para permitir la retrotracción de la transacción, la transacción finalizada continúa bloqueando los mismos registros de base de datos. Si la aplicación intenta acceder a estos registros bloqueados, se genera una excepción de contención de bloqueo en DB2. |
DB2 Versión 8.2 se facilita con una aplicación de ejemplo que se conecta a un servidor DB2 definido y utiliza las API de DB2 disponibles para obtener una lista de estas transacciones finalizadas. La aplicación ofrece un valor de configuración que le permite designar un periodo de tiempo después del cual la aplicación retrotrae estas transacciones. Coloque la aplicación de ejemplo en el directorio sqllib/samples/db2xamon.c de DB2 Versión 8.2 y ejecútela. |
“DSRA8050W: No se ha podido encontrar la clase DataStoreHelper especificada.“ Se produce la excepción cuando se intenta utilizar un origen de datos de DB2 Universal en una célula de release mixta
Este error generalmente ocurre cuando está utilizando WebSphere Application Server versión 6.0 o posterior junto con una versión anterior e intenta crear un origen de datos de DB2 Universal en una versión anterior.
Esto puede ocurrir porque el origen de datos de DB2 Universal no estaba disponible en la versión 5 y anteriores, pero la consola administrativa de la versión 6 le permite crear uno.
Para corregir este problema: cree el origen de datos de la versión 6.0 o posterior
Error "'SYSTEM' no es un ID de autorización válido" al intentar acceder a DB2 en una máquina Windows donde también se ha instalado WebSphere Application Server
Se recibe el error "'SYSTEM' no es un ID de autorización válido" al intentar acceder a DB2 en una máquina Windows donde también está instalado WebSphere Application Server.
Síntoma | Problema | Descripción | Respuesta recomendada |
---|---|---|---|
Para un servidor WebSphere Application Server de una instalación Windows que utiliza DB2 como programa de fondo, verá la siguiente
excepción en el archivo de registro de JVM:
|
Esta excepción se genera en el caso de las configuraciones en las que WebSphere Application Server es cliente del servidor DB2 . El problema subyacente es un conflicto de autorización entre WebSphere Application Server en Windows y DB2, que surge cuando una aplicación intenta conectarse a DB2 sin proporcionar un ID de usuario ni una contraseña. | Cuando un cliente DB2 y la base de datos DB2 se ejecutan en la misma máquina, DB2 permite que el cliente se conecte sin un ID de usuario ni una contraseña. La conexión se realiza bajo la credencial del usuario propietario del proceso cliente: es este caso, la JVM del servidor de aplicaciones. Sin embargo, si WebSphere Application Server se ejecuta como un servicio Windows y la opción "Iniciar sesión como" se establece en "Cuenta de sistema local", la JVM del servidor de aplicaciones está categorizada como un subcomponente de un usuario Windows especial llamado SYSTEM. Este usuario no tiene permiso para conectarse a DB2, generando la excepción mostrada previamente. | Tiene dos
opciones:
|
XAException: XAER_NOTA en llamada de preparación XA en el tipo de controlador JDBC 4 de DB2 Universal después de una restitución de transacción de una fase
Síntoma
Para las aplicaciones que utilizan el tipo de controlador JDBC 4 de DB2 Universal con DB2 versión 8.2, es posible que falle una conexión y que se active un error XAER_NOTA XAException. El siguiente bloque de código es una ejemplo de esta excepción:
J2CA0027E: Se ha producido una excepción al invocar la preparación en un
adaptador de recursos XA desde dataSource jdbc/SDOSVT, en el
ID de transacción {XidImpl: formatId(57415344), gtrid_length(36), bqual_length(54),
data(000000ff5191398200000001000000296cac5c42fe3c6838631cbaafc8b5a9253b846544
000000ff5191398200000001000000296cac5c42fe3c6838631cbaafc8b5a9253b8465440000000
10000000000000000000000000002)}:
javax.transaction.xa.XAException: XAER_NOTA
at com.ibm.db2.jcc.a.xb.a(xb.java:1682)
at com.ibm.db2.jcc.a.xb.a(xb.java:841)
at com.ibm.db2.jcc.a.xb.prepare(xb.java:812)
at com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl.prepare(WSRdbXaResourceImpl.java:837)
...
Problema
Si se utiliza un tipo de controlador JDBC 4 de DB2 Universal en una transacción de una fase como, por ejemplo, una transacción local que tiene establecido el valor de Autocommit en false y se restituye esta transacción de una fase, la próxima vez que se utiliza la conexión en una transacción de dos fases falla cuando se invoca prepare.
Un problema en el soporte XA del controlador JDBC de tipo 4 de DB2 Universal hace que la llamada de preparación de XA falle. Este problema no se produce si la transacción de una sola fase se confirma y no se produce cuando se utiliza el controlador JDBC de DB2 Universal en la modalidad de tipo 2.
Solución
Actualice al fixpack 1 de DB2 Versión 8.2, que es equivalente al fixpack 8 de la versión 8.1. El XA del controlador JDBC de DB2 Universal que está disponible con estos releases soluciona el problema descrito anteriormente para la modalidad de tipo 4.
Se anota cronológicamente java.rmi.MarshalException para el cliente de aplicaciones debido a la incompatibilidad de las versiones de archivo del controlador JDBC.
Síntoma
En una aplicación que incluye un cliente de aplicaciones, se muestra el mensaje de error siguiente en el archivo de registro del servidor de aplicaciones:
java.rmi.MarshalException: CORBA MARSHAL 0x4942f89a No; la excepción anidada es:
org.omg.CORBA.MARSHAL: No se ha podido leer el valor del puente subyacente : Serialización no coincidente
UIDs : Source (Rep.
IDRMI:com.ibm.db2.jcc.c.SqlException:63EEE52211DCD763:82CE0C0DA2B0A000)
= 82CE0C0DA2B0A000 whereas Target (Rep. ID
RMI:com.ibm.db2.jcc.c.SqlException:63EEE52211DCD763:91C6171BC645E41B)
= 91C6171BC645E41B vmcid: 0x4942f000 código menor: 2202 completado: No
Problema
Los archivos db2jcc.jar de la máquina del cliente de aplicaciones del servidor de aplicaciones son de versiones de DB2 incompatibles entre sí o incompatibles con la versión de DB2 que funciona como el almacén de datos.
Solución
Consulte los archivos db2jcc.jar de la máquina del cliente de aplicaciones, el servidor de aplicaciones y el servidor de DB2 . En la máquina del cliente y en el servidor de aplicaciones, instale archivos de la misma versión que sea compatible con el servidor DB2.
Un error de base de datos activa una excepción problemática de tipo -99999 para las aplicaciones que utilizan el tipo de controlador 4 de DB2 Universal
Síntoma
Si utiliza el tipo de controlador 4 de DB2 Universal para acceder a DB2 Network Server, y la base de datos falla, el servidor de datos emite una excepción genérica de tipo -99999 como respuesta a cada solicitud getConnection de JDBC: Esta excepción, de la que se muestra un ejemplo en el extracto de código siguiente, puede provocar un comportamiento imprevisto de las aplicaciones.
java.sql.SQLException: Excepción de E/S al abrir el socket en
el servidor bs8.rchland.ibm.com en el puerto 1527.
El servidor DB2 puede haber concluido. DSRA0010E: SQL State = null,
Error Code = -99,999DSRA0010E: SQL State = null,
Error Code = -99,999
at com.ibm.db2.jcc.b.a.<init>(a.java:125)
at com.ibm.db2.jcc.b.b.a(b.java:1011)
at com.ibm.db2.jcc.c.l.<init>(l.java:197)
at com.ibm.db2.jcc.b.b.<init>(b.java:258)
at com.ibm.db2.jcc.DB2PooledConnection.
<init>(DB2PooledConnection.java:44)
at com.ibm.db2.jcc.DB2ConnectionPoolDataSource.getPooledConnectionX
(DB2ConnectionPoolDataSource.java:80)
at com.ibm.db2.jcc.DB2ConnectionPoolDataSource.getPooledConnection
(DB2ConnectionPoolDataSource.java:45)
at com.ibm.ws.rsadapter.DSConfigurationHelper$1.run
(DSConfigurationHelper.java:945)
Problema
Cuando se ejecuta en la modalidad de tipo 4, algunas versiones del controlador de DB2 Universal activan una excepción genérica para el error de base de datos, en lugar de un código de error específico que WebSphere Application Server puede correlacionar con una excepción de conexión caducada. Este problema se produce con las versiones del controlador que se asocian con el fixpack 6 ó 7 de DB2 8.1 y DB2 8.2.
Solución
Actualice al fixpack 1 de DB2 Versión 8.2, que es equivalente al fixpack 8 de la versión 8.1, que proporciona un código de error de válido en el caso de ejemplo descrito anteriormente. WebSphere Application Server correlaciona este código de error con una excepción StaleConnectionException, como está previsto.
No se puede acceder a DB2 en Linux cuando se utiliza el controlador JDBC de DB2 Universal
Síntoma
java.security.AccessControlException: Acceso denegado (java.lang.RuntimePermission accessClassInPackage.sun.io)
- Si ejecuta Linux de 64 bits:
com.ibm.db2.jcc.b.SqlException: Error al cargar la bibliotecanativa T2 db2jcct2
Problema
El proceso para configurar DB2 en Linux funciona con el controlador JDBC de DB2 Universal no se ha completado.
Solución
- Compruebe que los requisitos de configuración para Java™ SDK 1.4.2 para la plataforma Linux se hayan cumplido.
- Configure el entorno de desarrollo para crear aplicaciones Java en Linux con el soporte de JDBC de DB2. Consulte los temas de desarrollo de aplicaciones de DB2 para obtener más información.
- Si ejecuta DB2 en la plataforma Linux/IA64 y utiliza el fixpack 7A de DB2 v8.1, realice el paso adicional que se describe en la nota técnica de fixpack 7a de DB2 UDB Versión 8 para Linux en IA64 que genera un error de falta de la biblioteca libdb.so.3. Este paso sólo es necesario para el fixpack 7A. Este paso no es necesario para el fixpack 7 de DB2 versión 8.1 o de versiones anteriores de DB2; este paso tampoco es necesario para el fixpack 8 de DB2 versión 8.1 o versiones posteriores de DB2.
Se produce una conversión no permitida en una columna VARCHAR FOR BIT DATA en un bean de persistencia gestionada por contenedor
Cuando los enterprise beans con tipos CMP (persistencia gestionada por contenedor) que tienen columnas VARCHAR FOR BIT DATA definidas en una tabla DB2 se despliegan en el controlador JDBC de tipo 4 de DB2 Universal para la persistencia de los datos, se genera una excepción SQLException de conversión no permitida en el tiempo de ejecución. Esta excepción sólo se produce cuando se utiliza el controlador JDBC de tipo 4 de DB2 Universal y se establece la propiedad deferPrepares como true. Cuando se establece la propiedad deferPrepares como true, el controlador JDBC de tipo 4 de DB2 Universal utiliza la correlación de datos JDBC estándar.
Actualmente, el código desplegado que se genera no sigue la correlación de la especificación JDBC estándar. El error durante la ejecución se debe a un problema en la herramienta que ha preparado los enterprise beans para la ejecución.
- Establezca la propiedad deferPrepares como false en la configuración del origen de datos.
- No utilice el controlador JDBC de tipo 4 de DB2 Universal si la tabla tiene columnas VARCHAR FOR BIT DATA o LONG VARCHAR FOR BIT DATA. Consulte el readme de DB2 V8.1 para obtener más información.