Sessió d’Oracle caiguda per la VPN? Reviseu les capes de keepalive

Vint-i-cinc minuts de feina útil de base de dades gairebé no produeixen sortida, i des de cada dispositiu del camí aquest flux sembla inactiu. L’estat inactiu és exactament el que es recull. L’informe posterior sempre té la mateixa forma: la consulta s’executava, després la sessió va desaparèixer i el resultat no va arribar mai.

Quatre comprovacions decideixen si una sessió silenciosa sobreviu, i van del socket cap enfora. Feu-les en ordre, perquè cadascuna assumeix que la capa anterior fa la seva feina.

Quin flux es queda en silenci

La connexió que importa és la que transporta el trànsit de base de dades, identificada per les seves pròpies adreces i ports. Res més la refresca. Un ping a una passarel·la, una segona connexió SQL des del mateix host i el batec propi del túnel són fluxos separats amb estat separat a cada dispositiu que els segueix.

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

El llistat de sockets mostra temporitzadors i estat de cua de la connexió viva, cosa que informa més que una prova d’abastabilitat. Els valors de sysctl són els predeterminats del nucli per al comportament de keepalive, i la secció següent explica per què potser mai s’apliquen a la vostra sessió. Un valor predeterminat que no es dispara mai és indistingible de no tenir-ne cap.

Anoteu les adreces, els ports i la interfície que fa servir la connexió. Quan una sessió mor, aquests detalls són els que us permeten preguntar al dispositiu correcte què va fer, en lloc de preguntar si la xarxa estava activa.

Si la política d’inactivitat caduca o limita

Dues polítiques produeixen el mateix símptoma i exigeixen respostes oposades. Un temps d’espera per inactivitat elimina estat que el trànsit elegible hauria pogut refrescar, i un keepalive ho pot evitar. Un límit absolut de sessió elimina el flux després d’una durada fixa independentment de l’activitat, i cap keepalive ho canvia.

Pregunteu al propietari de cada intermediari quina de les dues implementa. Un tallafoc, un dispositiu NAT, un balancejador de càrrega i una passarel·la al núvol poden tots guardar estat, i no cal que coincideixin. El més estret fixa el termini que heu de batre.

Aquesta distinció també us diu quan deixar d’ajustar. Si la política és un límit absolut, la solució correcta és una unitat de feina més curta, una tasca reprenable o una excepció aprovada, i la comprovació de sota només confirmarà que els keepalives no van canviar res.

L’interruptor del socket darrere dels valors de Linux

El keepalive és opcional per socket. Els valors del nucli descriuen com es comporten les sondes un cop un socket ha habilitat el mecanisme, i no l’habiliten per a connexions existents. Una aplicació que no el demana mai no rep sondes, diguin el que diguin els valors de sysctl.

Per això pujar els números tot sol no canvia res per a un client de base de dades. La biblioteca client o l’aplicació ha d’habilitar el mecanisme, i on la pila exposa controls per connexió, un ajust acotat supera un canvi a tot l’host que afecta serveis sense relació.

L’interval fins a la primera sonda tampoc no és un temps d’espera de consulta. Una connexió sana es queda en silenci entre sondes, i un parell mort es reconeix segons l’interval i el nombre de sondes. Llegir aquests tres valors com un sol temps d’espera és com la gent arriba a ajustos que detecten la fallada massa tard o massa aviat. Controlen la detecció, no la paciència de l’aplicació.

EXPIRE_TIME és un ajust de base de dades, no una solució de xarxa

Oracle Net ofereix el seu propi mecanisme de vitalitat, configurat al perfil efectiu del procés i no en un fitxer arbitrari que casualment tingui un nom semblant. El valor s’expressa en minuts.

SQLNET.EXPIRE_TIME = 5

El seu propòsit principal és la detecció al servidor de connexions mortes, i a les plataformes que admeten el model millorat també ajusta el comportament de keepalive de TCP per a aquestes connexions. És una propietat útil: la capa de base de dades pot organitzar sondes sense demanar a l’aplicació client que canviï.

El valor il·lustratiu de dalt és una elecció coordinada contra un termini suposat, no una recomanació. La guia general documentada és un interval més llarg, i el número correcte depèn de la implementació instal·lada, del cost de sondes que accepteu i de les regles reals de refresc al camí. Posa l’ajust al perfil que llegeix el procés corresponent i confirmeu que el procés l’ha recollit. Oracle documenta les ubicacions del perfil i el comportament de detecció a la seva referència de paràmetres.

Proveu l’interval silenciós i després planifiqueu la recuperació

Feu passar una connexió nova i permesa per un període silenciós més llarg que el termini que intenteu batre, i vigileu el trànsit de vitalitat i el resultat de l’aplicació. No captureu contingut de càrrega que no necessiteu; els temporitzadors i l’estat de la connexió responen 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 sessió encara desapareix, el termini pertany a un dispositiu que encara no heu preguntat, o la política és un límit absolut. Si sobreviu, anoteu quina capa ha canviat perquè la propera operació silenciosa no repeteixi la investigació.

Finalment, decidiu què passa quan la connexió sí que cau, perquè les comprovacions de vitalitat redueixen la freqüència i mai no eliminen la possibilitat. Establiu el resultat registrat de l’operació de base de dades abans de tornar-la a enviar: perdre la resposta no demostra res sobre si la feina s’ha confirmat. Per a tot el que hagi de sobreviure al tancament d’un portàtil o a un reinici del túnel, una tasca propietat del servidor amb un resultat durador és el disseny més sòlid, i un keepalive no és un planificador.