Ոչ, միացման տողը չի կարող գործարկել ձեր VPN թունելը

Ծրագրավորողները դեռ փնտրում են այն տեղը, որտեղ միացման տողը, JDBC URL-ը կամ tnsnames.ora-ի գրառումը ընտրում է VPN-ը։ Այդպիսի տեղ չկա։ Թունելը ստեղծում է օպերացիոն համակարգը կամ մատակարարի հաճախորդը, որը գրանցում է վիրտուալ ադապտեր, և դրա վերևի յուրաքանչյուր տվյալների բազայի գրադարան օգտագործում է այդ արդյունքում ստացված սոկետի շերտը։ Միացման տողը նշում է հոսթ, պորտ և հավատարմագիր, և դա է ամբողջ բառապաշարը։

Առասպել. միացման տողը կարող է ընտրել թունել

Դրայվերը TCP սոկետ է բացում դեպի հոսթ և պորտ։ Այն չունի API թունել բարձրացնելու համար, չունի դաշտ թունելի պրոֆիլի համար և չունի VPN դարպասին նույնականացվելու միջոց։

Այդ է պատճառը, որ գործիքները նույն կերպ են վարվում, երբ երթուղի գոյություն ունի։ SSMS-ը, DBeaver-ը, Eclipse Data Tools-ը և սովորական sqlcmd-ը գործում են այնպես, ասես սերվերը տեղական ցանցում է, որովհետև սոկետի տեսանկյունից այդպես է։ Վիրտուալ ադապտերը տվյալների բազայի ենթացանցը հասանելի դարձրեց, և դրայվերը երբեք չգիտի ինչպես։

Սա նաև բացատրում է, թե ինչու միացման տողը չի կարող վերանորոգել կտրված թունելը։ Երբ կապը մահանում է, դրայվերը հաղորդում է ժամանակի սպառման կամ ընդհանուր ցանցային սխալի մասին, և հավելվածի կոդը, որը դա համարում է հարցման խնդիր, ընդմիշտ կրկնում է սխալ շերտը։

Բարձրացրեք թունելը մինչև դրայվերի աշխատելը

Միացեք VPN-ին օպերացիոն համակարգի մակարդակով՝ հետևելով մատակարարի կամ ցանցային թիմի ցուցումներին, և միայն դրանից հետո բացեք գործիքը։ Գործնականում դա նշանակում է, որ դեպի տվյալների բազայի ենթացանց երթուղի գոյություն ունի նախքան դրայվերը կլուծի հոսթի անունը։

Թունելի հսկողությունը պահեք հավելվածից դուրս. PHP կամ Java ծառայությունը, որը փորձում է ինքը բարձրացնել կապը, մեկ մատակարարի վարքը կոդավորում է բիզնես կոդի մեջ, և յուրաքանչյուր ձախողման անցում դառնում է հավելվածի թողարկում։ Վերահսկիչը, որը տիրապետում է թունելին, հետևում է նրան և վերագործարկում, առանձին հարց է հարցման ուղուց։

Ստուգեք երթուղին նախքան դրայվերին մեղադրելը: եթե հոսթը չի լուծվում կամ պորտը չի պատասխանում shell-ից, ոչ մի միացման տող դա չի փոխի։

Առասպել. Windows-ի նույնականացման ձախողումը նշանակում է, որ երթուղին կոտրված է

VPN-ի միջոցով Windows-ի նույնականացումը հաճախ ձախողվում է ցանցային խափանում հիշեցնող սխալով, մինչդեռ երթուղին կարգին է։ Երբ հաշիվը պատկանում է այլ տիրույթի, և նոթբուքը չի կարող միանալ դրան, գործարկեք հաճախորդը բացահայտ հավատարմագրերով՝ սեղանադիր նստաշրջանի ինքնության փոխարեն։

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

