Sesión de Oracle caída pola VPN? Revisa as capas de keepalive

Vinte e cinco minutos de traballo útil de base de datos producen case ningunha saída, e desde cada dispositivo do camiño ese fluxo parece inactivo. O estado inactivo é exactamente o que se recolle. O informe posterior sempre ten a mesma forma: a consulta estaba en marcha, despois a sesión desapareceu e o resultado nunca chegou.

Catro comprobacións deciden se unha sesión silenciosa sobrevive, e van do socket cara a fóra. Fainas en orde, porque cada unha dá por feito que a capa anterior fai o seu traballo.

Que fluxo queda en silencio

A conexión que importa é a que transporta o tráfico de base de datos, identificada polas súas propias direccións e portos. Nada máis a refresca. Un ping a unha pasarela, unha segunda conexión SQL desde o mesmo host e o latexado propio do túnel son fluxos separados con estado separado en cada dispositivo que os segue.

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

A listaxe de sockets mostra temporizadores e estado de cola da conexión viva, o que informa máis que unha proba de alcanzabilidade. Os valores de sysctl son os predeterminados do núcleo para o comportamento de keepalive, e a sección seguinte explica por que pode que nunca se apliquen á túa sesión. Un valor predeterminado que nunca se dispara é indistinguible de non ter ningún.

Anota as direccións, os portos e a interface que usa a conexión. Cando unha sesión morre, eses detalles son os que che permiten preguntar ao dispositivo correcto que fixo, en lugar de preguntar se a rede estaba activa.

Se a política de inactividade caduca ou limita

Dúas políticas producen o mesmo síntoma e esixen respostas opostas. Un tempo de espera por inactividade elimina estado que o tráfico elixible podería refrescar, e un keepalive pode evitalo. Un límite absoluto de sesión elimina o fluxo tras unha duración fixa independentemente da actividade, e ningún keepalive cambia iso.

Pregunta ao responsable de cada intermediario cal das dúas implementa. Un cortalumes, un dispositivo NAT, un balanceador de carga e unha pasarela na nube poden todos gardar estado, e non teñen que coincidir. O máis estreito fixa o prazo que debes bater.

Esa distinción tamén che di cando deixar de axustar. Se a política é un límite absoluto, a solución correcta é unha unidade de traballo máis curta, un traballo retomable ou unha excepción aprobada, e a comprobación de abaixo só confirmará que os keepalives non cambiaron nada.

O interruptor do socket detrás dos valores de Linux

O keepalive é opcional por socket. Os valores do núcleo describen como se comportan as sondas unha vez que un socket habilitou o mecanismo, e non o habilitan para conexións existentes. Unha aplicación que nunca o pide non recibe sondas, digan o que digan os valores de sysctl.

Por iso subir os números por si só non cambia nada para un cliente de base de datos. A biblioteca cliente ou a aplicación ten que habilitar o mecanismo, e onde a pila expón controis por conexión, un axuste acoutado supera un cambio en todo o host que afecta servizos sen relación.

O intervalo ata a primeira sonda tampouco é un tempo de espera de consulta. Unha conexión sa permanece calada entre sondas, e un par morto recoñécese segundo o intervalo e o número de sondas. Ler eses tres valores como un único tempo de espera é como a xente chega a axustes que detectan a falla demasiado tarde ou con demasiada ansia. Controlan a detección, non a paciencia da aplicación.

EXPIRE_TIME é un axuste de base de datos, non unha solución de rede

Oracle Net ofrece o seu propio mecanismo de vitalidade, configurado no perfil efectivo do proceso e non nun ficheiro arbitrario que casualmente teña un nome parecido. O valor exprésase en minutos.

SQLNET.EXPIRE_TIME = 5

O seu propósito principal é a detección no servidor de conexións mortas, e nas plataformas que admiten o modelo mellorado tamén axusta o comportamento de keepalive de TCP para esas conexións. É unha propiedade útil: significa que a capa de base de datos pode organizar sondas sen pedir á aplicación cliente que cambie.

O valor ilustrativo de arriba é unha elección coordinada contra un prazo suposto, non unha recomendación. A guía xeral documentada é un intervalo máis longo, e o número correcto depende da implementación instalada, do custo de sondas que aceptes e das regras reais de refresco no camiño. Pon o axuste no perfil que le o proceso correspondente e confirma que o proceso o recolleu. Oracle documenta as localizacións do perfil e o comportamento de detección na súa referencia de parámetros.

Proba o intervalo silencioso e despois planifica a recuperación

Fai pasar unha conexión nova e permitida por un período silencioso máis longo que o prazo que intentas bater, e vixía o tráfico de vitalidade e o resultado da aplicación. Non captures contido de carga que non necesites; os temporizadores e o estado da conexión responden á pregunta.

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

Se a sesión segue desaparecendo, o prazo pertence a un dispositivo que aínda non preguntaches, ou a política é un límite absoluto. Se sobrevive, anota que capa cambiou para que a próxima operación silenciosa non repita a investigación.

Por último, decide que ocorre cando a conexión si cae, porque as comprobacións de vitalidade reducen a frecuencia e nunca eliminan a posibilidade. Establece o resultado rexistrado da operación de base de datos antes de reenviala: perder a resposta non demostra nada sobre se o traballo se confirmou. Para todo o que deba sobrevivir ao peche dun portátil ou a un reinicio do túnel, un traballo propiedade do servidor cun resultado duradeiro é o deseño máis sólido, e un keepalive non é un planificador.