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"

त्या पत्त्याची तुम्ही कॉन्फिगर केलेल्या श्रोत्याशी तुलना करा. विसंगती म्हणजे दुसरा श्रोता किंवा अनपेक्षित ठिकाणी सोडवला जाणारे नाव, आणि पुढील रीबूट तुमच्या वतीने तुमची दुरुस्ती तपासण्यापूर्वी दोन्ही जाणून घेणे योग्य आहे. नंतर कोणताही वापरकर्ता साइन-इन नसताना होस्ट रीबूट करा आणि बंधन यशस्वी झाल्याची खात्री करा. तीच एक चाचणी दुरुस्त केलेला श्रोता आणि पुढील पॅचच्या रात्री अयशस्वी होणारा तात्पुरता उपाय यातील फरक आहे.