Сеанс Oracle оборвался через VPN? Проверьте уровни keepalive

Двадцать пять минут полезной работы с базой данных почти не дают вывода, и с точки зрения каждого устройства на пути этот поток выглядит неактивным. Именно неактивное состояние и собирается. Отчёт потом всегда имеет одну форму: запрос выполнялся, затем сеанс исчез, а результат так и не пришёл.

Четыре проверки решают, выживет ли тихий сеанс, и идут от сокета наружу. Делайте их по порядку, потому что каждая предполагает, что предыдущий уровень выполняет свою работу.

Какой поток затихает

Важно соединение, которое несёт трафик базы данных, определяемое собственными адресами и портами. Ничто другое его не обновляет. Ping до шлюза, второе 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 не планировщик.