Oracle-sesio senfaliĝis tra VPN? Kontrolu la keepalive-tavolojn

Dudek kvin minutoj da utila datumbaza laboro preskaŭ nenion eligas, kaj de ĉiu aparato sur la vojo tiu fluo aspektas neaktiva. Neaktiva stato estas ĝuste tio, kio estas kolektata. La raporto poste ĉiam havas la saman formon: la peto funkciis, tiam la sesio malaperis, kaj la rezulto neniam alvenis.

Kvar kontroloj decidas ĉu silenta sesio supervivas, kaj ili iras de la soketo eksteren. Faru ilin en ordo, ĉar ĉiu supozas, ke la antaŭa tavolo faras sian taskon.

Kiu fluo silentas

La konekto grava estas tiu, kiu portas la datumbazan trafikon, identigita per siaj propraj adresoj kaj pordoj. Nenio alia refreŝigas ĝin. Ping al enirejo, dua SQL-konekto de la sama gastiganto kaj la propra korbato de la tunelo estas apartaj fluoj kun aparta stato sur ĉiu aparato, kiu ilin sekvas.

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

La soketlisto montras tempigilojn kaj atendovican staton por la viva konekto, kio informas pli ol atingebleca testado. La sysctl-valoroj estas la kernodefaultoj por keepalive-konduto, kaj la sekva sekcio klarigas, kial ili eble neniam aplikiĝas al via sesio. Defaŭlto, kiu neniam ekfunkcias, nedistingeblas de tute nenia defaŭlto.

Notu la adresojn, la pordojn kaj la interfacon, kiujn la konekto uzas. Kiam sesio mortas, ĝuste tiuj detaloj ebligas al vi demandi la ĝustan aparaton, kion ĝi faris, anstataŭ demandi, ĉu la reto estis funkcianta.

Ĉu la senaktiveca politiko eksvalidiĝas aŭ limigas

Du politikoj produktas la saman simptomon kaj postulas kontraŭajn respondojn. Senaktiveca tempolimo forigas staton, kiun kvalifika trafiko povus refreŝigi, kaj keepalive povas malhelpi tion. Absoluta sesilimo forigas la fluon post fiksa daŭro sendepende de aktiveco, kaj neniu keepalive tion ŝanĝas.

Demandu la posedanton de ĉiu peranto, kiun el la du ĝi realigas. Fajroŝirmilo, NAT-aparato, ŝarĝobalancilo kaj nuba enirejo ĉiuj povas teni staton, kaj ili ne devas konsenti. La plej mallarĝa starigas la limdaton, kiun vi devas venki.

Tiu distingo ankaŭ diras al vi, kiam ĉesi agordi. Se la politiko estas absoluta limo, la ĝusta solvo estas pli mallonga laborelemento, rekomencigebla tasko aŭ aprobita escepto, kaj la kontrolo sube nur konfirmos, ke keepalive faris neniun diferencon.

La soketŝaltilo malantaŭ la Linux-defaŭltoj

Keepalive estas laŭelekta por ĉiu soketo. La kernodefaultoj priskribas, kiel sondoj kondutas post kiam soketo jam ŝaltis la mekanismon, kaj ili ne ŝaltas ĝin por ekzistantaj konektoj. Aplikaĵo, kiu neniam petas ĝin, ricevas neniujn sondojn, kion ajn diras la sysctl-valoroj.

Tial plialtigi la nombrojn sole ŝanĝas nenion por datumbaza kliento. La klientbiblioteko aŭ la aplikaĵo devas ŝalti la mekanismon, kaj kie la stako ofertas regilojn por ĉiu konekto, limigita agordo superas ŝanĝon por la tuta gastiganto, kiu efikas al nerilataj servoj.

La intervalo ĝis la unua sondo ankaŭ ne estas petotempolimo. Sana konekto restas silenta inter sondoj, kaj morta samtavolano estas rekonebla laŭ la sonda intervalo kaj nombro. Legi tiujn tri valorojn kiel unu tempolimon estas kiel homoj alvenas al agordoj, kiuj trovas la paneon aŭ multe tro malfrue aŭ multe tro avide. Ili regas la trovadon, ne la paciencon de la aplikaĵo.

EXPIRE_TIME estas datumbaza agordo, ne retriparo

Oracle Net ofertas sian propran vivecmeĥanismon, agorditan en la efika profilo por la procezo prefere ol en arbitra dosiero, kiu hazarde havas similan nomon. La valoro esprimiĝas en minutoj.

SQLNET.EXPIRE_TIME = 5

Ĝia ĉefa celo estas servoflanka trovado de mortaj konektoj, kaj sur platformoj subtenantaj la plibonigitan modelon ĝi ankaŭ agordas la TCP-keepalive-konduton por tiuj konektoj. Tio estas utila eco: la datumbaza tavolo povas aranĝi sondojn sen peti la klientan aplikaĵon ŝanĝiĝi.

La ilustra valoro supre estas kunordigita elekto kontraŭ supozita limdato, ne rekomendo. La dokumentita ĝenerala gvidado estas pli longa intervalo, kaj la ĝusta nombro dependas de la instalita realigo, de la sonda superpago, kiun vi akceptas, kaj de la realaj refreŝigaj reguloj sur la vojo. Metu la agordon en la profilon, kiun legas la koncerna procezo, kaj konfirmu, ke la procezo prenis ĝin. Oracle dokumentas la profilajn lokojn kaj la trovan konduton en sia parametra referenco.

Testu la silentan intervalon, poste planu la reakiron

Lasu novan permesitan konekton trapasi silentan periodon pli longan ol la limdato, kiun vi provas venki, kaj observu la vivecan trafikon kaj la rezulton de la aplikaĵo. Ne kaptu utilŝarĝan enhavon, kiun vi ne bezonas; tempigiloj kaj konekta stato respondas la demandon.

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

Se la sesio ankoraŭ malaperas, la limdato apartenas al aparato, kiun vi ankoraŭ ne demandis, aŭ la politiko estas absoluta limo. Se ĝi supervivas, notu, kiu tavolo ŝanĝiĝis, por ke la sekva silenta operacio ne ripetu la enketon.

Fine, decidu, kio okazas, kiam la konekto vere falas, ĉar vivecaj kontroloj malpliigas la oftecon kaj neniam forigas la eblecon. Starigu la registritan rezulton de la datumbaza operacio antaŭ ol resendi ĝin: perdi la respondon pruvas nenion pri tio, ĉu la laboro estis konfirmita. Por ĉio, kio devas supervivi fermon de tekkomputilo aŭ restarigon de tunelo, servoposedata tasko kun daŭra rezulto estas la pli forta dezajno, kaj keepalive ne estas planilo.