Oracle сесия прекъсната през VPN? Проверете keepalive слоевете

Двадесет и пет минути полезна работа с базата данни почти не произвеждат изход, а от всяко устройство по пътя този поток изглежда неактивен. Неактивното състояние е точно това, което се събира. Докладът след това винаги има същата форма: заявката работеше, после сесията изчезна и резултатът никога не пристигна.

Четири проверки решават дали тиха сесия оцелява и те вървят от сокета навън. Направете ги по ред, защото всяка предполага, че предишният слой си върши работата.

Кой поток утихва

Важна е връзката, която пренася трафика на базата данни, разпозната по собствените си адреси и портове. Нищо друго не я обновява. Пинг към шлюз, втора SQL връзка от същия хост и собственият пулс на тунела са отделни потоци с отделно състояние на всяко устройство, което ги следи.

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

Списъкът на сокетите показва таймери и състояние на опашката за живата връзка, което е по-информативно от тест за достъпност. Стойностите sysctl са подразбиращите се стойности на ядрото за поведението keepalive и следващият раздел обяснява защо може никога да не се приложат към вашата сесия. Подразбираща се стойност, която никога не се задейства, е неразличима от никаква подразбираща се стойност.

Запишете адресите, портовете и интерфейса, които връзката използва. Когато сесия умре, тези подробности ви позволяват да попитате правилното устройство какво е направило, вместо да питате дали мрежата е била достъпна.

Дали политиката за бездействие изтича или ограничава

Две политики дават същия симптом и изискват противоположни отговори. Времевото ограничение за бездействие премахва състояние, което квалифициран трафик е могъл да обнови, а keepalive може да попречи на това. Абсолютно ограничение на сесията премахва потока след фиксирана продължителност независимо от активността и никаква keepalive не променя това.

Питайте собственика на всеки посредник коя от двете прилага. Защитна стена, NAT устройство, балансьор на натоварване и облачен шлюз могат да държат състояние и не е нужно да са съгласни. Най-тясното определя крайния срок, който трябва да победите.

Това разграничение ви казва и кога да спрете да настройвате. Ако политиката е абсолютно ограничение, правилното решение е по-кратка работна единица, възобновяема задача или одобрено изключение и проверката по-долу само ще потвърди, че keepalive не промениха нищо.

Превключвателят на сокета зад подразбиращите се стойности на Linux

Keepalive е по избор за всеки сокет. Подразбиращите се стойности на ядрото описват как се държат сондите, след като сокет активира механизма, и не го активират за съществуващи връзки. Приложение, което никога не го поиска, не получава сонди, каквото и да казват стойностите sysctl.

Затова самото увеличаване на числата не променя нищо за клиент на базата данни. Механизмът трябва да бъде активиран от клиентската библиотека или приложението и където стекът предлага контроли за отделна връзка, ограничена настройка побеждава промяна за целия хост, която засяга несвързани услуги.

Интервалът до първата сонда също не е времево ограничение на заявка. Здравословна връзка остава тиха между сондите и мъртъв партньор се разпознава според интервала и броя на сондите. Четенето на тези три стойности като едно ограничение води до настройки, които откриват повредата или твърде късно, или твърде прибързано. Те управляват откриването, не търпението на приложението.

EXPIRE_TIME е настройка на базата данни, не мрежова поправка

Oracle Net предлага собствен механизъм за жизненост, конфигуриран в ефективния профил за процеса, а не в произволен файл, който случайно има подобно име. Стойността се изразява в минути.

SQLNET.EXPIRE_TIME = 5

Основната му цел е откриване на мъртви връзки от страна на сървъра и на платформи, които поддържат подобрения модел, той също настройва поведението на TCP keepalive за тези връзки. Това е полезно свойство: слоят на базата данни може да осигури сонди, без да иска от клиентското приложение да се променя.

Илюстративната стойност по-горе е координиран избор спрямо предполагаем срок, не препоръка. Документираната обща препоръка е по-дълъг интервал и правилното число зависи от инсталираната реализация, приетата цена на сондите и действителните правила за обновяване по пътя. Поставете настройката в профила, който съответният процес чете, и потвърдете, че процесът я е приел. Oracle документира местоположенията на профила и поведението при откриване в своя справочник на параметрите.

Тествайте тихия интервал и след това планирайте възстановяване

Пуснете нова разрешена връзка през тих период, по-дълъг от срока, който се опитвате да победите, и наблюдавайте трафика на жизненост и резултата на приложението. Не записвайте съдържание на полезния товар, което не ви е нужно; таймерите и състоянието на връзката отговарят на въпроса.

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

Ако сесията все още изчезва, срокът принадлежи на устройство, което още не сте попитали, или политиката е абсолютно ограничение. Ако оцелее, отбележете кой слой се е променил, за да не повтаря следващата тиха операция разследването.

Накрая решете какво се случва, когато връзката наистина падне, защото проверките за жизненост намаляват честотата и никога не премахват възможността. Установете записания резултат на операцията с базата данни, преди да я изпратите отново: загубата на отговора не доказва нищо за това дали работата е потвърдена. За всичко, което трябва да оцелее при затваряне на лаптоп или рестарт на тунел, работа, собственост на сървъра, с траен резултат е по-силният дизайн, а keepalive не е планировчик.