SQL प्रदर्शन ट्यूनिंग डेटाबेस प्रबंधन के लिए इतना महत्वपूर्ण क्यों है?
क्योंकि यह आपको बड़ा समय बचा सकता है। मेरे साथ रहें और आप देखेंगे कि कैसे।
SQL प्रदर्शन ट्यूनिंग और डेटाबेस प्रबंधन — बिंदुओं को जोड़ना
अधिकांश डेटाबेस पेशेवर रोशनी को चालू रखने में अपना समय व्यतीत करते हैं। वे मेमोरी, स्टोरेज और नेटवर्क थ्रूपुट जैसे संसाधनों पर नज़र रखकर अपटाइम सुनिश्चित करने में अपना अधिकांश प्रयास निवेश करते हैं। यह डेटाबेस प्रबंधन का एक बड़ा हिस्सा है, लेकिन जैसे-जैसे अधिक कंपनियां अपने डेटाबेस को AWS और Azure जैसे लगभग असीमित क्लाउड संसाधनों में स्थानांतरित करती हैं, अन्य पहलू अधिक महत्वपूर्ण हो गए हैं।
SQL प्रदर्शन ट्यूनिंग उन पहलुओं में से एक है। एक बार जब रोशनी सुरक्षित रूप से चालू हो जाती है और आप डेटाबेस प्रबंधन में जरूरतों के पदानुक्रम को आगे बढ़ाते हैं, तो अगली चीज़ जो आप चाहते हैं वह है बेहतर प्रदर्शन, और इसके लिए ट्यूनिंग की आवश्यकता होती है।
एसक्यूएल में परफॉर्मेंस ट्यूनिंग करते समय पूछे जाने वाले पहले प्रश्न
जल्दी या बाद में, कई डेटाबेस पेशेवर खुद को एक SQL सर्वर के सामने पाते हैं जिसे उन्होंने नहीं बनाया था। उस स्थिति के लिए बहुत से मार्गदर्शक नहीं हैं। SQL प्रदर्शन ट्यूनिंग में खुदाई करने, क्या गलत है इसका पता लगाने और फिर इसे पुनरावृत्त रूप से ठीक करने का एक अभ्यास है।
अपने पहले सुधारों में, हो सकता है कि आप SQL कथनों को बिल्कुल भी स्पर्श न करें। कुछ डेटाबेस पेशेवर उपयोगकर्ता/सत्र स्तर पर शुरू होते हैं। वे वहां जाते हैं जहां उपयोगकर्ता नाखुश होते हैं, सुनते हैं कि उनकी शिकायतें कैसी लगती हैं और सवाल खड़े करते हैं।
- कौन सी स्क्रीन या पेज रेंडर होने में बहुत अधिक समय लेते हैं?
- जब वे नया टिकट बनाते हैं या मौजूदा टिकट खोलते हैं तो क्या आवेदन धीमा होता है?
- क्या किसी रिकॉर्ड को सहेजने में लंबा समय लगता है?
- कितना लंबा है "एक लंबा समय?"
एक बार जब उनके पास वे उत्तर होते हैं, तो वे देखते हैं कि डेटाबेस में इसका क्या कारण है।
यह पहले दिन बैठने और विखंडन जैसी किसी चीज़ से निपटने का निर्णय लेने से बेहतर है, जो उपयोगकर्ताओं को बिल्कुल भी प्रभावित नहीं कर सकता है। मुद्दा यह है कि उपयोगकर्ता किस चीज की परवाह करते हैं।
उदाहरण/डेटाबेस स्तर के बारे में भी सोचें। Microsoft की दुनिया में, उदाहरण के लिए, SQL सर्वर एजेंट कार्य शुरू करने के लिए एक अच्छी जगह है। वे क्रियाओं की एक श्रृंखला है जो आमतौर पर एक प्रशासनिक कार्य को परिभाषित करती है जिसे आप सफलता या विफलता के लिए मॉनिटर कर सकते हैं। वे सुविधाजनक होने के लिए हैं, लेकिन डेटाबेस प्रबंधन में कई चीजों की तरह, वे जमा हो जाते हैं क्योंकि लोग भूल जाते हैं कि उनकी उत्पत्ति कैसे हुई और वे क्या करते हैं।
आपको एक ही काम करते हुए कई काम मिल सकते हैं, जैसे कि एक इंडेक्स स्क्रिप्ट के विभिन्न संस्करण चलाना या इससे भी बदतर, एक दूसरे के खिलाफ काम करना। दो प्रश्नों के आलोक में पहले से कॉन्फ़िगर की गई नौकरियों की जांच करें:"यह नौकरी क्या करती है?" और, अधिक महत्वपूर्ण, "यदि मैं उस कार्य को रोक दूं, तो क्या कुछ बुरा होगा?"
आपको किन कारकों पर ध्यान देना चाहिए?
एक बार जब आप एसक्यूएल ट्यूनिंग के प्रदर्शन के स्तर पर पहुंच जाते हैं, तो यह कई कारकों से व्यवहार के लिए अपना संकेत लेता है। जैसा कि हमारे विशेषज्ञों से पूछें:डेटाबेस प्रदर्शन राउंडटेबल वेबकास्ट के दौरान वर्णित है, यदि आप इन जैसे कारकों को ढूंढते और सही ढंग से व्याख्या करते हैं, तो आप स्वयं SQL को ट्यून करने में कम समय व्यतीत कर सकते हैं:
- अवरुद्ध करना — यदि सर्वर ब्लॉक हो रहा है, तो यह टिक टिक टाइम बम की तरह है। मान लीजिए कि कोई स्क्रिप्ट लेन-देन शुरू करती है और उसे बंद नहीं करती है; जो एक लॉग फ़ाइल की ओर ले जा सकता है जो तब तक बढ़ती और बढ़ती है जब तक कि स्थान समाप्त नहीं हो जाता। प्रदर्शन के लिए अवरुद्ध करना बुरी खबर है, इसलिए इसे तुरंत देखें।
- एजेंट — SQL सर्वर एजेंट जॉब्स के एप्रोपोस, एडमिनिस्ट्रेटर अनजाने में परफॉर्मेंस-इम्पेयरिंग टास्क को जॉब में लपेटने के लिए जाने जाते हैं। वे लेन-देन निष्पादित कर सकते हैं या किसी नौकरी में अनुक्रमणिका का पुनर्निर्माण कर सकते हैं, या लेन-देन में डेटाबेस को छोटा कर सकते हैं। ऐसे मामले में, एजेंट को सभी संबद्ध कार्य बंद करने के लिए अस्थायी रूप से अक्षम करने पर विचार करें। यह एक आक्रामक तकनीक है, लेकिन अगर यह प्रदर्शन में सुधार करती है, तो आपको पता चल जाएगा कि क्यों।
- प्रतीक्षा आँकड़े — अपने आप से पूछें, "अभी सर्वर किसका इंतज़ार कर रहा है?" पेज लाइफ एक्सपेक्टेंसी और डिस्क क्यू की लंबाई जैसे मेट्रिक्स के कुछ जवाब हैं, लेकिन वे केवल एक संकीर्ण दृश्य प्रस्तुत करते हैं। प्रतीक्षा आँकड़े आपको प्रतीक्षा प्रकारों और प्रतीक्षा श्रेणियों के लेंस के माध्यम से सब कुछ दिखाते हैं, जिससे आप उन पाँच या अधिक प्रतीक्षा घटनाओं पर ध्यान केंद्रित कर सकते हैं जो सबसे अधिक समय लेती हैं। ब्रेंट ओज़र की sp_BlitzFirst यह पता लगाने के लिए एक भरोसेमंद संग्रहित प्रक्रिया है कि आपके SQL सर्वर क्वेरीज़ अभी किस चीज़ का इंतज़ार कर रही हैं। फिर, जब आप अपने सर्वर के लिए प्रतीक्षा आंकड़ों में लंबी अवधि के पैटर्न का अध्ययन करना चाहते हैं, तो एक प्रदर्शन निगरानी उपकरण देखें।
- व्यवस्थापक गतिविधि — इसे "पायलट त्रुटि" के रूप में भी जाना जाता है, क्योंकि आप स्वयं जो कर रहे हैं उससे कुछ प्रदर्शन समस्याएं उत्पन्न होती हैं। मान लीजिए कि आप एक ही समय में SQL सर्वर गतिविधि मॉनिटर और SQL सर्वर प्रोफाइलर दोनों चला रहे हैं, क्वेरी स्टोर सीखने का प्रयास कर रहे हैं। आप पर्यवेक्षक प्रभाव से आगे नहीं बढ़ सकते; जब आप इस तरह सब कुछ ट्रैक करते हैं, तो आप बस डेटाबेस को धीमा करने के लिए कह रहे हैं।
- सूचकांक — किसी ऐसी चीज के लिए जो फायदेमंद मानी जाती है, निश्चित रूप से इंडेक्स आपको गर्दन में दर्द दे सकते हैं। वास्तव में, वे सिर्फ एक गोली से अधिक के लायक हैं। आगे पढ़ें।
SQL प्रदर्शन ट्यूनिंग का अर्थ है अनुक्रमणिका पर कड़ी नज़र रखना
बड़े हिस्से में, SQL प्रदर्शन ट्यूनिंग इंडेक्स ट्यूनिंग तक सीमित हो जाती है। सौभाग्य से, यदि आप ऑन-प्रिमाइसेस डेटाबेस प्रबंधन में महारत हासिल करते हैं, तो आपके कौशल क्लाउड में डेटाबेस प्रबंधन को आसानी से स्थानांतरित किए जा सकते हैं।
इंडेक्स की बढ़ती विविधता के कारण इंडेक्स ट्यूनिंग महत्व प्राप्त कर रहा है:क्लस्टर्ड, गैर-क्लस्टर, अद्वितीय, फ़िल्टर्ड, कॉलमस्टोर, हैश, मेमोरी-अनुकूलित गैर-क्लस्टर, एक्सएमएल, स्थानिक और पूर्ण-पाठ, कुछ नाम रखने के लिए। लेकिन एक चीज जो कभी नहीं बदली है वह है इंडेक्स का पहला कॉलम, जो डेटाबेस इंजन द्वारा किए गए इंडेक्स निर्णयों को संचालित करता है।
कई विक्रेता बहुत सारे सुविचारित इंडेक्स के साथ एप्लिकेशन बेचते हैं और तैनात करते हैं जो कभी भी उपयोग नहीं किए जाते हैं या इससे भी बदतर, वास्तव में प्रदर्शन में बाधा डालते हैं। यदि आप कुछ सॉफ़्टवेयर उत्पादों में अप्रयुक्त इंडेक्स स्क्रिप्ट या इंडेक्स खपत स्क्रिप्ट की जांच करते हैं, तो आपको एक विदेशी कुंजी पर इंडेक्स का एक सरफ़ेट मिलेगा। यदि उत्पाद 20 विदेशी कुंजियों का उपयोग करता है, तो विक्रेता 20 इंडेक्स, प्लस दस सिंगल-कॉलम इंडेक्स, साथ ही एक अद्वितीय क्लस्टर इंडेक्स पर दस अन्य इंडेक्स भेज सकते हैं, और इसी तरह।
जब भी आपके पास विकल्प होता है, डेटाबेस आर्किटेक्चर तक पहुंचने का बेहतर तरीका एक क्लस्टर इंडेक्स से शुरू करना है जो आपको लगता है कि तालिका का सबसे अच्छा प्रतिनिधित्व करेगा। फिर, सिस्टम को कुछ देर के लिए अपने आप चलने दें। यदि और जैसा कि आपको अधिक अनुक्रमणिका की आवश्यकता है, उन्हें बनाएं। डिस्क स्थान भरने और वहां पर लॉक करने जैसी समस्याओं के साथ यहां बेहतर प्रदर्शन को बंद करने के लिए इंडेक्स जोड़ना एक अभ्यास है। यह देखना कठिन हो जाता है कि प्रत्येक अतिरिक्त अनुक्रमणिका समग्र रूप से सिस्टम को कैसे प्रभावित करती है।
उस मामले के लिए, इंडेक्स को खत्म करने पर विचार करें - जिस तरह से एलर्जी वाला व्यक्ति खाद्य समूहों को खत्म कर देगा - यह देखने के लिए कि प्रदर्शन कैसे बदलता है। प्रत्येक अनुक्रमणिका को अपने देव उदाहरण पर छोड़ने का प्रयास करें और देखें कि कौन-से आपके शीर्ष पांच प्रश्नों को प्रभावित करते हैं।
SQL सर्वर में प्रदर्शन ट्यूनिंग — इसके साथ आने वाले टूल
ध्यान दें कि आप इस प्रयास में अकेले नहीं हैं। SQL सर्वर में प्रदर्शन को बेहतर बनाने के लिए डिज़ाइन की गई सुविधाएँ शामिल हैं।
योजना मार्गदर्शिकाएँ आपको यह बदलने देती हैं कि SQL सर्वर किसी दी गई क्वेरी को कैसे चलाता है, और भले ही यह शुद्ध SQL प्रदर्शन ट्यूनिंग न हो, लेकिन यह प्रदर्शन को प्रभावित करता है। कई अनुप्रयोगों में बाहरी विक्रेता द्वारा लिखी गई SQL क्वेरी होती है, और भले ही उन प्रश्नों के कारण खराब प्रदर्शन हो, कुछ डेटाबेस पेशेवर उन्हें बदलने के लिए अनिच्छुक हैं। योजना गाइड के साथ आप क्वेरी के लिए एक प्रश्न संकेत या एक निश्चित योजना संलग्न कर सकते हैं और इसे प्रभावित कर सकते हैं कि यह कैसे चलता है।
हालाँकि, योजना गाइडों का नकारात्मक पक्ष यह है कि यद्यपि वे समय के साथ नहीं बदलते हैं, उनके आसपास का वातावरण करता है। एक मुद्रित रोडमैप की तरह, वे अल्पावधि में अच्छी तरह से काम कर सकते हैं और लंबे समय से पहले अप्रचलित हो सकते हैं, इसलिए यदि आप उन पर भरोसा करने जा रहे हैं, तो बेहतर होगा कि आप उन्हें कभी-कभी फिर से देखें।
योजना गाइड से संबंधित क्वेरी स्टोर है, जो SQL सर्वर की एक विशेषता है जो आपके सिस्टम में सबसे अधिक संसाधनों का उपभोग करने वाली क्वेरी को पहचानने और ट्यून करने में आपकी सहायता करती है। नए SQL सर्वर और Azure Synapse Analytics (SQL DW) डेटाबेस के लिए डिफ़ॉल्ट रूप से क्वेरी स्टोर सक्षम नहीं है। लेकिन यह नए Azure SQL डेटाबेस में डिफ़ॉल्ट रूप से सक्षम है।
सामान्य तौर पर, क्वेरी स्टोर को सक्षम करना मुश्किल नहीं है, लेकिन प्रत्येक SQL सर्वर को शुरू से ही इसकी आवश्यकता नहीं होती है। कुछ व्यवस्थापक क्वेरी स्टोर के बारे में नहीं जानते हैं, और कुछ इसके बारे में जानते हैं लेकिन अभी तक इसे पर्याप्त रूप से एक्सप्लोर करने के लिए समय नहीं लिया है; वे इसे अक्षम छोड़ने से बेहतर हैं। बाद में, जब वे समझते हैं कि क्वेरी स्टोर कैसे काम करता है, तो वे इसका उपयोग क्वेरी योजना परिवर्तनों के कारण प्रदर्शन अंतर खोजने के लिए कर सकते हैं।
अंत में, डेटाबेस इंजन ट्यूनिंग सलाहकार कार्यभार का विश्लेषण करता है और क्वेरी प्रदर्शन को बेहतर बनाने के लिए इंडेक्स या विभाजन रणनीतियों की सिफारिश करता है। अपने डेटाबेस पर ट्यूनिंग सलाहकार चलाना एक अच्छा विचार है; बस इसे बहुत जल्दी मत चलाओ। सुनिश्चित करें कि आपके डेटाबेस में पर्याप्त डेटा है ताकि अनुक्रमणिका अनुशंसाएँ मान्य हों। जब आप पहली बार अपना आवेदन बना रहे हों, तो आपके पास प्रत्येक तालिका में केवल एक हजार पंक्तियां हो सकती हैं। एक बार डेटाबेस बढ़ने के बाद ट्यूनिंग सलाहकार की सिफारिशें अधिक उपयोगी होती हैं।
मुझे पैसे दिखाओ
जैसा कि मैंने शुरुआत में उल्लेख किया है, SQL प्रदर्शन ट्यूनिंग डेटाबेस प्रबंधन के लिए महत्वपूर्ण है क्योंकि यह आपको पैसे बचा सकता है। कैसे?
विशेष रूप से क्लाउड में, जहां क्रेडिट कार्ड द्वारा स्केलिंग लोकप्रिय है, आईटी टीमें यह पता लगा रही हैं कि मासिक संग्रहण वास्तव में कितना महंगा हो सकता है। क्या अधिक है, वे यह समझने लगे हैं कि खराब लिखित प्रश्नों को चलाने और AWS और Azure को अपनी अनुक्रमणिका प्रबंधित करने देने से उनकी क्लाउड कंप्यूटिंग लागत बढ़ जाती है। धीमी क्वेरी और खराब इंडेक्स के लिए आपको पैसे खर्च करने पड़ते हैं।
SQL प्रदर्शन ट्यूनिंग उन सभी चीजों को ठीक करने के बारे में है। इस तरह, चाहे आप ऑन-प्रिमाइसेस OpEx की दुनिया में रहें या क्लाउड की CapEx दुनिया में माइग्रेट करें, आप अपने खर्च पर नियंत्रण बनाए रखते हैं।