Qué puede causar errores ORA-12519 intermitentes (TNS: no se encontró controlador apropiado)

Question

Estamos ejecutando nuestro conjunto de pruebas Junit 4 contra Weblogic 9 frente a una base de datos Oracle 10 (usando Hudson como servidor de integración continua) y de vez en cuando lo haremos obtener un ORA-12519 crash durante el desmantelamiento del script. Sin embargo, el error es muy intermitente:

• lo general, ocurre por la misma clase de prueba
• No siempre sucede para los mismos casos de prueba (a veces pasa)
• Esto no sucede para el mismo número de casos de prueba (entre 3-9)
• a veces no sucede en absoluto, todo pasa

Aunque no puedo garantizar que esto no suceda de forma local (cuando se ejecuta en contra de la misma base de datos, por supuesto), I han ejecutado el mismo conjunto de clases varias veces sin problemas.

¿Alguna idea?

Answer 1

No sé si esta será la respuesta de todos, pero después de excavar, esto es lo que se nos ocurrió.

El error es obviamente causado por el hecho de que el oyente no aceptaba conexiones, pero ¿por qué obtendríamos ese error cuando otras pruebas podrían conectarse bien (también podríamos conectar ningún problema a través de sqlplus)? La clave del problema no era que no pudiéramos conectarnos, sino que era intermitente

Después de algunas investigaciones, descubrimos que había algunos datos estáticos creados durante la configuración de la clase que mantendrían las conexiones abiertas para el vida de la clase de prueba, creando nuevas a medida que avanzaba. Ahora, a pesar de que todos los recursos se lanzaron correctamente cuando esta clase salió del alcance (a través de un bloque finally {}, por supuesto), hubo algunos casos durante la ejecución cuando esta clase se tragaría todas las conexiones disponibles (bueno, malo alerta de práctica: este fue el código de prueba unitaria que se conectó directamente en lugar de usar un grupo, por lo que el mismo problema no podría ocurrir en la producción).

La solución era no hacer que la clase sea estática y se ejecute en la configuración de la clase, sino usarla en los métodos por método de configuración y eliminación.

Así que si obtiene este error en sus propias aplicaciones, abra un perfil de ese chico malo y vea si puede haber una fuga de conexión. Espero que ayude.

Answer 2

Otra solución que he encontrado a un error similar pero el mismo mensaje de error es aumentar el número de controladores de servicio encontrados. (Mi ejemplo de este error fue causado por demasiadas conexiones en las piscinas de conexión Weblogic Portal.)

• Run SQL*Plus y está registrado como SYSTEM. Debe saber qué contraseña ha utilizado durante la instalación de Oracle DB XE.
• Ejecute el comando alter system set processes=150 scope=spfile; en SQL * Plus
• MUY IMPORTANTE: reinicie la base de datos.

A partir de aquí:

http://www.atpeaz.com/index.php/2010/fixing-the-ora-12519-tnsno-appropriate-service-handler-found-error/

Answer 3

También tuve el mismo problema, me buscaron respuestas muchos lugares. Obtuve muchas respuestas similares para cambiar el número de controladores de proceso/servicio. Pero pensé: ¿y si me olvidé de reiniciarlo?

Luego traté de usar el método Thread.sleep() después de cada uno de mis connection.close();.

No sé cómo, pero funciona al menos para mí.

Si alguien quiere probarlo y descubrir cómo funciona, por favor, adelante. También me gustaría saberlo ya que soy un principiante en el mundo de la programación.

Answer 4

Tuve el problema similar. Sucedió cada vez que ejecuto un paquete de pruebas de base de datos (Spring JDBC) con SpringJUnit4ClassRunner, así que resolví el problema poniendo @DirtiesContext anotación para cada prueba para limpiar el contexto de la aplicación y liberar todos los recursos para que cada prueba se pudiera ejecutar con una nueva iniciación del contexto de la aplicación.

Answer 5

Tuve este problema en una prueba de unidad que abrió muchas conexiones al DB a través de un grupo de conexiones y luego "detuvo" el grupo de conexiones (ManagedDataSource en realidad) para liberar las conexiones al final de cada prueba. Siempre me quedé sin conexiones en algún momento del conjunto de pruebas.

Agregué un Thread.sleep (500) en el desmontaje() de mis pruebas y esto resolvió el problema. Creo que lo que sucedía era que el grupo de conexiones stop() libera las conexiones activas en otro hilo de modo que si el hilo principal sigue ejecutándose, los hilos de limpieza se han quedado tan atrás que el servidor de Oracle se quedó sin conexiones. Agregar la suspensión permite que los hilos de fondo liberen las conexiones agrupadas.

Esto es mucho menos un problema en el mundo real debido a que los servidores de bases de datos son mucho más grandes y hay una buena combinación de operaciones (no solo operaciones interminables de conexión/desconexión de DB).