Nei, tengingarstrengur getur ekki ræst VPN-göngin þín

Forritarar leita enn að staðnum þar sem tengingarstrengur, JDBC-slóð eða færsla í tnsnames.ora velur VPN. Slíkur staður er ekki til. Göngin eru sett upp af stýrikerfinu eða biðlara frá birgi sem skráir sýndarþóka, og hvert gagnagrunnsbókasafn ofan á því notar sokkalagið sem af því verður. Tengingarstrengur nefnir hýsil, gátt og skírteini, og það er allt orðaforðinn.

Goðsögn: tengingarstrengurinn getur valið göng

Rekillinn opnar TCP-sokka á hýsil og gátt. Hann hefur ekkert API til að reisa göng, ekkert svæði fyrir gangasnið og enga leið til að sannvotta sig við VPN-gátt.

Þess vegna hegða tólin sér eins þegar leið er til. SSMS, DBeaver, Eclipse Data Tools og venjulegt sqlcmd haga sér eins og þjónninn sé á staðarnetinu, því frá sjónarhóli sokkans er hann það. Sýndarþóknin gerði undirnet gagnagrunnsins aðgengilegt, og rekillinn veit aldrei hvernig.

Það útskýrir líka hvers vegna tengingarstrengur getur ekki lagfært göng sem hafa dottið. Þegar tengingin deyr tilkynnir rekillinn tímanotkun eða almenna netvillu, og forritakóði sem lítur á það sem fyrirspurnarvandamál endurtekur ranga lagið að eilífu.

Reistu göngin áður en rekillinn keyrir

Tengdu VPN á stigi stýrikerfis, samkvæmt leiðbeiningum þjónustuaðilans eða netteymisins, og opnaðu tólið fyrst eftir það. Í reynd þýðir það að leið að undirneti gagnagrunnsins er til áður en rekillinn leysir hýsilnafnið.

Haltu eftirliti með göngunum utan forritsins. PHP- eða Java-þjónusta sem reynir sjálf að reisa tenginguna kóðar hegðun eins þjónustuaðila inn í viðskiptakóða, og hvert tilfærsluferli verður forritautgáfa. Eftirlitsaðili sem á göngin, fylgist með þeim og endurræsir þau er aðskilið mál frá fyrirspurnarleiðinni.

Athugaðu leiðina áður en þú kennir rekilnum um: ef hýsillinn leysist ekki eða gáttin svarar ekki úr skelinni, mun enginn tengingarstrengur breyta því.

Goðsögn: bilun í Windows-sannvottun þýðir að leiðin sé brotin

Windows-sannvottun gegnum VPN mistekst oft með villu sem lítur út eins og netbilun, en leiðin er í lagi. Þegar reikningurinn tilheyrir öðru léni og fartölvan getur ekki gengið í það, ræstu biðlarann með skýrum skírteinum í stað auðkenningar skjáborðstímans.

runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

/netonly-rofin heldur þessum skírteinum eingöngu fyrir fjarsannvottun. Staðfestu hvað þjónninn fékk í raun með SELECT SUSER_SNAME() í stað þess að treysta tengiglugganum. Greint er frá því að geymsla skírteinis fyrir vistfang þjónsins í Windows Credential Manager virki fyrir SSMS en ekki alltaf fyrir þjónustu sem keyrir undir öðrum reikningi, svo athugaðu hvaða auðkenni ferlið notar áður en þú breytir innskráningunni.

Biðtími breytir þjónahliðarbendli í tímanotkun

Þjónahliðarbendill biður gagnagrunninn að halda niðurstöðunni og sækja hana smátt og smátt, sem breytir einni stórri niðurstöðu í margar litlar ferðir fram og til baka. Á staðarneti er það ódýrt. Gegnum göng sem bæta tugum millisekúndna af biðtíma getur sama fyrirspurn farið yfir tímanotkun skipunarinnar án þess að flytja nánast nein gögn.

Skiptu yfir í biðlarahliðarbendil, eða hækkaðu sækjustærðina og flokkaðu raðirnar, og fjöldi ferða fram og til baka lækkar. Þrengslin eru fjöldi skipta, ekki nafnlegur hraði tengingarinnar, svo mæling á afköstum villir þig en mæling á ferðum fram og til baka gerir það ekki. Prófaðu með stærsta niðurstöðusafninu sem notendur þínir sækja í raun, ekki með fyrirspurn um eina röð sem snýr strax aftur. Ef tímanotkunin færist til en hverfur ekki skaltu hækka tímanotkun skipunarinnar og sækjustærðina saman og mæla aftur.

Sama reikningur gildir um málgaðar ORM og hvern þann biðlara sem sendir eina setningu fyrir hverja röð. Ef fyrirspurnaráætlunin er góð og flutningurinn lítill skaltu telja netskiptin áður en þú stillir gagnagrunninn.

Athugaðu gáttina, tilvikið og staðbundna síuna

Nefnt tilvik hlustar á kvika gátt, svo staðfestu gáttina í stað þess að gera ráð fyrir 1433. Á sjálfgefnu tilviki er hægt að lesa gildið úr TcpPort skráningargildinu undir SuperSocketNetLib-lykli tilviksins. Fyrir Oracle skaltu staðfesta að hýsillinn í tnsnames.ora leysist, að vistfangið svari og að gátt hlustandans sé leyfð; 1521 er algengt sjálfgefið gildi, ekki trygging.

Útilokaðu þá aðgangslista ganganna sjálfra og loks staðbundið vírusvarnarforrit eða hýsilinnra eldvegg sem lokar tengingunni jafnvel þótt biðlari og þjónn séu sama vélin. Skráðu það stig sem mistekst áður en þú breytir stillingum, því nafnleysing, TCP-aðgengi og TLS eða innskráning mistekst hvert með annarri skilaboðum.

Skrifaðu stigið í miðann. Annars endurtekur næsta manneskja sömu leit að tengingarstrengnum sem byrjaði allt þetta.