SQL सर्वर 2017 क्रैश हो जाता है जब फ़ाइलपैड गलत होता है

मैं अपने डेटाबेस को पुनर्स्थापित करने की कोशिश कर रहा था और SQL सर्वर क्रैश हो रहा था। मुझे SSMS में एक संदेश मिलेगा जिसमें कहा गया था कि नेटवर्क ट्रांसपोर्ट एरर था (कनेक्शन क्रैश हो गया था)। मैंने लॉग की जाँच की और पाया कि SQL सर्वर अप्रत्याशित रूप से बंद होने से ज्यादा कुछ नहीं है। फिर मुझे सेवा को फिर से शुरू करना होगा।

मैंने उस स्क्रिप्ट को समस्या को संकुचित कर दिया जिसे GUI चलाने का प्रयास कर रहा था। समस्या तब है जब यह एक पूंछ लॉग बैकअप लेने के लिए जाता है, बैकअप फ़ाइलों के लिए पथ गलत है। यह होना चाहिएD:\mapbenefits\...

BACKUP LOG [mapbenefits]
TO  DISK = N'D:mapbenefits_LogBackup_2019-02-21_13-58-24.bak'
WITH NOFORMAT, NOINIT,  NAME = N'mapbenefits_LogBackup_2019-02-21_13-58-24',
    NOSKIP, NOREWIND, NOUNLOAD,  NORECOVERY ,  STATS = 5

मेरे दो सवाल हैं।

मैं इस रास्ते को कैसे ठीक करूँ? मैंने सर्वर सेटिंग्स में जाने की कोशिश की और बैकअप पथ D:बिना किसी स्लैश के है। अगर मैं स्लैश जोड़ दूं तो गुई इसे हटा देती है। यह SSMS v17.9.1 है। मैं चुन सकता हूं D:\mapbenefits\और वह काम करता है लेकिन मैं चाहता हूंD:\DATABASE\...
क्या यह एक बग है? क्या SQL सर्वर क्रैश हो जाना चाहिए क्योंकि एक रास्ता गलत तरीके से टाइप किया गया है? एक बार जब मैंने फ़ाइल पथ को ठीक कर लिया तो इसमें कोई परेशानी नहीं है। मैं कभी भी फ़ाइलपथ को मैक्ड करके पुन: पेश कर सकता हूं।

यदि मैं CU13 प्राप्त करने वाले संस्करण की जांच करने के लिए एक क्वेरी चलाता हूं, लेकिन अगर मैं सेटिंग्स में जाता हूं तो मुझे संस्करण 14.0.1000.169 दिखाई देता है।

ऐसा लगता है कि यह एक बग है और प्रतिलिपि प्रस्तुत करने योग्य है, इसलिए मैंने इसे यहां पोस्ट किया: https://feedback.azure.com/forums/908035-sql-server/suggestions/36920542-incorrect-fitpath-with-backup-log-command-command का कारण बनता है

sql-server backup sql-server-2017

— पोरौटी
स्रोत

मैं इसे पुन: पेश करने में सक्षम था।

२०१६ को, अगर मैं उस तरह से एक अमान्य रास्ता डालता हूँ, तो मुझे यह संदेश मिलता है:

बैकअप डिवाइस 'D: mapbenefits_LogBackup_2019-02-21_13-58-24.bak' को नहीं खोल सकता। ऑपरेटिंग सिस्टम त्रुटि 3 (सिस्टम निर्दिष्ट पथ नहीं ढूँढ सकता।)

2017 CU 13 (14.0.3048.4) पर, यह सेवा दुर्घटनाग्रस्त होने का परिणाम है। आपने पहले ही उल्लेख किया है कि नवीनतम हॉटफ़िक्स (14.0.3049.1) में, सेवा क्रैश नहीं होती है, लेकिन सत्र मारा जाता है।

मैंने उसी सटीक व्यवहार की पुष्टि की है जो समान RESTORE DATABASEरूप से लागू होता है - "D: Backups" (एक गुम बैकस्लैश के साथ) या "D :: \ Backups" (अतिरिक्त कॉलोन) जैसे पथ को पारित करने से SQL सर्वर आवृत्ति क्रैश हो जाती है (धन्यवाद माइकल के कैम्पबेल इसे लाने के लिए)।

यदि मैं एक "वैध" पथ रखता हूं जो अस्तित्व में नहीं है, तो मुझे 2017 में सही व्यवहार ("निर्दिष्ट पथ नहीं मिल सकता है") मिलता है।

यह एक बग है - CU 13 और हॉटफिक्स बिल्ड दोनों में। करने के लिए गलत पैरामीटर प्रदान करने BACKUPया RESTOREआदेशों सेवा दुर्घटना नहीं करना चाहिए या अपने सत्र मार डालते हैं। आप इसे फ़ीडबैक साइट पर रिपोर्ट कर सकते हैं ।

नोट: इस बग के सेवा-दुर्घटनाग्रस्त संस्करण को SQL सर्वर 2019 (CTP2.2) के सार्वजनिक पूर्वावलोकन संस्करण में पुन: पेश किया जा सकता है - इसे इंगित करने के लिए डेनिस रूबास्किन का धन्यवाद )

डिबगर में इसे देखते हुए, ऐसा लगता है कि पथ सत्यापन कोड बस टूट गया है। यह समाप्त हो जाता है sqlmin!CheckFileStreamReserved, आपूर्ति मार्ग पर सामान्य (और काफी व्यापक) चेक के बाद पुनरावृत्ति करके एक स्टैक ओवरफ्लो का कारण बनता है। स्टैक ओवरफ्लो 3048 के निर्माण पर सेवा को नीचे लाता है। 3049 को एक ही चीज होती है, जिसमें एक्सेस उल्लंघनों के अनुक्रम को छोड़कर पूरे सर्वर को रोकने के बजाए स्टैक ओवरफ्लो को संभालने का प्रयास करते हुए कनेक्शन को तोड़ दिया जाता है।

SQL सर्वर 2017 CU 15 में इस बग के लिए कोई फ़िक्सेस जारी किया गया था:

FIX: SQL सर्वर 2017 क्रैश अतिप्रवाह के कारण क्रैश हो जाता है जब आप डेटाबेस मास्टर को डिस्क पर बैकअप लेने का प्रयास करते हैं

समस्या SQL Server 2019 CTP 3.0 में भी हल है।

— जोश डारनेल
स्रोत