Oracle-munkamenet megszakadt VPN-en? Ellenőrizze a keepalive rétegeket

Huszonöt perc hasznos adatbázis-munka szinte semmilyen kimenetet nem ad, és az útvonal minden eszközéről nézve ez a folyam inaktívnak látszik. Pontosan az inaktív állapot az, amit összegyűjtenek. Az utána készült jelentés mindig ugyanolyan alakú: a lekérdezés futott, aztán a munkamenet eltűnt, és az eredmény soha nem érkezett meg.

Négy ellenőrzés dönti el, hogy egy csendes munkamenet túléli-e, és ezek a socketből kifelé haladnak. Sorrendben végezze el őket, mert mindegyik feltételezi, hogy az előző réteg végzi a dolgát.

Melyik folyam hallgat el

A fontos kapcsolat az, amely az adatbázis-forgalmat szállítja, saját címei és portjai azonosítják. Semmi más nem frissíti. Az átjáró felé küldött ping, egy második SQL-kapcsolat ugyanarról a hosztról és az alagút saját szívverése külön folyamok, külön állapottal minden őket követő eszközön.

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

A socket-lista az élő kapcsolat időzítőit és várakozási sorának állapotát mutatja, ami többet mond egy elérhetőségi tesztnél. A sysctl-értékek a kernel alapértékei a keepalive viselkedéshez, és a következő szakasz elmagyarázza, miért lehet, hogy soha nem érvényesek a munkamenetére. Egy soha be nem induló alapérték megkülönböztethetetlen attól, mintha egyáltalán nem lenne.

Jegyezze fel a címeket, a portokat és az interfészt, amelyet a kapcsolat használ. Amikor egy munkamenet meghal, ezek a részletek teszik lehetővé, hogy a megfelelő eszköztől kérdezze meg, mit tett, ahelyett hogy azt kérdezné, működött-e a hálózat.

Lejár-e az üresjárati házirend, vagy korlátoz

Két házirend ugyanazt a tünetet okozza, és ellentétes válaszokat kíván. Az üresjárati időkorlát eltávolítja azt az állapotot, amelyet a jogosult forgalom frissíthetett volna, és a keepalive ezt megakadályozhatja. Az abszolút munkamenet-korlát fix időtartam után eltávolítja a folyamot, függetlenül az aktivitástól, és ezen semmilyen keepalive nem változtat.

Kérdezze meg minden közvetítő tulajdonosát, melyiket valósítja meg. Egy tűzfal, egy NAT-eszköz, egy terheléselosztó és egy felhőátjáró mind tárolhat állapotot, és nem kell egyetérteniük. A legszűkebb szabja meg a határidőt, amelyet le kell győznie.

Ez a különbség azt is megmondja, mikor hagyja abba a hangolást. Ha a házirend abszolút korlát, a helyes megoldás egy rövidebb munkaegység, egy folytatható feladat vagy egy jóváhagyott kivétel, és az alábbi ellenőrzés csak azt erősíti meg, hogy a keepalive-ok semmit nem változtattak.

A socket-kapcsoló a Linux alapértékei mögött

A keepalive socketenként opcionális. A kernel alapértékei azt írják le, hogyan viselkednek a próbák, miután egy socket engedélyezte a mechanizmust, és nem engedélyezik azt a meglévő kapcsolatokhoz. Egy alkalmazás, amely soha nem kéri, nem kap próbákat, akármit mondanak a sysctl-értékek.

Ezért a számok puszta növelése semmit nem változtat egy adatbázis-kliensnél. A mechanizmust a klienskönyvtárnak vagy az alkalmazásnak kell engedélyeznie, és ahol a verem kapcsolatonkénti vezérlést kínál, egy szűkebb beállítás jobb, mint a teljes hosztra vonatkozó változtatás, amely nem kapcsolódó szolgáltatásokat érint.

Az első próbáig tartó intervallum sem lekérdezési időkorlát. Egy egészséges kapcsolat csendben marad a próbák között, és egy halott partner a próbaintervallum és -szám szerint ismerhető fel. Ezt a három értéket egyetlen időkorlátként olvasni olyan beállításokhoz vezet, amelyek vagy túl későn, vagy túl mohón észlelik a hibát. Az észlelést vezérlik, nem az alkalmazás türelmét.

Az EXPIRE_TIME adatbázis-beállítás, nem hálózati javítás

Az Oracle Net saját életképességi mechanizmust kínál, amely a folyamat tényleges profiljában van beállítva, nem pedig egy véletlenül hasonló nevű tetszőleges fájlban. Az értéket percekben adják meg.

SQLNET.EXPIRE_TIME = 5

Fő célja a halott kapcsolatok kiszolgáló oldali észlelése, és a továbbfejlesztett modellt támogató platformokon a TCP keepalive viselkedését is hangolja ezekhez a kapcsolatokhoz. Ez hasznos tulajdonság: az adatbázis-réteg próbákat szervezhet anélkül, hogy a kliensalkalmazás változtatását kérné.

A fenti szemléltető érték egy feltételezett határidőhöz igazított, összehangolt választás, nem ajánlás. A dokumentált általános útmutatás hosszabb intervallum, és a helyes szám a telepített megvalósítástól, az elfogadott próbaköltségtől és az útvonal tényleges frissítési szabályaitól függ. Tegye a beállítást abba a profilba, amelyet az illetékes folyamat olvas, és erősítse meg, hogy a folyamat átvette. Az Oracle dokumentálja a profil helyeit és az észlelési viselkedést a paraméterreferenciájában.

Tesztelje a csendes intervallumot, majd tervezze meg a helyreállítást

Engedjen át egy új, engedélyezett kapcsolatot egy olyan csendes időszakon, amely hosszabb, mint a legyőzni kívánt határidő, és figyelje az életképességi forgalmat és az alkalmazás eredményét. Ne rögzítsen szükségtelen hasznos adatot; az időzítők és a kapcsolat állapota megválaszolják a kérdést.

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

Ha a munkamenet mégis eltűnik, a határidő egy olyan eszközhöz tartozik, amelyet még nem kérdezett meg, vagy a házirend abszolút korlát. Ha túléli, jegyezze fel, melyik réteg változott, hogy a következő csendes művelet ne ismételje meg a vizsgálatot.

Végül döntse el, mi történik, amikor a kapcsolat ténylegesen megszakad, mert az életképességi ellenőrzések csökkentik a gyakoriságot, és soha nem szüntetik meg a lehetőséget. Állapítsa meg az adatbázis-művelet rögzített eredményét, mielőtt újra elküldi: a válasz elvesztése semmit nem bizonyít arról, hogy a munka jóváhagyást kapott-e. Mindenhez, aminek túl kell élnie egy laptop bezárását vagy egy alagút újraindítását, a kiszolgáló tulajdonában lévő, tartós eredményű feladat az erősebb terv, és a keepalive nem ütemező.