Sesja Oracle zerwana przez VPN? Sprawdź warstwy keepalive

Dwadzieścia pięć minut pożytecznej pracy z bazą danych prawie nie daje wyjścia, a z każdego urządzenia na ścieżce ten przepływ wygląda na nieaktywny. Właśnie stan nieaktywny jest zbierany. Późniejszy raport zawsze ma ten sam kształt: zapytanie działało, potem sesja zniknęła, a wynik nigdy nie dotarł.

Cztery kontrole decydują, czy cicha sesja przetrwa, i biegną od gniazda na zewnątrz. Wykonuj je po kolei, bo każda zakłada, że poprzednia warstwa robi swoje.

Który przepływ cichnie

Ważne jest połączenie przenoszące ruch bazy danych, rozpoznawane po własnych adresach i portach. Nic innego go nie odświeża. Ping do bramy, drugie połączenie SQL z tego samego hosta i własny puls tunelu to osobne przepływy z osobnym stanem na każdym urządzeniu, które je śledzi.

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

Lista gniazd pokazuje timery i stan kolejki żywego połączenia, co mówi więcej niż test osiągalności. Wartości sysctl to domyślne wartości jądra dla zachowania keepalive, a następna sekcja wyjaśnia, dlaczego mogą nigdy nie dotyczyć twojej sesji. Wartość domyślna, która nigdy się nie uruchamia, jest nieodróżnialna od braku jakiejkolwiek wartości domyślnej.

Zapisz adresy, porty i interfejs, których używa połączenie. Gdy sesja umiera, właśnie te szczegóły pozwalają zapytać właściwe urządzenie, co zrobiło, zamiast pytać, czy sieć działała.

Czy zasada bezczynności wygasa, czy ogranicza

Dwie zasady dają ten sam objaw i wymagają przeciwnych reakcji. Limit bezczynności usuwa stan, który kwalifikowany ruch mógłby odświeżyć, a keepalive może temu zapobiec. Bezwzględny limit sesji usuwa przepływ po stałym czasie niezależnie od aktywności i żaden keepalive tego nie zmieni.

Zapytaj właściciela każdego pośrednika, którą z dwóch realizuje. Zapora, urządzenie NAT, równoważenie obciążenia i brama chmurowa mogą wszystkie przechowywać stan i nie muszą się zgadzać. Najwęższa wyznacza termin, który musisz pobić.

To rozróżnienie mówi też, kiedy przestać dostrajać. Jeśli zasada jest bezwzględnym limitem, właściwym rozwiązaniem jest krótsza jednostka pracy, zadanie wznawialne lub zatwierdzony wyjątek, a poniższa kontrola tylko potwierdzi, że keepalive nic nie zmieniły.

Przełącznik gniazda za domyślnymi wartościami Linuksa

Keepalive jest opcjonalny dla każdego gniazda. Domyślne wartości jądra opisują, jak zachowują się sondy, gdy gniazdo włączy mechanizm, i nie włączają go dla istniejących połączeń. Aplikacja, która nigdy o niego nie prosi, nie dostaje żadnych sond, cokolwiek mówią wartości sysctl.

Dlatego samo podniesienie liczb nic nie zmienia dla klienta bazy danych. Mechanizm musi włączyć biblioteka klienta lub aplikacja, a tam, gdzie stos daje kontrolę na poziomie połączenia, ograniczone ustawienie bije zmianę dla całego hosta, która dotyka niepowiązanych usług.

Odstęp do pierwszej sondy też nie jest limitem czasu zapytania. Zdrowe połączenie milczy między sondami, a martwy partner jest rozpoznawany według odstępu i liczby sond. Czytanie tych trzech wartości jako jednego limitu prowadzi do ustawień, które wykrywają awarię albo zbyt późno, albo zbyt gorliwie. Sterują wykrywaniem, a nie cierpliwością aplikacji.

EXPIRE_TIME to ustawienie bazy danych, a nie poprawka sieciowa

Oracle Net oferuje własny mechanizm żywotności, konfigurowany w efektywnym profilu procesu, a nie w dowolnym pliku, który przypadkiem ma podobną nazwę. Wartość wyraża się w minutach.

SQLNET.EXPIRE_TIME = 5

Jego głównym celem jest wykrywanie martwych połączeń po stronie serwera, a na platformach obsługujących ulepszony model dostraja też zachowanie TCP keepalive dla tych połączeń. To użyteczna właściwość: warstwa bazy danych może zorganizować sondy bez proszenia aplikacji klienta o zmiany.

Powyższa wartość ilustracyjna to skoordynowany wybór wobec zakładanego terminu, a nie zalecenie. Udokumentowane ogólne zalecenie to dłuższy odstęp, a właściwa liczba zależy od zainstalowanej implementacji, akceptowanego narzutu sond i rzeczywistych zasad odświeżania na ścieżce. Umieść ustawienie w profilu, który czyta odpowiedni proces, i potwierdź, że proces je przejął. Oracle dokumentuje lokalizacje profili i zachowanie wykrywania w swojej referencji parametrów.

Przetestuj cichy odstęp, potem zaplanuj odzyskiwanie

Przepuść nowe dozwolone połączenie przez cichy okres dłuższy niż termin, który próbujesz pobić, i obserwuj ruch żywotności oraz wynik aplikacji. Nie przechwytuj zawartości ładunku, której nie potrzebujesz; timery i stan połączenia odpowiadają na pytanie.

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

Jeśli sesja nadal znika, termin należy do urządzenia, o które jeszcze nie pytałeś, albo zasada jest bezwzględnym limitem. Jeśli przetrwa, zapisz, która warstwa się zmieniła, aby następna cicha operacja nie powtarzała dochodzenia.

Na koniec zdecyduj, co się dzieje, gdy połączenie naprawdę spada, bo kontrole żywotności zmniejszają częstotliwość i nigdy nie usuwają możliwości. Ustal zapisany wynik operacji na bazie danych, zanim wyślesz ją ponownie: utrata odpowiedzi niczego nie dowodzi co do tego, czy praca została potwierdzona. Dla wszystkiego, co musi przetrwać zamknięcie laptopa lub restart tunelu, zadanie należące do serwera z trwałym wynikiem jest mocniejszym projektem, a keepalive nie jest harmonogramem.