Sessione Oracle caduta via VPN? Controlla i livelli keepalive

Venticinque minuti di lavoro utile sul database non producono quasi alcun output, e da ogni dispositivo lungo il percorso quel flusso sembra inattivo. Lo stato inattivo è esattamente ciò che viene raccolto. Il resoconto successivo ha sempre la stessa forma: la query era in esecuzione, poi la sessione è sparita e il risultato non è mai arrivato.

Quattro controlli decidono se una sessione silenziosa sopravvive, e vanno dal socket verso l’esterno. Eseguili in ordine, perché ognuno dà per scontato che il livello precedente faccia il suo lavoro.

Quale flusso diventa silenzioso

La connessione che conta è quella che trasporta il traffico del database, identificata dai suoi stessi indirizzi e porte. Nient’altro la rinfresca. Un ping verso un gateway, una seconda connessione SQL dallo stesso host e il battito proprio del tunnel sono flussi separati con stato separato su ogni dispositivo che li segue.

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

L’elenco dei socket mostra timer e stato della coda per la connessione attiva, il che è più informativo di un test di raggiungibilità. I valori sysctl sono i predefiniti del kernel per il comportamento keepalive, e la sezione successiva spiega perché potrebbero non applicarsi mai alla tua sessione. Un valore predefinito che non scatta mai è indistinguibile dall’assenza di qualsiasi valore.

Annota gli indirizzi, le porte e l’interfaccia usati dalla connessione. Quando una sessione muore, sono quei dettagli a permetterti di chiedere al dispositivo giusto cosa ha fatto, invece di chiedere se la rete era attiva.

Se la policy di inattività scade o limita

Due policy producono lo stesso sintomo e richiedono risposte opposte. Un timeout di inattività rimuove stato che il traffico idoneo avrebbe potuto rinfrescare, e un keepalive può impedirlo. Un limite assoluto di sessione rimuove il flusso dopo una durata fissa indipendentemente dall’attività, e nessun keepalive lo cambia.

Chiedi al proprietario di ogni intermediario quale delle due implementa. Un firewall, un dispositivo NAT, un bilanciatore di carico e un gateway cloud possono tutti conservare stato, e non devono essere d’accordo. Il più stretto fissa la scadenza che devi battere.

Questa distinzione ti dice anche quando smettere di regolare. Se la policy è un limite assoluto, la soluzione corretta è un’unità di lavoro più breve, un job riprendibile o un’eccezione approvata, e il controllo qui sotto si limiterà a confermare che i keepalive non hanno cambiato nulla.

L’interruttore del socket dietro i predefiniti di Linux

Il keepalive è opzionale per socket. I predefiniti del kernel descrivono come si comportano le sonde una volta che un socket ha abilitato il meccanismo, e non lo abilitano per le connessioni esistenti. Un’applicazione che non lo chiede mai non riceve sonde, qualunque cosa dicano i valori sysctl.

Per questo alzare i numeri da solo non cambia nulla per un client di database. La libreria client o l’applicazione deve abilitare il meccanismo, e dove lo stack espone controlli per connessione, un’impostazione mirata batte una modifica a livello di host che tocca servizi non correlati.

L’intervallo fino alla prima sonda non è nemmeno un timeout di query. Una connessione sana resta silenziosa tra le sonde, e un peer morto viene riconosciuto in base all’intervallo e al numero di sonde. Leggere quei tre valori come un unico timeout è il modo in cui si arriva a impostazioni che rilevano il guasto troppo tardi o troppo in fretta. Controllano il rilevamento, non la pazienza dell’applicazione.

EXPIRE_TIME è un’impostazione del database, non una correzione di rete

Oracle Net offre un proprio meccanismo di vitalità, configurato nel profilo effettivo del processo e non in un file arbitrario che per caso ha un nome simile. Il valore è espresso in minuti.

SQLNET.EXPIRE_TIME = 5

Il suo scopo principale è il rilevamento lato server delle connessioni morte, e sulle piattaforme che supportano il modello avanzato regola anche il comportamento keepalive di TCP per quelle connessioni. È una proprietà utile: lo strato database può organizzare sonde senza chiedere all’applicazione client di cambiare.

Il valore illustrativo qui sopra è una scelta coordinata rispetto a una scadenza ipotizzata, non una raccomandazione. La guida generale documentata è un intervallo più lungo, e il numero giusto dipende dall’implementazione installata, dal costo delle sonde che accetti e dalle regole reali di rinnovo sul percorso. Metti l’impostazione nel profilo che il processo interessato legge, e conferma che il processo l’abbia raccolta. Oracle documenta le posizioni dei profili e il comportamento di rilevamento nella sua guida ai parametri.

Prova l’intervallo silenzioso, poi pianifica il recupero

Fai passare una nuova connessione consentita attraverso un periodo silenzioso più lungo della scadenza che stai cercando di battere, e osserva il traffico di vitalità e il risultato dell’applicazione. Non catturare contenuto del payload che non ti serve; timer e stato della connessione rispondono alla domanda.

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

Se la sessione sparisce ancora, la scadenza appartiene a un dispositivo che non hai ancora interrogato, oppure la policy è un limite assoluto. Se sopravvive, annota quale livello è cambiato, così la prossima operazione silenziosa non ripete l’indagine.

Infine, decidi cosa succede quando la connessione cade davvero, perché i controlli di vitalità riducono la frequenza e non eliminano mai la possibilità. Stabilisci l’esito registrato dell’operazione sul database prima di inviarla di nuovo: perdere la risposta non dimostra nulla sul fatto che il lavoro sia stato confermato. Per tutto ciò che deve sopravvivere alla chiusura di un portatile o al riavvio di un tunnel, un job di proprietà del server con un risultato durevole è il progetto più solido, e un keepalive non è uno scheduler.