Sessão do Oracle caiu por causa da VPN? Verifique as camadas de keepalive

Vinte e cinco minutos de trabalho útil no banco de dados quase não geram saída, e de cada dispositivo no caminho esse fluxo parece inativo. Estado inativo é exatamente o que é recolhido. O relatório depois tem sempre a mesma forma: a consulta estava em execução, então a sessão sumiu, e o resultado nunca chegou.

Quatro verificações decidem se uma sessão silenciosa sobrevive, e elas vão do socket para fora. Faça-as em ordem, porque cada uma presume que a camada anterior está fazendo o seu trabalho.

Qual fluxo fica em silêncio

A conexão que importa é a que carrega o tráfego do banco de dados, identificada pelos seus próprios endereços e portas. Nada mais a renova. Um ping para um gateway, uma segunda conexão SQL do mesmo host e o batimento próprio do túnel são fluxos separados com estado separado em cada dispositivo que os acompanha.

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

A listagem de sockets mostra temporizadores e estado da fila da conexão viva, o que informa mais do que um teste de alcançabilidade. Os valores de sysctl são os padrões do kernel para o comportamento de keepalive, e a seção seguinte explica por que eles talvez nunca se apliquem à sua sessão. Um padrão que nunca dispara é indistinguível de padrão nenhum.

Anote os endereços, as portas e a interface que a conexão usa. Quando uma sessão morre, são esses detalhes que permitem perguntar ao dispositivo certo o que ele fez, em vez de perguntar se a rede estava no ar.

Se a política de inatividade expira ou limita

Duas políticas produzem o mesmo sintoma e pedem respostas opostas. Um tempo limite de inatividade remove estado que o tráfego qualificado poderia ter renovado, e um keepalive pode evitá-lo. Um limite absoluto de sessão remove o fluxo após uma duração fixa, independentemente da atividade, e nenhum keepalive muda isso.

Pergunte ao responsável de cada intermediário qual das duas ele implementa. Um firewall, um dispositivo NAT, um balanceador de carga e um gateway de nuvem podem todos guardar estado, e não precisam concordar. O mais estreito define o prazo que você tem de vencer.

Essa distinção também diz quando parar de ajustar. Se a política é um limite absoluto, a correção certa é uma unidade de trabalho mais curta, um trabalho retomável ou uma exceção aprovada, e a verificação abaixo vai apenas confirmar que os keepalives não fizeram diferença.

O comutador do socket por trás dos padrões do Linux

O keepalive é opcional por socket. Os padrões do kernel descrevem como as sondas se comportam depois que um socket habilita o mecanismo, e não o habilitam para conexões existentes. Uma aplicação que nunca pede isso não recebe sondas, digam o que disserem os valores de sysctl.

É por isso que aumentar os números sozinho não muda nada para um cliente de banco de dados. A biblioteca cliente ou a aplicação precisa habilitar o mecanismo, e onde a pilha expõe controles por conexão, um ajuste delimitado supera uma mudança no host inteiro que afeta serviços não relacionados.

O intervalo até a primeira sonda também não é um tempo limite de consulta. Uma conexão saudável fica em silêncio entre as sondas, e um par morto é reconhecido conforme o intervalo e a contagem de sondas. Ler esses três valores como um único tempo limite é como as pessoas chegam a configurações que detectam a falha tarde demais ou cedo demais. Eles controlam a detecção, não a paciência da aplicação.

EXPIRE_TIME é uma configuração de banco de dados, não uma correção de rede

O Oracle Net oferece o seu próprio mecanismo de vitalidade, configurado no perfil efetivo do processo e não num arquivo arbitrário que por acaso tem um nome parecido. O valor é expresso em minutos.

SQLNET.EXPIRE_TIME = 5

O seu objetivo principal é a detecção no servidor de conexões mortas, e nas plataformas que suportam o modelo aprimorado ele também ajusta o comportamento de keepalive do TCP para essas conexões. Isso é uma propriedade útil: significa que a camada de banco de dados pode providenciar sondas sem pedir à aplicação cliente que mude.

O valor ilustrativo acima é uma escolha coordenada contra um prazo presumido, não uma recomendação. A orientação geral documentada é um intervalo mais longo, e o número certo depende da implementação instalada, do custo de sondas que você aceita e das regras reais de renovação no caminho. Coloque a configuração no perfil que o processo relevante lê, e confirme que o processo a apanhou. A Oracle documenta as localizações do perfil e o comportamento de detecção na sua referência de parâmetros.

Teste o intervalo silencioso e depois planeje a recuperação

Faça passar uma conexão nova e permitida por um período silencioso mais longo do que o prazo que você está tentando vencer, e observe o tráfego de vitalidade e o resultado da aplicação. Não capture conteúdo de carga de que não precise; temporizadores e estado da conexão respondem à pergunta.

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

Se a sessão ainda desaparecer, o prazo pertence a um dispositivo que você ainda não questionou, ou a política é um limite absoluto. Se ela sobreviver, registre qual camada mudou para que a próxima operação silenciosa não repita a investigação.

Por fim, decida o que acontece quando a conexão cai de fato, porque as verificações de vitalidade reduzem a frequência e nunca eliminam a possibilidade. Estabeleça o resultado registrado da operação de banco de dados antes de reenviá-la: perder a resposta não prova nada sobre se o trabalho foi confirmado. Para tudo o que tiver de sobreviver ao fechamento de um laptop ou à reinicialização de um túnel, um trabalho pertencente ao servidor com um resultado durável é o projeto mais forte, e um keepalive não é um agendador.