SQL सर्वर हर दिन की योजना बना रहा है

Question

हमारे उत्पादन वातावरण में यह समस्या है।

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) - एंटरप्राइज़ संस्करण (64-बिट) Windows NT 6.1 पर (बिल्ड 7601: सर्विस पैक 1)।

SQL सर्वर पुराने निष्पादन योजनाओं के सभी (लगभग 100%) को छोड़ रहा है और उन्हें हर रात (11:00 बजे से रात 8:00 बजे तक) फिर से बना रहा है। यह तब भी हो रहा था जब 'ऑटो अपडेट आँकड़े' अक्षम अवस्था में थे। हमने पिछले 2-3 सप्ताह के लिए 'ऑटो अपडेट आँकड़े' चालू किए हैं। लेकिन यह अभी भी हो रहा है।

हमें वास्तव में यह पता नहीं है कि इस पुन: निर्माण की योजना क्या है, लेकिन हमें यकीन है कि हम इसे मैन्युअल रूप से नहीं करते हैं।

केवल एक चीज जो वास्तव में पुनर्जीवित होने वाली योजनाओं के समय के साथ मेल खाती है, वह एक DB रखरखाव कार्य है जो हमारे पास है: दैनिक सूचकांक पुनर्गठन (जब विखंडन 5-30% है), और दैनिक सूचकांक पुनर्निर्माण (जब विखंडन 30% से अधिक है) ) काम। आमतौर पर यह दैनिक रखरखाव का काम केवल पुनर्गठन करता है (क्योंकि दैनिक आधार पर सूचकांक विखंडन कभी भी 30% से अधिक नहीं होता है)।

प्रभाव:

ये नई बनाई गई योजनाएं कुछ यूडीएफ कॉल / क्वेरी कॉल करती हैं (जो यूआई / वेब पेज से कॉल की जाती हैं) अधिक समय लेती हैं (1 सेकंड से कम समय के विपरीत मिनट), और इसलिए सत्र केवल सीपीयू को 90% के करीब ले जाते हैं। ।

यह समस्या उस समय दूर हो जाती है जब अटके हुए सत्रों को बलपूर्वक (डीबी की तरफ) हटा दिया जाता है, और 1) जब यूडीएफ को बदल दिया जाता है (कार्य के लिए) मैन्युअल रूप से सभी संबंधित निष्पादन योजनाओं को मैन्युअल रूप से (प्रश्नों के लिए) या 2) मंजूरी दे दी जाती है। उस क्षण से SQL सर्वर द्वारा बनाई गई कोई भी नई योजना पूरे दिन में सही काम करती है जब तक कि अगली सुबह उसी मुद्दे को समाप्त न हो जाए। इसके अलावा, यह व्यवहार 100% संगत नहीं है, हम वास्तव में इसे प्रत्येक सुबह नहीं देख रहे हैं। लेकिन कुछ समय ऐसे रहे हैं जब हम इसे लगातार 4-5 दिनों से देख रहे हैं।

यह समस्या बिजनेस मॉर्निंग पर होती है, जब यूआई / वेब पेजों को अधिक गहनता से एक्सेस किया जाता है, ऐसा लगता है।

क्या किसी को कोई सुराग है कि यह क्या कारण है और इस समस्या को कैसे हल किया जाए? कोई भी सहायताकाफी प्रशंसनीय होगी।

Comments

जब मशीन मेमोरी के दबाव में होती है या आप सेटिंग्स बदलते हैं तो db लेवल को बंद कर दिया जा सकता है। (परिवर्तन db)। चूंकि आपने कहा था कि आप उन्हें "मैन्युअल रूप से" नहीं हटाते हैं, इसलिए मुझे लगता है कि यह स्मृति दबाव हो सकता है। मशीन में कितनी मेमोरी है? आपकी अधिकतम मेमोरी सेटिंग्स क्या है? क्या आपके पास एक आभासी वातावरण है और शायद समग्र रैम है?

— रयोफॉसमैंड

तुम SP1 में क्यों हो इससे पहले कि आप कोई भी चीज SP3 लागू करें। SQL सर्वर प्लान्स को बाध्य कर सकता है यदि यह मेमोरी प्रेशर पाता है और विशेष रूप से इंडेक्स पुनर्निर्माण से पृष्ठों को समायोजित करने के लिए अधिक मेमोरी की आवश्यकता होती है यदि आपके पास बड़ी टेबल हैं। सूचकांक के पुनर्निर्माण के लिए अधिक से अधिक पृष्ठ लाने की कोशिश की जाएगी। आप क्या कर सकते हैं एमपी का उपयोग करना बंद करें और ओला हॉलेनग्रेन समाधान का उपयोग करें और देखें कि क्या यह मदद करता है। अधिकतम सर्वर मेमोरी क्या है?

— शंकी

