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"

उस पते की तुलना अपने कॉन्फ़िगर किए गए श्रोता से करें। बेमेल का अर्थ है दूसरा श्रोता या कहीं अप्रत्याशित रूप से हल होने वाला नाम, और अगले रीबूट के आपके सुधार को आपकी ओर से परखने से पहले दोनों जानना ज़रूरी है। फिर किसी उपयोगकर्ता के साइन-इन किए बिना होस्ट रीबूट करें और पुष्टि करें कि बंधन सफल है। वही एक परीक्षण मरम्मत किए गए श्रोता और अगली पैच रात में विफल होने वाले वैकल्पिक उपाय के बीच का अंतर है।