/netonly անջատիչը պահում է այդ հավատարմագրերը միայն հեռավոր նույնականացման համար։ Հաստատեք, թե ինչ ստացավ սերվերը իրականում, SELECT SUSER_SNAME()-ով՝ միացման երկխոսությանը վստահելու փոխարեն։ Հաղորդվում է, որ սերվերի հասցեի հավատարմագիրը Windows Credential Manager-ում պահելը աշխատում է SSMS-ի համար, բայց ոչ միշտ՝ այլ հաշվի տակ աշխատող ծառայության համար, ուստի նախքան մուտքը փոխելը ստուգեք, թե որ ինքնությունն է օգտագործում գործընթացը։

Ուշացումը սերվերի կողմի կուրսորը դարձնում է ժամանակի սպառում

Սերվերի կողմի կուրսորը խնդրում է տվյալների բազային պահել արդյունքը և այն աստիճանաբար բերել, ինչը մեկ մեծ արդյունքը դարձնում է բազմաթիվ փոքր շրջապտույտներ։ Տեղական ցանցում դա էժան է։ Տասնյակ միլիվայրկյան լրացուցիչ ուշացում ունեցող թունելով նույն հարցումը կարող է գերազանցել հրամանի ժամանակի սպառումը՝ գրեթե տվյալներ չփոխանցելով։

Անցեք հաճախորդի կողմի կուրսորի, կամ մեծացրեք բերման չափը և խմբավորեք տողերը, և շրջապտույտների քանակը կնվազի։ Խոչընդոտը փոխանակումների քանակն է, ոչ թե կապի անվանական արագությունը, ուստի թողունակության չափումը ձեզ կմոլորեցնի, իսկ շրջապտույտների չափումը՝ ոչ։ Փորձարկեք ամենամեծ արդյունքի բազմությամբ, որը ձեր օգտատերերը իսկապես քաշում են, ոչ թե մեկ տողով հարցումով, որը վերադառնում է ակնթարթորեն։ Եթե ժամանակի սպառումը տեղափոխվում է, բայց չի անհետանում, միասին մեծացրեք հրամանի ժամանակի սպառումը և բերման չափը և կրկին չափեք։

Նույն թվաբանությունը վերաբերում է շատախոս ORM-ներին և ցանկացած հաճախորդի, որը տողի համար մեկ հայտարարություն է թողարկում։ Եթե հարցման պլանը լավ է, իսկ փոխանցումը՝ փոքր, հաշվեք ցանցային փոխանակումները նախքան տվյալների բազան կարգավորելը։

Ստուգեք պորտը, օրինակը և տեղական զտիչը

Անվանված օրինակը լսում է դինամիկ պորտի վրա, ուստի հաստատեք պորտը՝ 1433 ենթադրելու փոխարեն։ Լռելյայն օրինակի վրա արժեքը կարելի է կարդալ TcpPort գրանցամատյանի արժեքից՝ օրինակի SuperSocketNetLib բանալու տակ։ Oracle-ի համար ստուգեք, որ tnsnames.ora-ի հոսթը լուծվում է, հասցեն պատասխանում է, և լսողի պորտը թույլատրված է. 1521-ը սովորական լռելյայն է, ոչ թե երաշխիք։

Այնուհետև բացառեք հենց թունելի մուտքի ցանկը և, վերջապես, տեղական հակավիրուս կամ հոսթի հրապատ, որը արգելափակում է կապը նույնիսկ երբ հաճախորդն ու սերվերը նույն մեքենան են։ Արձանագրեք ձախողվող փուլը նախքան կարգավորումը փոխելը, քանի որ անվան լուծումը, TCP հասանելիությունը և TLS-ը կամ մուտքը յուրաքանչյուրը տարբեր հաղորդագրությամբ է ձախողվում։

Գրեք փուլը տոմսի մեջ։ Հակառակ դեպքում հաջորդ մարդը կկրկնի նույն միացման տողի որոնումը, որով ամեն ինչ սկսվեց։