मैंने देखा है कि कुछ डीबीए SQL सर्वर को बहुत बार फिर से शुरू करते हैं, कभी-कभी रात में भी। मेरा मानना है कि वे इसे कुछ स्मृति को मुक्त करने के लिए करते हैं, या शायद प्रश्नों को गति देने के लिए भी। मुझे पता है कि फिर से शुरू होने के बाद क्वेरी प्लान को फिर से तैयार करना होगा, लेकिन यहां तक कि मुझे आश्चर्य है कि अगर इस अभ्यास का शुद्ध लाभ है।
क्या यह सच है कि SQL सर्वर को रोजाना रीस्टार्ट करने से यह तेजी से चलता है
जवाबों:
सर्वर को पुनरारंभ करना संभवतः प्रदर्शन के लिए सबसे हानिकारक चीजों में से एक है। इसका अर्थ है कि आप डेटा के लिए एक ठंडा कैश, क्वेरी योजनाओं के लिए एक ठंडा कैश और सभी SQL सर्वर आंतरिक कैश भी प्रक्रिया में nuked हैं। यह उल्लेख नहीं करने के लिए कि परिचालन सांख्यिकी DMV में एकत्र किए गए सभी आंकड़ों को फेंकने से, आप कभी भी सफलतापूर्वक कुछ जांच करने के अपने अवसरों को कम कर देते हैं।
इस प्रथा का समर्थन करने वाला कोई आधिकारिक मार्गदर्शन नहीं है, मैंने इसे किसी भी अच्छे अभ्यास के लिए उल्लेख नहीं किया है। यह मत करो।
जबकि अन्य उत्तर अच्छे हैं, उन्हें एक महत्वपूर्ण टुकड़ा याद आ रहा है: विंडोज की फाइल कैश।
64-बिट विंडोज पर, मेमोरी की मात्रा के लिए कोई कैप नहीं है विंडोज विंडोज़ को कैश करने के लिए उपयोग करेगी। विंडोज़ आपके सिस्टम को मेमोरी के पूरी तरह से सूखा कर सकता है, और उस बिंदु पर, आप डिस्क पर स्वैप करना शुरू कर देंगे। इसे कुछ स्थानों पर प्रलेखित किया गया है:
SQL सर्वर को पुनरारंभ करके, आप SQL को मेमोरी छोड़ने के लिए मजबूर करते हैं, जिससे विंडोज अधिक मिलता है, और पेजिंग अस्थायी रूप से बंद हो जाती है। SQL फिर से शून्य-शून्य मेमोरी उपयोग पर शुरू होगा और धीरे-धीरे ऊपर जाएगा, और जब बॉक्स फिर से मेमोरी से बाहर चला जाएगा, तो पुनरारंभ अस्थायी रूप से मदद करेगा। संपूर्ण OS को पुनरारंभ करके, आप विंडोज के फ़ाइल कैश का उपयोग करने के लिए भी बाध्य करेंगे।
असली फ़िक्स: विंडोज़ सर्वर से फ़ाइलों को कॉपी करना बंद करें या डायनामिक फ़ाइल कैश सर्विस के उपयोग के लिए फ़ाइल कैश की मात्रा को कैप करें, जैसा कि ऊपर उन ब्लॉग पोस्ट में दर्ज़ किया गया है।
यदि यह प्रश्नों को गति देता है, तो पैरामीटर सूँघना शामिल हो सकता है। यदि एक बकवास योजना को कैश किया जाता है और अनुचित कॉल के लिए लागू किया जाता है, तो रिबूटिंग का चमत्कार आम / सही योजना को कैश करने की अनुमति देता है। यदि ऐसा है, तो व्यवहार को सही करने के असीम रूप से बेहतर तरीके हैं जैसा कि अन्य ने संकेत दिया है। लेकिन जब तक वे बॉक्स को रिबूट करना बंद नहीं करते, तब तक मूल कारण विश्लेषण करने का कोई तरीका नहीं है।
आपको तब तक SQL सर्वर को पुनरारंभ नहीं करना चाहिए जब तक कि आपने सेवा गुण नहीं बदले हैं या स्टार्टअप निशान नहीं लगाए हैं जिन्हें आप तुरंत प्रभाव में लेना चाहते हैं।
जैसा कि @RemusRusanu ने कई बिंदुओं को बताया है, यह बहुत सारे कैश को साफ करता है और SQL सर्वर को अनावश्यक स्टार्टअप के बहुत सारे काम करने का कारण बनता है ।
ऐसा लगता है कि यह सर्वर एक समर्पित SQL सर्वर / डेटाबेस सर्वर नहीं है। उत्पादन डेटाबेस सर्वर का केवल एक ही उद्देश्य है ... डेटाबेस सर्वर होना सबसे अच्छा अभ्यास है। किस स्थिति में, आप ओएस के लिए पर्याप्त मेमोरी और संसाधन अलग सेट करेंगे और SQL सर्वर को बाकी सब कुछ देंगे। यह आपको किसी अन्य एप्लिकेशन या सर्वर भूमिकाओं को भूखा नहीं रखने के लिए प्रेरित करेगा।
मैं इस भावना से सहमत हूं कि यदि आप सब कुछ ठीक कर रहे हैं, तो आपको अपने MSSQL सर्वर को रिबूट / रिस्टार्ट करने की आवश्यकता नहीं हो सकती है।
मेरे लिए यह उस परिदृश्य पर लागू होता है जहां हर कोई सक्षम है और आप कुछ भी ठीक कर सकते हैं।
मैं डीबीए नहीं हूं। मैं एक सॉफ्टवेयर आर्किटेक्ट हूं और इसमें पूरे डेटाबेस स्कीम्स को स्क्रैच से बनाना शामिल है और दुर्भाग्य से , 3rd पार्टी डेटाबेस के साथ काम करते हुए कि मेरा पूरी तरह से नियंत्रण नहीं है ।
लोगों, जिन्होंने हमारे प्रमुख 3 पार्टी डेटाबेस में से एक को बनाया और बनाए रखा, बमुश्किल इसे कार्यात्मक बनाया।
क्या मैंने उल्लेख किया कि मैं सुरक्षा विशेषज्ञ या नेटवर्क इंजीनियर भी नहीं हूं?
मेरे लिए सवाल तो यह हो जाता है: क्या मुझे हर 3 महीने की तुलना में अधिक बार SQL सर्वर को पुनरारंभ करना चाहिए?
प्रदर्शन के एक अतिरिक्त इंच के वादे के लिए शेड्यूलिंग पुनरारंभ, बारिश के लिए नृत्य करने जैसा है।
शायद यह आ जाएगा, हो सकता है कि यह नहीं होगा, लेकिन आप यह सुनिश्चित करने के लिए नहीं जानते होंगे कि बारिश के कारण क्या हुआ।
मैं कह आप पसंद नहीं करते कभी नहीं एक समस्या का निवारण या विफलता सत्यापित करने के लिए यह पुनः प्रारंभ करने की आवश्यकता है, लेकिन मैं कर बेतरतीब ढंग से होने से एक अज्ञात प्रदर्शन मुद्दा रखने के लिए समय-निर्धारण पुनरारंभ के साथ एक समस्या है।
इसका एकमात्र अपवाद यह है कि यदि आप एक दुष्ट तृतीय पक्ष डेटाबेस का प्रबंधन करते हैं, जहां इसे हर हफ्ते या दो बार रिबूट किया जाता है, तो इसे चालू रखने का एकमात्र तरीका है और आपको इसे ठीक करने या छूने की भी अनुमति नहीं है।
फिर भी, आपको फ़िक्सेस की तलाश करनी चाहिए, उन्हें मालिक के साथ साझा करना चाहिए, और हल होने तक नरक बढ़ाएं।