Session Oracle coupée via le VPN ? Vérifiez les couches keepalive

Vingt-cinq minutes de travail utile sur la base de données ne produisent presque aucune sortie, et depuis chaque équipement du chemin ce flux paraît inactif. L’état inactif est exactement ce qui est ramassé. Le rapport qui suit a toujours la même forme : la requête tournait, puis la session a disparu, et le résultat n’est jamais arrivé.

Quatre vérifications décident si une session silencieuse survit, et elles se font du socket vers l’extérieur. Faites-les dans l’ordre, car chacune suppose que la couche précédente fait son travail.

Quel flux devient silencieux

La connexion qui compte est celle qui transporte le trafic de base de données, identifiée par ses propres adresses et ports. Rien d’autre ne la rafraîchit. Un ping vers une passerelle, une deuxième connexion SQL depuis le même hôte et le battement propre du tunnel sont des flux distincts avec un état distinct sur chaque équipement qui les suit.

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

La liste des sockets montre les minuteries et l’état de file de la connexion active, ce qui est plus instructif qu’un test d’accessibilité. Les valeurs sysctl sont celles du noyau pour le comportement keepalive, et la section suivante explique pourquoi elles peuvent ne jamais s’appliquer à votre session. Une valeur par défaut qui ne se déclenche jamais est indistinguable d’aucune valeur par défaut.

Notez les adresses, les ports et l’interface qu’utilise la connexion. Quand une session meurt, ce sont ces détails qui vous permettent de demander au bon équipement ce qu’il a fait, plutôt que de demander si le réseau était disponible.

Si la politique d’inactivité expire ou limite

Deux politiques produisent le même symptôme et appellent des réponses opposées. Un délai d’inactivité supprime un état que du trafic éligible aurait pu rafraîchir, et un keepalive peut l’empêcher. Une limite absolue de session supprime le flux après une durée fixe quelle que soit l’activité, et aucun keepalive n’y change rien.

Demandez au responsable de chaque intermédiaire laquelle des deux il met en œuvre. Un pare-feu, un équipement NAT, un répartiteur de charge et une passerelle cloud peuvent tous conserver un état, et ils n’ont pas à être d’accord. Le plus étroit fixe l’échéance que vous devez battre.

Cette distinction vous dit aussi quand arrêter de régler. Si la politique est une limite absolue, la bonne solution est une unité de travail plus courte, une tâche reprenable ou une exception approuvée, et la vérification ci-dessous confirmera simplement que les keepalives n’ont rien changé.

L’interrupteur de socket derrière les valeurs par défaut de Linux

Le keepalive est optionnel par socket. Les valeurs par défaut du noyau décrivent le comportement des sondes une fois qu’un socket a activé le mécanisme, et elles ne l’activent pas pour les connexions existantes. Une application qui ne le demande jamais n’obtient aucune sonde, quelles que soient les valeurs sysctl.

C’est pourquoi augmenter les nombres seul ne change rien pour un client de base de données. La bibliothèque cliente ou l’application doit activer le mécanisme, et là où la pile expose des contrôles par connexion, un réglage ciblé vaut mieux qu’un changement à l’échelle de l’hôte qui touche des services sans rapport.

L’intervalle jusqu’à la première sonde n’est pas non plus un délai d’expiration de requête. Une connexion saine reste silencieuse entre les sondes, et un pair mort est reconnu selon l’intervalle et le nombre de sondes. Lire ces trois valeurs comme un seul délai mène à des réglages qui détectent la panne bien trop tard ou bien trop tôt. Elles contrôlent la détection, pas la patience de l’application.

EXPIRE_TIME est un réglage de base de données, pas une correction réseau

Oracle Net offre son propre mécanisme de vivacité, configuré dans le profil effectif du processus plutôt que dans un fichier arbitraire qui porte par hasard un nom similaire. La valeur est exprimée en minutes.

SQLNET.EXPIRE_TIME = 5

Son but principal est la détection côté serveur des connexions mortes, et sur les plateformes qui prennent en charge le modèle amélioré, il ajuste aussi le comportement keepalive de TCP pour ces connexions. C’est une propriété utile : la couche base de données peut organiser des sondes sans demander à l’application cliente de changer.

La valeur illustrative ci-dessus est un choix coordonné face à une échéance supposée, pas une recommandation. La recommandation générale documentée est un intervalle plus long, et le bon nombre dépend de l’implémentation installée, du coût des sondes que vous acceptez et des règles réelles de rafraîchissement sur le chemin. Placez le réglage dans le profil que lit le processus concerné, et confirmez que le processus l’a pris en compte. Oracle documente les emplacements des profils et le comportement de détection dans sa référence des paramètres.

Testez l’intervalle silencieux, puis planifiez la reprise

Faites passer une connexion autorisée neuve par une période silencieuse plus longue que l’échéance que vous cherchez à battre, et surveillez le trafic de vivacité et le résultat de l’application. Ne capturez pas de contenu utile dont vous n’avez pas besoin ; les minuteries et l’état de connexion répondent à la question.

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

Si la session disparaît encore, l’échéance appartient à un équipement que vous n’avez pas encore interrogé, ou la politique est une limite absolue. Si elle survit, notez quelle couche a changé pour que l’opération silencieuse suivante ne répète pas l’enquête.

Enfin, décidez ce qui se passe quand la connexion tombe vraiment, car les contrôles de vivacité réduisent la fréquence et n’en suppriment jamais la possibilité. Établissez le résultat enregistré de l’opération de base de données avant de la soumettre à nouveau : perdre la réponse ne prouve rien sur le fait que le travail a été validé. Pour tout ce qui doit survivre à la fermeture d’un portable ou au redémarrage d’un tunnel, une tâche détenue par le serveur avec un résultat durable est la conception la plus solide, et un keepalive n’est pas un ordonnanceur.