प्रस्तावना
एक सूचना प्रणाली है जिसे मैं प्रशासित करता हूं। सिस्टम में निम्नलिखित घटक होते हैं:
1. MS SQL सर्वर डेटाबेस
2. सर्वर अनुप्रयोग
3. क्लाइंट एप्लिकेशन
ये सूचना प्रणाली कई वस्तुओं पर स्थापित हैं। प्रत्येक वस्तु पर एक बार में 2 से 20 उपयोगकर्ताओं द्वारा 24 घंटे सक्रिय रूप से सूचना प्रणाली का उपयोग किया जाता है। इसलिए, आप एक ही बार में नियमित रखरखाव नहीं कर सकते। इसलिए, मुझे एक ही झटके में सभी आवश्यक खंडित अनुक्रमितों को डीफ़्रैग्मेन्ट करने के बजाय, पूरे दिन SQL सर्वर इंडेक्स डीफ़्रैग्मेन्टेशन को «फैलाना» है। यह अन्य कार्यों पर भी लागू होता है।
आँकड़े स्वतः अद्यतन गुण डेटाबेस के गुणों में सेट होते हैं। इसके अलावा, आंकड़े डीफ़्रेग्मेंटेड इंडेक्स पर अपडेट किए जाते हैं।
समस्या
लगभग एक साल पहले, मुझे निम्नलिखित समस्या का सामना करना पड़ा:
समय-समय पर, सभी प्रश्न धीमे चल रहे थे। विशेष रूप से, देरी का समय यादृच्छिक था। यह हर वस्तु पर एक यादृच्छिक दिन पर हुआ। इसके अलावा, जब मैंने विश्लेषण करना शुरू किया कि कितनी बार देरी होती है (प्रोफाइलर का उपयोग करके), मुझे पता चला कि वे हर दिन यादृच्छिक समय पर होते हैं। उपयोगकर्ता हमेशा उन पर ध्यान नहीं देते बल्कि उन्हें केवल यादृच्छिक विलंब के रूप में लेते हैं, और फिर सिस्टम फिर से जल्दी से काम करता है।
समस्या का समाधान
मैंने धीमी गति से चलने वाले सभी प्रश्नों की समीक्षा की है। सबसे अजीब बात यह थी कि सभी क्वेरी एक यादृच्छिक समय पर धीमी गति से चल रही थीं, यहां तक कि सबसे सरल भी, जैसे कई हज़ार पंक्तियों वाली तालिका से अंतिम रिकॉर्ड खींचना।
इसके अलावा, मैंने निम्नलिखित चरणों का पालन किया:
1. मैंने MS SQL सर्वर और Windows सर्वर लॉग का विश्लेषण किया, लेकिन देरी का कारण नहीं खोज सका।
2. मैंने इंडेक्स (विखंडन, आदि) का विश्लेषण किया, लापता लोगों को जोड़ा और अप्रयुक्त को हटा दिया।
3. मैंने प्रश्नों का विश्लेषण किया - कुछ प्रश्नों में सुधार किया गया।
4. मैंने SQL एजेंट में कार्यों का विश्लेषण किया और कार्यों को विलंब की समस्या से संबद्ध नहीं कर सका।
5. मैंने टास्क शेड्यूलर में कार्यों का विश्लेषण किया और कार्यों को देरी की समस्या से संबद्ध नहीं कर सका।
6. प्रोफाइलर ने परिणाम दिखाए, लेकिन देरी का कारण नहीं दिखाया।
7. मैंने गतिरोध के लिए एक जाँच की - कोई लंबी रुकावटें सामने नहीं आईं।
नतीजतन, मैंने कभी-कभी धीमी गति से चलने वाली क्वेरी के कारण की असफल खोज पर 3 महीने से अधिक समय बिताया। हालांकि, मैंने एक दिलचस्प तथ्य का खुलासा किया - कार्यकर्ता निष्पादन संकेतक के बजाय, सभी प्रश्नों के लिए बीता हुआ प्रतीक्षा संकेतक बढ़ गया। इस तथ्य ने मुझे यह विचार दिया कि डिस्क में कुछ गड़बड़ है। मैंने उन्हें चेक किया - सब कुछ ठीक था।
समाधान
मेरे आश्चर्य के लिए, मैंने गलती से खुलासा किया कि जब आवेदन में एक प्रश्न धीरे-धीरे निष्पादित किया गया था, तो यह एसएसएमएस में जल्दी से चला गया। एक लेख ने समस्या को हल करने में मदद की (कम से कम इसने विचार का सुझाव दिया)।
लेख का एक पैराग्राफ:
व्यवहार में, सबसे महत्वपूर्ण SET विकल्प ARITHABORT है, क्योंकि इस विकल्प के लिए डिफ़ॉल्ट मान अनुप्रयोगों के लिए और SQL सर्वर प्रबंधन स्टूडियो के लिए भिन्न है। यह बताता है कि आप अपने आवेदन में धीमी गति से चलने वाली क्वेरी का पता क्यों लगा सकते हैं, और फिर इसे एसएसएमएस में निष्पादित करके अच्छी गति प्राप्त कर सकते हैं। एप्लिकेशन एक योजना का उपयोग करता है जो वास्तविक सही मूल्यों से भिन्न मूल्यों के एक सेट के लिए बनाया गया था। जबकि यदि आप SSMS में क्वेरी चलाते हैं, तो यह सबसे अधिक संभावना है कि कैश में अभी तक ARITHABORT ON के लिए निष्पादन योजना नहीं है, और इसलिए SQL सर्वर आपके वर्तमान मूल्यों के लिए एक योजना तैयार करेगा।
निष्पादन में अंतर SET ARITHABORT पैरामीटर के कारण था। एसएसएमएस में निष्पादित सभी प्रश्नों के लिए, यह विकल्प सक्षम है, और बाहर से (एप्लिकेशन से) प्रश्नों के लिए - अक्षम है। इसे अनुप्रयोगों के लिए एक साधारण क्वेरी द्वारा भी सक्षम नहीं किया जा सकता है:
SET ARITHABORT ON;
एक पागल विचार का पालन किया गया - हैंगअप के समय प्रक्रियात्मक कैश को साफ़ करना।
बाद की मैन्युअल जांच के लिए, मुझे SSMS में क्वेरी से पहले निम्नलिखित कथन लिखना होगा:
SET ARITHABORT OFF;
इस प्रकार हम एप्लिकेशन के संचालन का अनुकरण करेंगे। जब क्वेरी लंबे समय से चल रही थी, तो मैंने प्रक्रियात्मक कैश को साफ़ कर दिया। और इससे हमेशा मदद मिली। प्रक्रियात्मक कैश को साफ़ करने से पहले, क्वेरी 20-30 सेकंड तक और बाद में - 0 सेकंड तक चल सकती है।
उसके बाद, मैंने एक और प्रयोग किया - SQL एजेंट के माध्यम से हर घंटे पूरे डेटाबेस के लिए संपूर्ण प्रक्रियात्मक कैश को साफ करना:
--cleaning the cache by database id DBCC FLUSHPROCINDB (@db_id);
उसके बाद, सभी प्रश्न बहुत तेज़ी से (0.05 सेकंड से कम) चले। निष्पादन के 5-10 सेकंड तक केवल कुछ घटनाएं हुईं, लेकिन उपयोगकर्ताओं ने कोई हैंगअप नहीं देखा। इसके अलावा, आँकड़ों को अद्यतन करने से परिणामों में सुधार नहीं हुआ, इसलिए मैंने सांख्यिकी अद्यतन को अक्षम कर दिया।
कुछ और महीनों के अध्ययन के बाद, मुझे पता चला कि कभी-कभी हैंगअप तब होता है जब या तो कैश सर्वर पर सब कुछ खा लेता है, और कोई खाली जगह नहीं बची है या कोई खाली मेमोरी नहीं है, लेकिन 1 जीबी से कम रैम या एमएस एसक्यूएल सर्वर सेवा सभी आवंटित रैम (टास्क मैनेजर के माध्यम से) पर कब्जा कर लेता है। लेकिन दूसरी घटना पूरे अध्ययन के अनुसार केवल दो बार हुई।
तथ्य यह है कि वस्तुतः सब कुछ कैश में लिखा जाता है, जबकि कैश हमेशा समय पर जारी नहीं होता है। कैश की समस्या को EmptyStandbyList.exe प्रोग्राम का उपयोग करके हल किया गया था।
मैंने इस एप्लिकेशन को टास्क शेड्यूलर के माध्यम से हर घंटे 1 बार चलाने के लिए कॉन्फ़िगर किया है। सभी काम पूरे होने के बाद, अब आधे साल से अधिक समय से सभी वस्तुओं पर कोई क्वेरी हैंगअप नहीं है।
केवल एक चीज जो अस्पष्ट रहती है, वह दुर्लभ मामले हैं जब एक क्वेरी 5-10 सेकंड के लिए महीने में एक बार यादृच्छिक दिन पर और यादृच्छिक समय पर हैंग होती है। ऐसे 4 मामले थे और आधे साल के लिए केवल दो ऑब्जेक्ट्स पर जब MS SQL सर्वर सेवा सभी आवंटित मेमोरी को थोड़े समय के लिए घेर लेती है।
मूल रूप से, गहरी खुदाई करने की कोई आवश्यकता नहीं है, क्योंकि उपयोगकर्ताओं को कोई हैंगअप दिखाई नहीं देता है और सब कुछ ठीक काम करता है, लेकिन अगर किसी के पास कोई विचार है, तो मैं साझा करने के लिए आभारी रहूंगा।
यह लेख उन लोगों की मदद करने के लिए लिखा गया था जो ऐसी समस्याओं का सामना करते हैं, क्योंकि मुझे इंटरनेट पर एक व्यापक उत्तर नहीं मिला, और मैंने समस्या का अध्ययन करने और समाधान खोजने में बहुत समय बिताया।
यह भी देखें:
- क्वेरी, संग्रहीत कार्यविधियों और ट्रिगर के लिए SQL सर्वर प्रदर्शन संकेतक लागू करना
- MS SQL सर्वर डेटाबेस में स्वचालित अनुक्रमणिका डीफ़्रेग्मेंटेशन
उपयोगी टूल:
SQL सर्वर के लिए dbForge क्वेरी बिल्डर - उपयोगकर्ताओं को मैन्युअल कोड लेखन के बिना सहज ज्ञान युक्त दृश्य इंटरफ़ेस के माध्यम से त्वरित और आसानी से जटिल SQL क्वेरी बनाने की अनुमति देता है।
