क्वेस्ट के डेटाबेस ट्रेनिंग डेज़ फ़ॉल सीरीज़ के हिस्से के रूप में, ब्रेंट ओज़र, माइक्रोसॉफ्ट सर्टिफाइड मास्टर ने "क्वेरी ट्यूनिंग के साथ गतिरोध से बचना" पर एक ट्यूटोरियल प्रस्तुत किया। कार्यक्रम तीन समवर्ती मुद्दों पर केंद्रित था जो SQL सर्वर में होते हैं, उन्हें ठीक करने के तीन तरीके और एक तरीका जो उन्हें ठीक करने के लिए प्रतीत होता है, लेकिन वास्तव में ऐसा नहीं करता है।
Concurrency समस्या:SQL सर्वर में लॉक करना, ब्लॉक करना और गतिरोध करना
समवर्ती मुद्दे क्या हैं? वे तब होते हैं जब क्वेरीज़ टेबल जैसे डेटाबेस ऑब्जेक्ट्स पर एक-दूसरे के साथ संघर्ष से बचने की कोशिश करते हैं। वे हैं:
- लॉक करना - अन्य प्रश्नों को एक ही समय में तालिका का उपयोग करने से रोकने के लिए क्वेरीज़ हर समय ऐसा करती हैं। यह एक सामान्य डेटाबेस ऑपरेशन है।
- अवरुद्ध करना - यह तब होता है जब एक क्वेरी में सामान्य लॉक होता है, लेकिन दूसरी क्वेरी उसी लॉक को प्राप्त करने का प्रयास करती है। दूसरी क्वेरी को लॉक जारी करने के लिए पहली क्वेरी के लिए आवश्यक होने तक प्रतीक्षा करनी होगी। पहली क्वेरी की प्रकृति के आधार पर, दूसरी क्वेरी बहुत कम समय या बहुत लंबे समय तक प्रतीक्षा कर सकती है। यह लंबे समय तक प्रतीक्षा ही है जो वास्तव में प्रदर्शन को प्रभावित करती है।
- गतिरोध - डेडलॉक तब होता है जब एक क्वेरी लॉक लेती है, दूसरी क्वेरी एक अलग लॉक लेती है, और फिर प्रत्येक दूसरे का लॉक प्राप्त करना चाहता है। SQL सर्वर किसी एक क्वेरी को पीड़ित के रूप में निर्दिष्ट करके और गतिरोध को तोड़ने के लिए उसे मारकर इसका समाधान करता है। भले ही कोई एक क्वेरी आगे बढ़ने में सक्षम हो, लेकिन इसका प्रदर्शन पर भी प्रभाव पड़ता है।
समवर्ती मुद्दों को ठीक करना
भले ही आप SQL सर्वर में अवरोध या गतिरोध का अनुभव कर रहे हों, समवर्ती समस्याओं को ठीक करने के तरीके हैं। ब्रेंट ने इन तीन विधियों को प्रस्तुत किया, और शेष सत्र का अधिकांश समय दूसरे एक पर ध्यान केंद्रित करने में बिताया - खराब कोड को ठीक करना।
- आपके पास अपनी क्वेरी को तेज़ बनाने के लिए पर्याप्त इंडेक्स हैं, लेकिन इतने नहीं हैं कि वे प्रश्नों को लंबे समय तक अधिक लॉक बनाकर चीजों को धीमा कर दें
- अपने लेन-देन कोड को ट्यून करें ताकि क्वेरीज़ हर बार एक ही अनुमानित क्रम में तालिकाओं के माध्यम से काम करें
- अपने आवेदन की जरूरतों के लिए सही अलगाव स्तर का उपयोग करें
जैसे ही उन्होंने कार्यक्रम के व्यावहारिक भाग में छलांग लगाई, ब्रेंट ने अवरुद्ध और गतिरोध के लिए NOLOCK कथनों का उपयोग करने पर टिप्पणी की। उन्होंने आगाह किया कि NOLOCK वास्तव में इन समस्याओं को ठीक नहीं करता है क्योंकि यह "डर्टी रीड्स" पर निर्भर करता है - अनिवार्य रूप से, यह अन्य प्रश्नों के रो लॉक को अनदेखा करता है।
स्टैक ओवरफ्लो डेटाबेस का उपयोग करते हुए इसके प्रदर्शन में, उन्होंने एक साधारण क्वेरी बनाई जो "एलेक्स" नाम के लोगों को ढूंढती और गिनती थी। फिर, उन्होंने एक और क्वेरी बनाई जो उन लोगों पर एक अपडेट चलाएगी जो नहीं . हैं एलेक्स नाम दिया गया—रिकॉर्ड का कोई सम्मिलन या विलोपन नहीं। एक प्रश्न का दूसरे से कोई लेना-देना नहीं होना चाहिए। लेकिन, उन्हें एक साथ चलाने से एलेक्स नाम के लोगों की संख्या में अलग-अलग परिणाम सामने आते हैं। ऐसा इसलिए है क्योंकि NOLOCK आपको वह डेटा देखने देता है जो प्रतिबद्ध नहीं था, जिससे ऐसे यादृच्छिक परिणाम प्राप्त होते हैं जिनकी आप भविष्यवाणी नहीं कर सकते। यह केवल संगामिति के अंतर्गत होता है।
स्पष्ट रूप से, SQL सर्वर में अवरुद्ध और गतिरोध के लिए एक बेहतर सुधार की आवश्यकता है जो यादृच्छिक और अप्रत्याशित परिणाम नहीं देता है।
SQL गतिरोध के लिए एक बेहतर समाधान
ब्रेंट ने तब दिखाया कि कैसे एक गतिरोध को ठीक करने वाले कोड को बदलकर इसे ठीक किया जाए। उनके पहले डेमो में एक साधारण स्थिति दिखाई गई जिसमें दो टेबल शामिल थे ताकि दर्शकों को धीमी गति में गतिरोध दिखाई दे, जबकि ऐसा हुआ। चूंकि SQL सर्वर हर 5 सेकंड में गतिरोध की तलाश करता है और उस क्वेरी को समाप्त कर देता है जो वापस रोल करने में सबसे आसान है, हम गतिरोध पीड़ित को उभरने में सक्षम थे।
एक साधारण स्थिति में, सबसे सामान्य सलाह लागू होती है, और वह है प्रश्नों का निर्माण करते समय हर बार उसी क्रम में तालिकाओं को छूना। यह आम तौर पर प्रश्नों को एक दूसरे के गतिरोध से बचाए रखेगा।
अधिक जटिल प्रश्नों के बारे में क्या? इस परिदृश्य के लिए, ब्रेंट ने एक अधिक यथार्थवादी स्थिति का उपयोग किया जो आसानी से स्टैक ओवरफ्लो पर उत्पन्न हो सकती है जहां दो लोग एक-दूसरे के प्रश्नों को उठा रहे हैं। क्योंकि एक ही उपयोगकर्ता दोनों लेन-देन में शामिल होते हैं, यह गतिरोध का कारण बनता है।
यहां, प्रत्येक तालिका के माध्यम से हर बार एक ही क्रम में काम करना पर्याप्त नहीं है, लेकिन प्रत्येक तालिका को छूने की संख्या को कम करना भी आवश्यक है। जैसा कि ब्रेंट ने समझाया, फिक्स में कुछ बदसूरत कोड शामिल हो सकते हैं जो प्रश्नों को अवरुद्ध करने का कारण बनते हैं, लेकिन कम से कम गतिरोध नहीं। इस मामले में, एक छोटी अवधि का ब्लॉक जो दोनों प्रश्नों को पूरा करने की अनुमति देता है, उनमें से एक को समाप्त करने वाले गतिरोध से बेहतर है।
कोई भी सैकड़ों प्रश्नों में कोड बदलना नहीं चाहता है, इसलिए उन पर ध्यान केंद्रित करें जो लगातार गतिरोध कर रहे हैं, लेन-देन से किसी भी अनावश्यक रेखा को हटा दें, और गतिरोध से बचने के लिए एक ब्लॉक शुरू करने से डरो मत।
