Sesiune Oracle pierdută prin VPN? Verificați straturile keepalive

Douăzeci și cinci de minute de lucru util la baza de date nu produc aproape nimic la ieșire, iar din perspectiva fiecărui dispozitiv de pe traseu acel flux pare inactiv. Starea inactivă este exact ceea ce se colectează. Raportul de după are mereu aceeași formă: interogarea rula, apoi sesiunea a dispărut, iar rezultatul nu a ajuns niciodată.

Patru verificări decid dacă o sesiune liniștită supraviețuiește, și ele se fac de la socket spre exterior. Faceți-le în ordine, pentru că fiecare presupune că stratul anterior își face treaba.

Care flux devine liniștit

Conexiunea care contează este cea care transportă traficul bazei de date, identificată prin propriile adrese și porturi. Nimic altceva nu o reîmprospătează. Un ping către o poartă, o a doua conexiune SQL de pe același host și bătăile proprii ale tunelului sunt fluxuri separate, cu stare separată pe fiecare dispozitiv care le urmărește.

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

Listarea socketurilor arată temporizatoare și starea cozii pentru conexiunea activă, ceea ce spune mai mult decât un test de accesibilitate. Valorile sysctl sunt valorile implicite ale nucleului pentru comportamentul keepalive, iar secțiunea următoare explică de ce s-ar putea să nu se aplice niciodată sesiunii dumneavoastră. O valoare implicită care nu se declanșează niciodată nu se poate distinge de lipsa oricărei valori implicite.

Notați adresele, porturile și interfața pe care le folosește conexiunea. Când o sesiune moare, aceste detalii sunt cele care vă permit să întrebați dispozitivul potrivit ce a făcut, în loc să întrebați dacă rețeaua era pornită.

Dacă politica de inactivitate expiră sau limitează

Două politici produc același simptom și cer răspunsuri opuse. Un timeout de inactivitate elimină starea pe care traficul eligibil ar fi putut-o reîmprospăta, iar un keepalive poate împiedica asta. O limită absolută de sesiune elimină fluxul după o durată fixă, indiferent de activitate, și niciun keepalive nu schimbă asta.

Întrebați proprietarul fiecărui intermediar pe care dintre cele două îl implementează. Un firewall, un dispozitiv NAT, un balanceator de încărcare și o poartă cloud pot toate păstra stare, și nu trebuie să fie de acord. Cel mai îngust stabilește termenul pe care trebuie să-l bateți.

Această distincție vă spune și când să vă opriți din reglaje. Dacă politica este o limită absolută, soluția corectă este o unitate de lucru mai scurtă, un job reluabil sau o excepție aprobată, iar verificarea de mai jos va confirma doar că keepalive-urile nu au schimbat nimic.

Comutatorul socketului din spatele valorilor implicite Linux

Keepalive este opțional per socket. Valorile implicite ale nucleului descriu cum se comportă sondele după ce un socket a activat mecanismul, și nu îl activează pentru conexiunile existente. O aplicație care nu îl cere niciodată nu primește sonde, orice ar spune valorile sysctl.

De aceea creșterea numerelor singură nu schimbă nimic pentru un client de bază de date. Biblioteca client sau aplicația trebuie să activeze mecanismul, iar acolo unde stiva expune controale per conexiune, o setare limitată bate o modificare la nivel de host care afectează servicii nelegate.

Intervalul până la prima sondă nu este nici el un timeout de interogare. O conexiune sănătoasă rămâne liniștită între sonde, iar un peer mort este recunoscut după intervalul și numărul sondelor. Citirea acestor trei valori ca un singur timeout este felul în care oamenii ajung la setări care detectează defecțiunea fie mult prea târziu, fie mult prea grăbit. Ele controlează detectarea, nu răbdarea aplicației.

EXPIRE_TIME este o setare a bazei de date, nu o reparație de rețea

Oracle Net oferă propriul mecanism de vitalitate, configurat în profilul efectiv al procesului, nu într-un fișier arbitrar care se întâmplă să aibă un nume similar. Valoarea este exprimată în minute.

SQLNET.EXPIRE_TIME = 5

Scopul său principal este detectarea pe server a conexiunilor moarte, iar pe platformele care acceptă modelul îmbunătățit reglează și comportamentul keepalive TCP pentru acele conexiuni. Aceasta este o proprietate utilă: stratul bazei de date poate organiza sonde fără a cere aplicației client să se schimbe.

Valoarea ilustrativă de mai sus este o alegere coordonată față de un termen presupus, nu o recomandare. Ghidul general documentat este un interval mai lung, iar numărul potrivit depinde de implementarea instalată, de costul sondelor pe care îl acceptați și de regulile reale de reîmprospătare de pe traseu. Puneți setarea în profilul pe care îl citește procesul relevant și confirmați că procesul a preluat-o. Oracle documentează locațiile profilului și comportamentul de detectare în referința de parametri.

Testați intervalul liniștit, apoi planificați recuperarea

Lăsați o conexiune nouă și permisă să treacă printr-o perioadă liniștită mai lungă decât termenul pe care încercați să-l bateți și urmăriți traficul de vitalitate și rezultatul aplicației. Nu capturați conținut de sarcină utilă de care nu aveți nevoie; temporizatoarele și starea conexiunii răspund la întrebare.

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

Dacă sesiunea dispare în continuare, termenul aparține unui dispozitiv pe care nu l-ați întrebat încă, sau politica este o limită absolută. Dacă supraviețuiește, notați care strat s-a schimbat, ca operația liniștită următoare să nu repete investigația.

În final, decideți ce se întâmplă când conexiunea chiar cade, pentru că verificările de vitalitate reduc frecvența și nu elimină niciodată posibilitatea. Stabiliți rezultatul înregistrat al operației de bază de date înainte de a o trimite din nou: pierderea răspunsului nu dovedește nimic despre faptul că lucrul a fost confirmat. Pentru tot ce trebuie să supraviețuiască închiderii unui laptop sau repornirii unui tunel, un job deținut de server cu un rezultat durabil este proiectul mai solid, iar un keepalive nu este un planificator.