¿Qué puede causar los errores intermitentes ORA-12519 (TNS: no se encontró el 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 un servidor de integración continua) y, ocasionalmente, obtendremos un bloqueo ORA-12519 durante la eliminación del script. Sin embargo, el error es muy intermitente:

• Generalmente sucede para la misma clase de prueba
• No siempre sucede para los mismos casos de prueba (a veces pasan)
• No sucede para el mismo número de casos de prueba (entre 3 y 9)
• A veces no sucede, todo pasa

Aunque no puedo garantizar que esto no suceda localmente (cuando se ejecuta en la misma base de datos, por supuesto), he 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 algo de investigación, esto es lo que se nos ocurrió.

El error se debe obviamente al hecho de que el oyente no estaba aceptando conexiones, pero ¿por qué obtendríamos ese error cuando otras pruebas podrían conectarse bien (también podríamos conectarnos sin problemas 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, encontramos que se crearon algunos datos estáticos durante la configuración de la clase que mantendrían las conexiones abiertas durante la vida de la clase de prueba, creando nuevas a medida que avanzaban. Ahora, aunque todos los recursos se liberaron correctamente cuando esta clase quedó fuera del alcance (a través de un bloque finalmente {}, 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 era un código de prueba de unidad que se conectaba directamente en lugar de usar un grupo, por lo que el mismo problema no podía ocurrir en la producción).

La solución fue no hacer que la clase sea estática y ejecutarse en la configuración de la clase, sino usarla en los métodos setUp y tearDown por método.

Entonces, si obtienes este error en tus propias aplicaciones, golpea un generador de perfiles en ese chico malo y ve si puedes tener una fuga de conexión. Espero que ayude.

Answer 2

Otra solución que encontré para un error similar, pero el mismo mensaje de error es aumentar el número de manejadores de servicios encontrados. (Mi instancia de este error fue causada por demasiadas conexiones en los grupos de conexiones de Weblogic Portal).

• Ejecute SQL * Plus e inicie sesión como SYSTEM . Debe saber qué contraseña ha utilizado durante la instalación de Oracle DB XE.
• Ejecute el comando alterar los procesos del conjunto del sistema = 150 scope = spfile; en SQL * Plus
• MUY IMPORTANTE: reinicia la base de datos.

Desde 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, busqué las respuestas en muchos lugares. Obtuve muchas respuestas similares para cambiar la cantidad de manejadores de procesos / servicios. Pero pensé, ¿qué pasa si me olvido de restablecerlo?

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

No sé cómo, pero está funcionando al menos para mí.

Si alguien quiere probarlo y descubrir cómo está funcionando, 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. Ocurrió cada vez que ejecutaba un paquete de pruebas de base de datos (Spring JDBC) con la anotación de SpringJUnit4ClassRunner , así que resolví el problema poniendo la anotación de @DirtiesContext para cada prueba con el fin de limpiar el contexto de la aplicación y libere todos los recursos, por lo que cada prueba podría ejecutarse con una nueva inicialización del contexto de la aplicación.

Answer 5

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

Agregué un Thread.sleep (500) en el desmontaje () de mis pruebas y esto resolvió el problema. Creo que lo que estaba ocurriendo era que el grupo de conexiones stop () libera las conexiones activas en otro hilo, de modo que si el hilo principal continúa ejecutándose, los hilos de limpieza se retrasaron tanto que el servidor Oracle se quedó sin conexiones. Al agregar el modo de espera, las secuencias de fondo liberan las conexiones agrupadas.

Este es un problema mucho menor en el mundo real porque los servidores de base de datos son mucho más grandes y hay una combinación saludable de operaciones (no solo operaciones de conexión / desconexión de base de datos infinitas).