Oracle-session tappad över VPN? Kontrollera keepalive-lagren

Tjugofem minuters nyttigt databasarbete ger nästan ingen utdata, och från varje enhet på vägen ser det flödet inaktivt ut. Inaktivt tillstånd är precis vad som samlas upp. Rapporten efteråt har alltid samma form: frågan körde, sedan försvann sessionen, och resultatet kom aldrig fram.

Fyra kontroller avgör om en tyst session överlever, och de går från socketen och utåt. Gör dem i ordning, för varje kontroll förutsätter att lagret innan gör sitt jobb.

Vilket flöde blir tyst

Anslutningen som spelar roll är den som bär databastrafiken, identifierad av sina egna adresser och portar. Inget annat fräschar upp den. En ping till en gateway, en andra SQL-anslutning från samma värd och tunnelns egen hjärtslag är separata flöden med separat tillstånd på varje enhet som följer dem.

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

Socket-listan visar timers och kötillstånd för den levande anslutningen, vilket säger mer än ett nåbarhetstest. sysctl-värdena är kernlens standardvärden för keepalive-beteende, och nästa avsnitt förklarar varför de kanske aldrig gäller för din session. Ett standardvärde som aldrig utlöses går inte att skilja från inget standardvärde alls.

Skriv ner adresserna, portarna och gränssnittet som anslutningen använder. När en session dör är det de detaljerna som låter dig fråga rätt enhet vad den gjorde, i stället för att fråga om nätverket var uppe.

Om inaktivitetsprincipen löper ut eller begränsar

Två principer ger samma symptom och kräver motsatta svar. En inaktivitets-timeout tar bort tillstånd som kvalificerande trafik hade kunnat fräscha upp, och en keepalive kan förhindra det. En absolut sessionsgräns tar bort flödet efter en fast varaktighet oavsett aktivitet, och ingen keepalive ändrar det.

Fråga ägaren av varje mellanliggande enhet vilken av de två den implementerar. En brandvägg, en NAT-enhet, en lastbalanserare och en molngateway kan alla hålla tillstånd, och de behöver inte vara överens. Den snävaste sätter tidsfristen du måste slå.

Den skillnaden säger dig också när du ska sluta justera. Om principen är en absolut gräns är rätt lösning en kortare arbetsenhet, ett återupptagbart jobb eller ett godkänt undantag, och kontrollen nedan bekräftar då bara att keepalives inte gjorde någon skillnad.

Socket-brytaren bakom Linux-standardvärdena

Keepalive är opt-in per socket. Kernlens standardvärden beskriver hur prober beter sig när en socket väl har aktiverat mekanismen, och de aktiverar den inte för befintliga anslutningar. Ett program som aldrig ber om det får inga prober, vad sysctl-värdena än säger.

Därför ändrar det inget för en databasklient att bara höja talen. Klientbiblioteket eller programmet måste aktivera mekanismen, och där stacken erbjuder styrning per anslutning vinner en avgränsad inställning över en ändring för hela värden som påverkar orelaterade tjänster.

Intervallet till första proben är inte heller någon frågetimeout. En frisk anslutning är tyst mellan proberna, och en död peer känns igen enligt probe-intervall och antal. Att läsa de tre värdena som en enda timeout är hur folk hamnar i inställningar som upptäcker felet antingen alldeles för sent eller alldeles för ivrigt. De styr upptäckten, inte programmets tålamod.

EXPIRE_TIME är en databasinställning, inte en nätverksfix

Oracle Net erbjuder sin egen livlighetsmekanism, konfigurerad i den effektiva profilen för processen och inte i en godtycklig fil som råkar ha ett liknande namn. Värdet anges i minuter.

SQLNET.EXPIRE_TIME = 5

Dess främsta syfte är serversidig upptäckt av döda anslutningar, och på plattformar som stöder den förbättrade modellen justerar den också TCP keepalive-beteende för dessa anslutningar. Det är en användbar egenskap: databaslagret kan ordna prober utan att be klientprogrammet ändra sig.

Exempelvärdet ovan är ett samordnat val mot en antagen tidsfrist, inte en rekommendation. Den dokumenterade allmänna vägledningen är ett längre intervall, och rätt tal beror på den installerade implementeringen, probe-overheaden du accepterar och de faktiska uppfräschingsreglerna på vägen. Sätt inställningen i den profil som den berörda processen läser, och bekräfta att processen har tagit upp den. Oracle dokumenterar profilplatserna och upptäcktsbeteendet i sin parameterreferens.

Testa det tysta intervallet och planera sedan återhämtning

Låt en ny tillåten anslutning gå genom en tyst period som är längre än tidsfristen du försöker slå, och håll koll på livlighetstrafiken och programmets resultat. Fånga inte nyttolastinnehåll du inte behöver; timers och anslutningstillstånd svarar på frågan.

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

Om sessionen ändå försvinner tillhör tidsfristen en enhet du ännu inte har frågat, eller så är principen en absolut gräns. Om den överlever, anteckna vilket lager som ändrades så att nästa tysta operation inte upprepar utredningen.

Bestäm till sist vad som händer när anslutningen faktiskt faller, för livlighetskontroller minskar frekvensen och tar aldrig bort möjligheten. Fastställ databasoperationens registrerade utfall innan du skickar den igen: att svaret försvinner bevisar ingenting om huruvida arbetet bekräftades. För allt som måste överleva att en laptop stängs eller att en tunnel startas om är ett serverägt jobb med ett varaktigt resultat den starkare designen, och en keepalive är ingen schemaläggare.