SQL Server, துவக்கத்தில் இல்லாத VPN முகவரிக்கு இணைகிறது
தொடக்க பதிவிலிருந்து உண்மையான கேட்பான் வரை தோல்வியடைந்த SQL Server இணைப்பைப் பின்தொடர்ந்து, பின்னர் வாடிக்கையாளர்களுக்கு VPN குள முகவரிக்குப் பதிலாக நிலையான தனிப்பட்ட முகவரி வழங்குங்கள்.
சேவை இன்னும் இயங்கும்போது தோல்வியடைந்த இணைப்பு பற்றிய SQL Server பதிவு வரியைப் படியுங்கள், அப்போது நீங்கள் செயலிழப்பு அல்ல, துவக்க வரிசைச் சார்பைக் கண்டுபிடித்துள்ளீர்கள். அந்தக் கலவையே துப்பு: எந்த முகவரியில் கேட்க வேண்டும் என்று கூறப்பட்டதோ அது இயந்திரத்தில் இருப்பதற்கு முன்பே இயந்திரம் தொடங்கியது. உள்நுழைவுக்குப் பிறகு எழும் VPN அடாப்டர் கண்காணிப்பில்லாத தரவுத்தள சேவைக்கு மோசமான முன்நிபந்தனை, எனவே இயந்திரம் பார்க்கும் வரிசையில் தோல்வியைப் பின்தொடருங்கள்.
வாடிக்கையாளரிடமிருந்து அல்ல, தொடக்க பதிவிலிருந்து தொடங்குங்கள்
நிறுவனத்தின் பிழைப் பதிவைத் திறந்து கடைசி வரி மட்டுமல்ல, பிணைய துவக்கத்தைச் சுற்றியுள்ள பதிவுகளைப் படியுங்கள். எந்த முகவரிகளை முயன்றது, எந்த நெறிமுறைகளை இயக்கியது என்பதை இயந்திரம் தெரிவிக்கிறது, அந்தப் பதிவு எந்த வாடிக்கையாளரும் இணைவதற்கு முன்பானது. இப்போது ஹோஸ்ட்டில் இந்தக் கணத்தில் என்ன இருக்கிறது எனப் பாருங்கள். உள்ளமைக்கப்பட்ட முகவரியைக் கொண்ட இடைமுகம் பயனர் உள்நுழைந்து வாடிக்கையாளரைத் தொடங்கிய பிறகே தோன்றினால், துவக்கத்தில் முகவரி இல்லை, இணைப்புத் தோல்வி முழுமையாக விளக்கப்படுகிறது.
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40
நிறுவனத்தின் பாதையை உங்கள் நிறுவலுக்கு ஏற்ப மாற்றி, முடிவுகளுக்கு வருவதற்கு முன் இடைமுகப் பட்டியலைப் படியுங்கள். இருக்கும் ஆனால் தவறான அடாப்டருக்குச் சொந்தமான முகவரி, இன்னும் இல்லாத முகவரியிலிருந்து வேறுபட்ட பிரச்சினை.
இயந்திரம் உண்மையில் பின்பற்றும் இணைப்பு வரிசையில் செல்லுங்கள்
இயந்திரம் தன் கேட்பான் உள்ளமைவைப் படித்து, பின்னர் இயக்க முறைமையை இணையச் சொல்கிறது. அந்தக் கணத்தில் முகவரி உள்ளூர் இல்லையெனில் அந்த முகவரிக்கான இணைப்பு தோல்வியடைகிறது, மீதமுள்ள நிறுவனம் வழக்கமாகத் தொடரலாம். அதனால்தான் பிற நெறிமுறைகள் அல்லது பிற முகவரிகள் இன்னும் செயல்படலாம், அதனால்தான் „SQL Server செயலிழந்துள்ளது“ தவறான சுருக்கம். பதிவிலிருந்து சரியான முடிவுப் புள்ளியைச் சேமியுங்கள்: முகவரி, துறைமுகம் மற்றும் நெறிமுறை, ஏனெனில் சரிசெய்தல் மூன்றில் எது தவறு என்பதைப் பொறுத்தது.
அடாப்டர் தோன்றிய பிறகு சேவையை மீண்டும் தொடங்குவது பொதுவாக கேட்பானை வெற்றிபெறச் செய்யும், அதுவே பொறி. அது சார்பை நீக்குவதற்குப் பதிலாக நிரூபிக்கிறது, சுரங்கப்பாதை மீண்டும் இணையும் ஒவ்வொரு முறையும் இணைந்திருக்கும் ஒவ்வொரு பயனரையும் துண்டிக்கிறது.
இயந்திரம் படிப்பதைப் போலவே கேட்பானைப் படியுங்கள்
SQL Server Configuration Manager இல் நிறுவனத்தின் TCP/IP பண்புகளைத் திறந்து தனிப்பட்ட முகவரிகளைத் திருத்துவதற்கு முன் Listen All அமைப்பைக் கவனியுங்கள். Listen All Yes ஆக இருக்கும்போது ஒவ்வொரு முகவரியின் Enabled மதிப்புகள் புறக்கணிக்கப்படும், எனவே அவற்றைத் திருத்துவது கேட்பான் பயன்படுத்துவதை எதையும் மாற்றாது. வரிசையாக மூன்று விஷயங்களைப் பதிவு செய்யுங்கள்: நீங்கள் சேவை செய்ய விரும்பும் முகவரி, துறைமுகம், மற்றும் கேட்பான் அனைத்து முகவரிகளையும் அல்லது ஒன்றை மட்டும் உள்ளடக்க வேண்டுமா. பின்னர் ஆதரிக்கப்படும் மறுதொடக்க நடைமுறை மூலம் மாற்றத்தைப் பயன்படுத்தி, இயந்திரம் நீங்கள் கேட்டதை இணைத்ததை உறுதிப்படுத்த அடுத்த தொடக்க பதிவைப் படியுங்கள்.
ஒவ்வொரு முகவரியிலும் கேட்பது அணுகல் கட்டுப்பாடு அல்ல. உண்மையில் பரந்த கேட்பான் தேவைப்பட்டால், அணுகக்கூடிய ஒவ்வொரு இடைமுகத்திற்கும் அதன் சொந்த ஃபயர்வால் மற்றும் தரவுத்தள அனுமதி முடிவு தேவை, இணையத்தை நோக்கிய எந்த இடைமுகமும் உட்பட.
வாடிக்கையாளருக்கு நிலையான இலக்கைக் கொடுங்கள்
தரவுத்தள ஹோஸ்ட் குள முகவரியை அணிய வேண்டிய அவசியம் வாடிக்கையாளருக்கு இல்லை. வழியமைக்கப்பட்ட வடிவமைப்பில் சேவையகம் தன் நிலையான தனிப்பட்ட முகவரியில் கேட்கிறது, VPN நுழைவாயில் வாடிக்கையாளரின் போக்குவரத்தை அதற்கு அனுப்பி பதிலைத் திரும்பக் கொண்டுவருகிறது.
Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15
வாடிக்கையாளர் 10.80.0.15 ஐ அடைந்தால் பாதை நிரூபிக்கப்பட்டது, தரவுத்தளம் அந்த வாடிக்கையாளருக்கு அனுமதி வழங்கினால் போதும். இல்லையெனில், கேட்பானை மீண்டும் தொடுவதற்கு முன் வழியமைப்பு மற்றும் DNS ஐச் சரிசெய்யுங்கள், ஏனெனில் சேவையகத்தின் இணைப்புப் பிரச்சினை வாடிக்கையாளர் அதைக் கண்டுபிடிக்க முடியாததற்கான காரணமே அல்ல. சேவையகத்திற்கு போலிக் குள முகவரி சேர்ப்பது, அல்லது கேட்பானை மகிழ்விக்க இரண்டாவது இயல்புநிலை நுழைவாயில் தருவது, பழையதின் மேல் புதிய பிணையப் பிரச்சினையை உருவாக்குகிறது. சேவையகத்தின் முகவரியை நிலையாக வைத்து, சுரங்கப்பாதை வாடிக்கையாளர்களை அதற்கு அழைத்துச் செல்லட்டும்.
வாடிக்கையாளர் பயன்படுத்திய முடிவுப் புள்ளியைச் சரிபாருங்கள்
துறைமுகச் சோதனைக்குப் பதிலாக பயன்பாட்டு நிலைச் சரிபார்ப்புடன் முடிக்கவும். பயன்பாடு பயன்படுத்தும் கணக்குடன் வாடிக்கையாளரிலிருந்து இணைந்து, சேவையகப் பக்க இணைப்பு விவரங்களைப் படியுங்கள், அவை உங்கள் அமர்வு தரையிறங்கிய உள்ளூர் முகவரியைக் காட்டுகின்றன.
sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"
அந்த முகவரியை நீங்கள் உள்ளமைத்த கேட்பானுடன் ஒப்பிடுங்கள். பொருந்தாமை என்பது இரண்டாவது கேட்பான் அல்லது எதிர்பாராத இடத்தில் தீர்க்கப்படும் பெயர், அடுத்த மறுதொடக்கம் உங்கள் சார்பாக உங்கள் சரிசெய்தலைச் சோதிப்பதற்கு முன் இரண்டையும் தெரிந்துகொள்வது மதிப்புள்ளது. பின்னர் எந்தப் பயனரும் உள்நுழையாமல் ஹோஸ்ட்டை மறுதொடக்கம் செய்து இணைப்பு வெற்றிபெறுவதை உறுதிப்படுத்துங்கள். அந்த ஒரு சோதனையே பழுதுபார்க்கப்பட்ட கேட்பான் மற்றும் அடுத்த இணைப்பு இரவில் தோல்வியடையும் தற்காலிகத் தீர்வு ஆகியவற்றுக்கிடையேயான வேறுபாடு.