Oracle-session droppet over VPN? Kontroller keepalive-lagene

Femogtyve minutters nyttigt databasearbejde giver næsten ingen output, og fra enhver enhed på vejen ser den strøm inaktiv ud. Inaktiv tilstand er præcis det, der bliver samlet op. Rapporten bagefter har altid samme form: forespørgslen kørte, så forsvandt sessionen, og resultatet kom aldrig frem.

Fire kontroller afgør, om en stille session overlever, og de kører fra socket og udad. Tag dem i rækkefølge, for hver af dem forudsætter, at det foregående lag passer sit arbejde.

Hvilken strøm bliver stille

Den forbindelse, der betyder noget, er den, der bærer databasetrafikken, identificeret ved sine egne adresser og porte. Intet andet fornyer den. En ping til en gateway, en anden SQL-forbindelse fra samme vært og tunnelens eget hjerteslag er separate strømme med separate tilstande på hver enhed, der følger 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-oversigten viser timere og køtilstand for den levende forbindelse, hvilket er mere informativt end en nåbarhedstest. sysctl-værdierne er kernelens standardværdier for keepalive-adfærd, og næste afsnit forklarer, hvorfor de måske aldrig gælder for din session. En standard, der aldrig udløses, kan ikke skelnes fra ingen standard overhovedet.

Skriv adresserne, portene og det interface ned, som forbindelsen bruger. Når en session dør, er det disse detaljer, der lader dig spørge den rigtige enhed, hvad den gjorde, i stedet for at spørge, om netværket var oppe.

Udløber ledighedspolitikken, eller begrænser den

To politikker giver samme symptom og kræver modsatte svar. En ledighedstimeout fjerner tilstand, som kvalificerende trafik kunne have fornyet, og en keepalive kan forhindre det. En absolut sessionsgrænse fjerner strømmen efter en fast varighed uanset aktivitet, og ingen keepalive ændrer det.

Spørg ejeren af hver mellemstation, hvilken af dem den implementerer. En firewall, en NAT-enhed, en load balancer og en cloud-gateway kan alle holde tilstand, og de behøver ikke være enige. Den snævreste sætter den frist, du skal slå.

Den forskel fortæller dig også, hvornår du skal stoppe med at justere. Er politikken en absolut grænse, er det korrekte svar en kortere arbejdsenhed, et genoptageligt job eller en godkendt undtagelse, og kontrollen nedenfor bekræfter så blot, at keepalives ikke gjorde nogen forskel.

Socket-kontakten bag Linux-standardværdierne

Keepalive er tilvalg per socket. Kernelens standardværdier beskriver, hvordan prober opfører sig, når en socket først har aktiveret mekanismen, og de aktiverer den ikke for eksisterende forbindelser. En applikation, der aldrig beder om det, får ingen prober, uanset hvad sysctl-værdierne siger.

Derfor ændrer det intet for en databaseklient at hæve tallene alene. Klientbiblioteket eller applikationen skal aktivere mekanismen, og hvor stakken giver kontroller per forbindelse, slår en afgrænset indstilling en ændring for hele værten, der påvirker urelaterede tjenester.

Intervallet til den første probe er heller ikke en forespørgselstimeout. En sund forbindelse forbliver stille mellem prober, og en død peer genkendes efter probeinterval og -antal. At læse de tre værdier som én timeout er, hvordan folk når indstillinger, der opdager fejl enten alt for sent eller alt for ivrigt. De styrer registreringen, ikke applikationens tålmodighed.

EXPIRE_TIME er en databaseindstilling, ikke en netværksrettelse

Oracle Net tilbyder sin egen livstegnsmekanisme, konfigureret i den effektive profil for processen snarere end i en vilkårlig fil, der tilfældigvis har et lignende navn. Værdien angives i minutter.

SQLNET.EXPIRE_TIME = 5

Dens primære formål er serversidig registrering af døde forbindelser, og på platforme, der understøtter den forbedrede model, justerer den også TCP keepalive-adfærd for disse forbindelser. Det er en nyttig egenskab: det betyder, at databaselaget kan sørge for prober uden at bede klientapplikationen om at ændre sig.

Eksempelværdien ovenfor er et koordineret valg mod en antaget frist, ikke en anbefaling. Den dokumenterede generelle vejledning er et længere interval, og det rigtige tal afhænger af den installerede implementering, den probeomkostning du accepterer og de faktiske fornyelsesregler på vejen. Sæt indstillingen i den profil, som den relevante proces læser, og bekræft, at processen har taget den op. Oracle dokumenterer profilplaceringerne og registreringsadfærden i sin parameterreference.

Test det stille interval, og planlæg derefter genopretning

Kør en ny tilladt forbindelse gennem en stille periode, der er længere end den frist, du prøver at slå, og hold øje med livstegnstrafikken og applikationsresultatet. Optag ikke nyttelastindhold, du ikke har brug for; timere og forbindelsestilstand besvarer spørgsmålet.

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

Forsvinder sessionen stadig, tilhører fristen en enhed, du endnu ikke har spurgt, eller politikken er en absolut grænse. Overlever den, så noter, hvilket lag der blev ændret, så den næste stille operation ikke gentager undersøgelsen.

Beslut til sidst, hvad der sker, når forbindelsen faktisk falder, for livstegnskontroller nedsætter hyppigheden og fjerner aldrig muligheden. Fastslå databaseoperationens registrerede udfald, før du sender den igen: at svaret forsvinder beviser intet om, hvorvidt arbejdet blev committet. For alt, der skal overleve, at en laptop lukkes, eller at en tunnel genstarter, er et serverejet job med et varigt resultat det stærkere design, og en keepalive er ikke en scheduler.