ODP.NET: evitar tiempos de espera de conexión con agrupación de conexiones

Question

En un sitio puedo conectarme a la base de datos Oracle con SQL Developer, dejarlo inactivo durante mucho tiempo (por ejemplo,> 60 minutos) y regresar, y todo está bien. En un segundo sitio, si permanece inactivo durante más de 5-10 minutos (no he contado exactamente), deja SQL Developer en un estado en el que las nuevas operaciones agotarán el tiempo de espera y tendré que "Desconectar" manualmente y luego volver a conectar en orden hacer algo útil Esto parece ser un tiempo de espera de conexión en el segundo sitio, y no sé qué lo causa (y me gustaría saber cómo desactivarlo, aunque esta no es mi principal pregunta).

Mi programa usa ODP.NET y procesa los datos que vienen en rachas. Cada 30 minutos (por el bien de la discusión) obtendrá un montón de datos para procesar, lo que implicará una serie de conexiones repetidas. También usa Connection Pooling. Establecí Connection Pool para usar Lifetime de 5 minutos.

Lo que estoy viendo en el segundo sitio (y no en el primero) es que mi programa obtendrá excepciones de tiempo de espera de conexión (por ejemplo, ORA-03113) al comienzo de cada arranque de datos. Lo que creo que está sucediendo es que, durante el aumento de los datos, el grupo de conexiones se usa según lo diseñado. Al final del ciclo, se verifica "Duración de la conexión" y la conexión no es demasiado antigua, por lo que queda en el grupo de conexiones. Luego, 30 minutos más tarde, cuando llegan nuevos datos, la conexión se elimina del grupo (y no se comprueba para toda la vida o el tiempo de espera) y se usa, y se está agotando, tal como lo veo en SQL Developer.

¿Cómo puedo evitar el tiempo de espera de conexión, pero aún así aprovechar el Pool de conexión durante los chorros? Parece de la documentación (y de mi experiencia) que la conexión solo se verifica para Lifetime cuando entra en el pool, y no cuando sale.

Answer 1

Puede especificar el tiempo de espera infinito estableciendo la propiedad OracleCommand.ConnectionTimeout en 0. En este caso no habrá tiempo de espera (al menos en el lado del cliente).

ConnectionPool también se utiliza en este caso.

Answer 2

Si la configuración de por vida de 5 minutos funciona bien en el primer sitio, entonces creo que esto podría deberse a que alguien establece el tiempo de espera de la sesión inactiva en un perfil en el lado del servidor de Oracle.

Sin embargo, con la configuración de por vida de 5 min, es posible que aún se agote el tiempo de espera cuando el chorro aumenta, porque cuando devuelva las conexiones a la piscina en el siguiente chorro se destruirán. Luego, el grupo estará ocupado creando y eliminando conexiones y podría ocasionar un tiempo de espera de conexión cuando la carga es realmente grande.

Answer 3

Esta es una pregunta muy antigua, pero he estado experimentando algunos problemas similares con una aplicación, por lo que creo que parte de la información podría ayudar a cualquier otra persona que tropiece con esta pregunta.

El resumen de TL; DR es que los controladores ODP.NET y la implementación de .NET no funcionan bien entre sí y por lo tanto su ejecución normal de la configuración de agrupación de conexiones de fábrica no parece funcionar exactamente como se esperaría .

• conexión de por vida es el delincuente primario. No estoy seguro de si this blog todavía es aplicable, ya que es bastante viejo, pero no he encontrado ninguna documentación para refutarlo y parece verificar el comportamiento que estoy viendo. Según el blog, Connection Lifetime mata a una sesión más antigua como se esperaba, pero la comprobación de este parámetro solo ocurre cuando se realiza una llamada a la base de datos. En otras palabras, las sesiones inactivas de larga duración nunca serán destruidas por .NET.
• Si tiene IDLE_TIME configurado en un valor en su perfil de usuario de Oracle (y no en UNLIMITED) entonces eventualmente estos parámetros inactivos de larga ejecución serán SNIPED por la base de datos. Esto puede llegar a causar problemas en el lado .NET porque a menos que se está comprobando de forma explícita que sus conexiones están aún abiertas, .NET va a servir a estos SNIPED conexiones como si todavía están disponibles (arrojando así el tiempo de espera de error ORA arriba).
• El truco evitar este problema es asegurarse de que tiene Data Validation=True; en la cadena de conexión. Esto asegura que .NET verificará la conectividad de la sesión antes de que sirva la conexión hasta la siguiente llamada de servicio. Cuando esta validación ve una sesión SNIPED, la elimina del grupo de conexiones .NET.

Dada esta información, lo más probable es que el problema original de la OP solamente aparecía en el sitio de una combinación de diferentes configuraciones de bases de datos y/o la frecuencia de la .NET llama a la base de datos. Que podría haber tenido el problema en ambos entornos, pero si los usuarios de un entorno estaban haciendo llamadas con frecuencia suficiente para Connection Lifetime a hacer su trabajo y luego no volver a ver estos tiempos de espera en esa base de datos.

Ahora todavía no han descubierto la manera de matar una conexión inactiva en .NET antes de cualquier francotiradores Oracle idle_time tiene lugar pero siempre y cuando se utiliza ese Data Validation = True parámetro que debe espera que sea capaz de solucionar este problema.