இல்லை, இணைப்புச் சரம் உங்கள் VPN சுரங்கப்பாதையைத் தொடங்க முடியாது
VPN இயங்குதளத்திற்கோ வாடிக்கையாளருக்கோ சொந்தமானது, ஒருபோதும் இயக்கிக்கு அல்ல. முதலில் சுரங்கப்பாதையை உயர்த்துங்கள், netonly மூலம் கள ஆவணங்களை அனுப்புங்கள், பின்னர் கர்சரின் போக்குவரத்தைச் சரிபாருங்கள்.
இணைப்புச் சரம், JDBC URL அல்லது tnsnames.ora பதிவு VPN-ஐத் தேர்ந்தெடுக்கும் இடத்தை உருவாக்குநர்கள் இன்னும் தேடுகிறார்கள். அத்தகைய இடம் இல்லை. மெய்நிகர் அடாப்டரைப் பதிவு செய்யும் இயங்குதளம் அல்லது விற்பனையாளர் வாடிக்கையாளரே சுரங்கப்பாதையை அமைக்கிறது, அதற்கு மேலுள்ள ஒவ்வொரு தரவுத்தள நூலகமும் அதனால் உருவாகும் சாக்கெட் அடுக்கைப் பயன்படுத்துகிறது. இணைப்புச் சரம் ஒரு ஹோஸ்ட், ஒரு போர்ட் மற்றும் ஒரு ஆவணத்தைப் பெயரிடுகிறது, அவ்வளவே முழுச் சொல்லகராதி.
கட்டுக்கதை: இணைப்புச் சரம் ஒரு சுரங்கப்பாதையைத் தேர்ந்தெடுக்க முடியும்
இயக்கி ஒரு ஹோஸ்ட் மற்றும் போர்ட்டுக்கு TCP சாக்கெட்டைத் திறக்கிறது. சுரங்கப்பாதையை உயர்த்த API இல்லை, சுரங்கப்பாதை சுயவிவரத்திற்கு புலம் இல்லை, VPN நுழைவாயிலில் அங்கீகரிக்க வழி இல்லை.
அதனால்தான் ஒரு வழி இருந்தால் கருவிகள் ஒரே மாதிரி நடந்துகொள்ளும். SSMS, DBeaver, Eclipse Data Tools மற்றும் சாதாரண sqlcmd அனைத்தும் சேவையகம் உள்ளூர் வலையமைப்பில் இருப்பது போலவே செயல்படுகின்றன, ஏனெனில் சாக்கெட்டின் பார்வையில் அது அங்கேயே உள்ளது. மெய்நிகர் அடாப்டர் தரவுத்தள துணை வலையமைப்பை அணுகக்கூடியதாக்கியது, அது எப்படி என்பதை இயக்கி ஒருபோதும் அறியாது.
இணைப்புச் சரம் அறுந்த சுரங்கப்பாதையை ஏன் சரிசெய்ய முடியாது என்பதையும் இது விளக்குகிறது. இணைப்பு இறந்ததும், இயக்கி நேரம் முடிந்தது அல்லது பொதுவான வலையமைப்புப் பிழை எனத் தெரிவிக்கிறது, அதை வினவல் சிக்கலாகக் கருதும் பயன்பாட்டுக் குறியீடு என்றென்றும் தவறான அடுக்கை மீண்டும் செய்கிறது.
இயக்கி இயங்குவதற்கு முன் சுரங்கப்பாதையை உயர்த்துங்கள்
வழங்குநர் அல்லது வலையமைப்புக் குழுவின் வழிமுறைகளைப் பின்பற்றி இயங்குதள மட்டத்தில் VPN-ஐ இணைக்கவும், அதன் பிறகே கருவியைத் திறக்கவும். நடைமுறையில் இதன் பொருள் இயக்கி ஹோஸ்ட் பெயரைத் தீர்க்கும் முன் தரவுத்தள துணை வலையமைப்பிற்கு வழி உள்ளது.
சுரங்கப்பாதை மேற்பார்வையை பயன்பாட்டிற்கு வெளியே வைத்திருங்கள். இணைப்பைத் தானே உயர்த்த முயற்சிக்கும் PHP அல்லது Java சேவை ஒரு வழங்குநரின் நடத்தையை வணிகக் குறியீட்டில் எழுதுகிறது, ஒவ்வொரு தோல்வி மாற்றமும் ஒரு பயன்பாட்டு வெளியீடாகிறது. சுரங்கப்பாதையை வைத்திருக்கும், கண்காணிக்கும், மீண்டும் இயக்கும் மேற்பார்வையாளர் வினவல் பாதையிலிருந்து தனி விஷயம்.
இயக்கியைக் குறை கூறும் முன் வழியைச் சரிபாருங்கள்: ஹோஸ்ட் தீர்க்கப்படவில்லை அல்லது ஷெல்லிலிருந்து போர்ட் பதிலளிக்கவில்லை என்றால், எந்த இணைப்புச் சரமும் அதை மாற்றாது.
கட்டுக்கதை: 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 க்கு வேலை செய்கிறது ஆனால் வேறு கணக்கின் கீழ் இயங்கும் சேவைக்கு எப்போதும் இல்லை என்று தெரிவிக்கப்படுகிறது, எனவே உள்நுழைவை மாற்றும் முன் செயல்முறை எந்த அடையாளத்தைப் பயன்படுத்துகிறது என்பதைச் சரிபாருங்கள்.
தாமதம் சேவையகப் பக்க கர்சரை நேரம் முடிந்ததாக மாற்றுகிறது
சேவையகப் பக்க கர்சர் தரவுத்தளத்தை முடிவை வைத்திருக்கவும் படிப்படியாகக் கொண்டுவரவும் கேட்கிறது, இது ஒரு பெரிய முடிவை பல சிறிய போக்குவரத்துகளாக மாற்றுகிறது. LAN இல் அது மலிவு. பத்துகள் மில்லிவினாடிகள் கூடுதல் தாமதமுள்ள சுரங்கப்பாதை வழியாக அதே வினவல் அதிக தரவை அனுப்பாமலேயே கட்டளை நேர முடிவை மீறலாம்.
வாடிக்கையாளர் பக்க கர்சருக்கு மாறுங்கள், அல்லது fetch size ஐ உயர்த்தி வரிசைகளை தொகுதியாக்குங்கள், போக்குவரத்துகளின் எண்ணிக்கை குறையும். தடையாக இருப்பது பரிமாற்றங்களின் எண்ணிக்கை, இணைப்பின் பெயரளவு வேகம் அல்ல, எனவே செயல்திறனை அளப்பது உங்களைத் தவறாக வழிநடத்தும், போக்குவரத்துகளை அளப்பது வழிநடத்தாது. உங்கள் பயனர்கள் உண்மையில் இழுக்கும் மிகப்பெரிய முடிவுத் தொகுப்புடன் சோதியுங்கள், உடனடியாகத் திரும்பும் ஒரு வரிசை வினவலுடன் அல்ல. நேர முடிவு நகர்ந்தாலும் மறையவில்லை என்றால், கட்டளை நேர முடிவையும் fetch size ஐயும் ஒன்றாக உயர்த்தி மீண்டும் அளவிடுங்கள்.
அதே கணிதம் பேசும் ORM களுக்கும் ஒவ்வொரு வரிசைக்கும் ஒரு கூற்றை வெளியிடும் எந்த வாடிக்கையாளருக்கும் பொருந்தும். வினவல் திட்டம் நல்லதாகவும் பரிமாற்றம் சிறியதாகவும் இருந்தால், தரவுத்தளத்தைச் சரிசெய்வதற்கு முன் வலையமைப்பு பரிமாற்றங்களை எண்ணுங்கள்.
போர்ட், நிகழ்வு மற்றும் உள்ளூர் வடிகட்டியைச் சரிபாருங்கள்
பெயரிடப்பட்ட நிகழ்வு மாறும் போர்ட்டில் கேட்கிறது, எனவே 1433 என்று கருதாமல் போர்ட்டை உறுதிப்படுத்துங்கள். இயல்புநிலை நிகழ்வில் மதிப்பை நிகழ்வின் SuperSocketNetLib விசையின் கீழ் உள்ள TcpPort பதிவு மதிப்பிலிருந்து படிக்கலாம். Oracle க்கு, tnsnames.ora இல் உள்ள ஹோஸ்ட் தீர்க்கப்படுகிறதா, முகவரி பதிலளிக்கிறதா, கேட்பவர் போர்ட் அனுமதிக்கப்படுகிறதா என்பதைச் சரிபாருங்கள்; 1521 ஒரு பொதுவான இயல்புநிலை, உத்தரவாதம் அல்ல.
பின்னர் சுரங்கப்பாதையின் சொந்த அணுகல் பட்டியலையும், இறுதியாக வாடிக்கையாளரும் சேவையகமும் ஒரே இயந்திரமாக இருந்தாலும் இணைப்பைத் தடுக்கும் உள்ளூர் வைரஸ் தடுப்பு அல்லது ஹோஸ்ட் ஃபயர்வாலையும் விலக்குங்கள். உள்ளமைப்பை மாற்றும் முன் தோல்வியடையும் நிலையைப் பதிவு செய்யுங்கள், ஏனெனில் பெயர் தீர்தல், TCP அணுகல் மற்றும் TLS அல்லது உள்நுழைவு ஒவ்வொன்றும் வெவ்வேறு செய்தியுடன் தோல்வியடைகின்றன.
நிலையை டிக்கெட்டில் எழுதுங்கள். இல்லையெனில் அடுத்த நபர் இதைத் தொடங்கிய அதே இணைப்புச் சரம் தேடலை மீண்டும் செய்வார்.