दोस्तों, मैं एक DBA नहीं हूँ, केवल एक SQL डेवलपर हूँ। मैं बस यह सब पूछ रहा हूं क्योंकि यह काफी समय से चल रहा है। आपकी टिप्पणियों के लिए धन्यवाद, मैं उन सभी को जवाब देने की कोशिश करूंगा, भले ही अभी के लिए मुझे इसका पालन करना मुश्किल है (और यह सब आपके लिए बहुत स्पष्ट लगता है)। क्या है सांसद?

— peter.petrov

@ peter.petrov हम आपके पर्यावरण को जानने के लिए आपकी मदद करने की कोशिश कर रहे हैं। सांसद = रखरखाव की योजना।

— परिजन शाह

असली समस्या यह है कि आपकी क्वेरी योजनाएँ इतनी नाजुक हैं। आवर्धन कभी भी, दिन के दौरान भी हो सकता है। कोई गारंटी नहीं। अपने प्रश्नों को ठीक करें ताकि योजनाएं स्थिर हो जाएं। विकल्प के लिए विकल्प या विकल्प के लिए विकल्प स्लेजहैमर दृष्टिकोण हैं जो उचित हो सकते हैं और एक त्वरित फिक्स हो सकते हैं।

— usr

Answer 1

वैसे मेरे पास कुछ विचार हैं जो इस व्यवहार का कारण बन सकते हैं।

1. क्या आप अपने मेमोरी प्रेशर पर नजर रखते हैं? हो सकता है कि आपकी क्वेरी एक निश्चित सीमा बढ़ाती है, जो योजना कैश के फ्लश का कारण बनेगी। मुझे आपके आवेदन की जानकारी नहीं है, लेकिन क्या यह आपके फ्रंटएंड सर्वरों के लॉग से मेल खाता है? क्या इस दौरान भी दबाव रहता है?
2. क्या आपके पास एक समर्पित SQL सर्वर है या क्या सर्वर अन्य प्रक्रियाओं / सेवाओं के साथ हार्डवेयर साझा करता है? यदि नहीं, तो अपने SQL सर्वर को इसके बजाय एक समर्पित मशीन को आउटसोर्स करने पर विचार करने का प्रयास करें। यह अन्य सेवाओं से दुष्प्रभाव को कम करेगा।
3. आप उपयोग करना चाह सकते हैं optimize for ad hoc workloads, जो योजना स्टब को बचाएगा और यदि आवश्यक हो तो इसे संकलित कर सकता है। यह आपके प्लेंचे के भार को कम करेगा, जिससे प्लेंश के फ्लशिंग होने की संभावना कम होगी। आप इसका उपयोग करके सक्षम कर सकते हैं sp_configure 'optimize for ad hoc workloads',1; reconfigure। यह किया जा सकता है यदि आपने advanced optionsउपयोग करने में सक्षम किया है sp_configure 'show advanced options',1; reconfigure।
4. एक और विचार बैकअप हो सकता है। बस सरल बैकअप। यदि वे आक्रामक रूप से होते हैं, तो ऐसा हो सकता है कि आपकी मशीन दबाव में आ जाए। जिस समय आपका उल्लेख सिर्फ बैकअप की योजना बनाने के लिए एक अच्छे समय की तरह लगता है।
5. हो सकता है कि यह आपके रखरखाव स्क्रिप्ट में काफी सरल बग हो। क्या आपने जाँच की है कि क्या कोई तार्किक मुद्दा है जो आपकी स्क्रिप्ट को उन सभी सूचकांकों के पुनर्निर्माण का कारण बनता है जो मानदंडों से मेल खाते हैं। यह शायद यह भी पैदा कर सकता है।

बस इस संभावनाओं के सभी के बगल में, यह विकल्प के लिए कुछ परिवर्तन के लिए लॉग फाइल की जांच करने के लिए उपयोगी हो सकता है affinity mask, affinity I/O maskऔर उनके 64 सहयोगियों के। एक और चीज MAXDOPआपके उदाहरण के विकल्प का बदलाव हो सकती है । कृपया उनके लिए लॉग भी देखें। उन्हें प्लेंचे को भी फ्लश करना होगा।

अंतिम लेकिन कम से कम, आप अभी भी एक सर्वरसाइड ट्रेस चला सकते हैं (बस इसे प्रोफाइलर का उपयोग करके स्थापित करना शुरू करें, इसे रोकें और SQLL कमांड का उपयोग करके इसे सर्वर पर फिर से शुरू करें)। बगल में जो perfmonतुम्हारा दोस्त है। यह आपके प्रदर्शन मूल्यों को एक समय के लिए देख और देख सकता है। हो सकता है कि आप अपने सर्वर पर कुछ कार्यों के साथ दबाव में समानताएं देख सकते हैं जो उन फ्लश का कारण हो सकता है।

उम्मीद है कि यह आपकी मदद करेगा, भले ही जवाब थोड़ा बाद में आए।