¿Sesión de Oracle caída por la VPN? Revisa las capas de keepalive

Veinticinco minutos de trabajo útil de base de datos producen casi ninguna salida, y desde cada dispositivo del camino ese flujo parece inactivo. El estado inactivo es exactamente lo que se recoge. El informe posterior siempre tiene la misma forma: la consulta estaba en marcha, luego la sesión desapareció y el resultado nunca llegó.

Cuatro comprobaciones deciden si una sesión silenciosa sobrevive, y van del socket hacia fuera. Hazlas en orden, porque cada una da por hecho que la capa anterior hace su trabajo.

Qué flujo se queda callado

La conexión que importa es la que transporta el tráfico de base de datos, identificada por sus propias direcciones y puertos. Nada más la refresca. Un ping a una puerta de enlace, una segunda conexión SQL desde el mismo host y el latido propio del túnel son flujos separados con estado separado en cada dispositivo que los sigue.

ss -tio dst 10.60.4.20
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes

El listado de sockets muestra temporizadores y estado de cola de la conexión viva, lo que informa más que una prueba de alcanzabilidad. Los valores de sysctl son los predeterminados del kernel para el comportamiento de keepalive, y la sección siguiente explica por qué puede que nunca se apliquen a tu sesión. Un valor predeterminado que nunca se dispara es indistinguible de no tener ninguno.

Anota las direcciones, los puertos y la interfaz que usa la conexión. Cuando una sesión muere, esos detalles son los que te permiten preguntar al dispositivo correcto qué hizo, en lugar de preguntar si la red estaba activa.

Si la política de inactividad caduca o limita

Dos políticas producen el mismo síntoma y exigen respuestas opuestas. Un tiempo de espera por inactividad elimina estado que el tráfico válido podría haber refrescado, y un keepalive puede evitarlo. Un límite absoluto de sesión elimina el flujo tras una duración fija independientemente de la actividad, y ningún keepalive cambia eso.

Pregunta al responsable de cada intermediario cuál de las dos implementa. Un cortafuegos, un dispositivo NAT, un balanceador de carga y una puerta de enlace en la nube pueden guardar estado, y no tienen que coincidir. El más estricto fija el plazo que debes batir.

Esa distinción también te dice cuándo dejar de ajustar. Si la política es un límite absoluto, la solución correcta es una unidad de trabajo más corta, un trabajo reanudable o una excepción aprobada, y la comprobación de abajo solo confirmará que los keepalives no cambiaron nada.

El conmutador del socket tras los valores de Linux

El keepalive es opcional por socket. Los valores del kernel describen cómo se comportan las sondas una vez que un socket ha habilitado el mecanismo, y no lo habilitan para conexiones existentes. Una aplicación que nunca lo pide no recibe sondas, digan lo que digan los valores de sysctl.

Por eso subir los números por sí solo no cambia nada para un cliente de base de datos. La biblioteca cliente o la aplicación tiene que habilitar el mecanismo, y donde la pila expone controles por conexión, un ajuste acotado supera a un cambio en todo el host que afecta a servicios no relacionados.

El intervalo hasta la primera sonda tampoco es un tiempo de espera de consulta. Una conexión sana permanece callada entre sondas, y un par muerto se reconoce según el intervalo y el número de sondas. Leer esos tres valores como un solo tiempo de espera es como la gente llega a ajustes que detectan el fallo demasiado tarde o con demasiada impaciencia. Controlan la detección, no la paciencia de la aplicación.

EXPIRE_TIME es un ajuste de base de datos, no una solución de red

Oracle Net ofrece su propio mecanismo de vitalidad, configurado en el perfil efectivo del proceso y no en un archivo arbitrario que casualmente tenga un nombre parecido. El valor se expresa en minutos.

SQLNET.EXPIRE_TIME = 5

Su propósito principal es la detección en el servidor de conexiones muertas, y en las plataformas que admiten el modelo mejorado también ajusta el comportamiento de keepalive de TCP para esas conexiones. Es una propiedad útil: significa que la capa de base de datos puede organizar sondas sin pedir a la aplicación cliente que cambie.

El valor ilustrativo de arriba es una elección coordinada frente a un plazo supuesto, no una recomendación. La guía general documentada es un intervalo más largo, y el número correcto depende de la implementación instalada, del coste de sondas que aceptes y de las reglas reales de refresco en el camino. Pon el ajuste en el perfil que lee el proceso correspondiente y confirma que el proceso lo ha recogido. Oracle documenta las ubicaciones del perfil y el comportamiento de detección en su referencia de parámetros.

Prueba el intervalo silencioso y luego planifica la recuperación

Haz pasar una conexión nueva y permitida por un periodo silencioso más largo que el plazo que intentas batir, y vigila el tráfico de vitalidad y el resultado de la aplicación. No captures contenido de carga que no necesites; los temporizadores y el estado de la conexión responden a la pregunta.

ss -tio dst 10.60.4.20
# after the quiet interval, same command
ls -l "$ORACLE_HOME/network/admin/sqlnet.ora"

Si la sesión sigue desapareciendo, el plazo pertenece a un dispositivo al que aún no has preguntado, o la política es un límite absoluto. Si sobrevive, anota qué capa cambió para que la siguiente operación silenciosa no repita la investigación.

Por último, decide qué ocurre cuando la conexión sí se cae, porque las comprobaciones de vitalidad reducen la frecuencia y nunca eliminan la posibilidad. Establece el resultado registrado de la operación de base de datos antes de reenviarla: perder la respuesta no demuestra nada sobre si el trabajo se confirmó. Para todo lo que deba sobrevivir al cierre de un portátil o al reinicio de un túnel, un trabajo propiedad del servidor con un resultado duradero es el diseño más sólido, y un keepalive no es un planificador.