आप निष्पादन योजनाओं को कैसे पढ़ते हैं? दाएं से बाएं, बाएं से दाएं, या लागतों की जांच करके? या इंडेक्स स्कैन, टेबल स्कैन और लुकअप जैसी वस्तुओं के बारे में क्या? यह ब्लॉग चर्चा करता है कि Microsoft® SQL सर्वर निष्पादन योजना को कैसे पढ़ा जाए।
परिचय
हालाँकि SQL सर्वर आमतौर पर एक अच्छी योजना बनाता है, कभी-कभी यह अपनी योजनाओं को मान्य करने और खराब योजनाओं को ठीक करने के लिए पर्याप्त स्मार्ट नहीं होता है।
आप एक अनुमानित निष्पादन योजना और SQL सर्वर में एक वास्तविक ग्राफिकल निष्पादन योजना प्राप्त कर सकते हैं। ctrl M . आदेश का उपयोग करके इन योजनाओं को उत्पन्न करें या ctrl एल या चिह्नों का उपयोग करके, जो SQL सर्वर प्रबंधन स्टूडियो (SSMS) के मानक उपकरण पट्टी पर निष्पादन चिह्न के दाईं ओर रखे जाते हैं। SQL सर्वर में अन्य प्रकार की योजनाएँ हैं, लेकिन वे योजनाएँ इस पोस्ट में शामिल नहीं हैं।
अनुमानित और वास्तविक निष्पादन योजनाएं
निष्पादन योजनाएँ दो प्रकार की होती हैं:
-
अनुमानित निष्पादन योजना :अनुमानित योजनाएं डेटा प्राप्त करने के लिए SQL सर्वर द्वारा किए जाने वाले कार्य का अनुमान प्रदान करती हैं।
-
वास्तविक निष्पादन योजना :ट्रांजैक्ट-एसक्यूएल प्रश्नों या बैचों को निष्पादित करने के बाद वास्तविक निष्पादन योजनाएं उत्पन्न होती हैं। इस वजह से, एक वास्तविक निष्पादन योजना में रनटाइम जानकारी होती है, जैसे कि वास्तविक संसाधन उपयोग मीट्रिक और कोई भी रनटाइम चेतावनी।
डेटा प्रोसेसिंग
क्या आपने कभी एक ही प्रश्न के लिए अनुमानित योजना और वास्तविक योजना के बीच अंतर देखा है? अधिकांश समय ऐसा ही रहेगा, लेकिन आंकड़ों में बदलाव, स्कीमा से संबंधित परिवर्तनों या डेटा में बदलाव के कारण यह भिन्न हो सकता है। समस्या निवारण करते समय आपको हमेशा वास्तविक निष्पादन योजना की जांच करनी चाहिए।
वास्तविक बिंदु की पहचान करने के लिए निष्पादन योजना को सही ढंग से पढ़ें। लागत के बजाय डेटा प्रवाह को देखकर प्रारंभ करें। तार्किक या भौतिक पढ़ने के बारे में मत सोचो। इनपुट/आउटपुट (I/O) संचालन की संख्या को कम करना महत्वपूर्ण है। एक डेटाबेस व्यवस्थापक (डीबीए) के रूप में, आप जानते हैं कि भंडारण तक पहुंच हार्डवेयर संसाधनों में सबसे धीमी है, इसलिए आपको उस गतिविधि को कम करने का प्रयास करना चाहिए। तो आप आँकड़ों का पता कैसे लगाते हैं, और क्या निष्पादन योजना इसे दिखाती है? हाँ, यह करता है! दाएँ-से-बाएँ संकेतक पर माउस मँडरा कर दिशा रेखाएँ देखें। यह रिकॉर्ड की संख्या और डेटा आकार प्रदर्शित करता है। ऑपरेशन द्वारा लौटाए गए डेटा वॉल्यूम के आधार पर प्रत्येक पंक्ति अधिक मोटी या पतली होती है, जैसा कि निम्नलिखित चित्रण द्वारा दिखाया गया है:
यदि आपके पास कई ऑब्जेक्ट हैं, तो आपको प्रत्येक ऑपरेशन द्वारा संसाधित किए गए डेटा की मात्रा का अवलोकन प्राप्त करने के लिए एक बेहतर तरीके की आवश्यकता है। SentryOne Plan Explorer को डाउनलोड करें और एक आसान तरीके से एक सिंहावलोकन प्राप्त करने के लिए इस टूल का उपयोग करके योजना देखें।
अपने सिस्टम पर SentryOne को डाउनलोड और कॉन्फ़िगर करने के बाद, इसके साथ निष्पादन योजना खोलें। SentryOne के कई विचार और विवरण हैं, जिनका आप अपनी आवश्यकता के अनुसार उपयोग कर सकते हैं। डेटा प्रोसेसिंग दृश्य प्राप्त करने के लिए, Data size in MB . का चयन करके दृश्य बदलें विकल्प जैसा कि निम्न छवि में दिखाया गया है। आपका लक्ष्य समग्र डेटा प्रोसेसिंग को कम करने का अवसर खोजना है।
यदि आपको I/O तनाव को कम करने की आवश्यकता है, तो आप SET STATISTICS IO ON देख सकते हैं क्वेरी के लिए I/O उपयोग का समग्र विचार प्राप्त करने के लिए T-SQL मान। संदेश पर परिणाम स्विच देखने के लिए आपको SSMS में क्वेरी निष्पादन से पहले इसे सेट करना चाहिए परिणाम . में टैब पैनल। यह निम्न परिणाम के समान दिखना चाहिए:
(356 row(s) affected)
Table 'Table3'. Scan count 1, logical reads 5, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0,
lob read-ahead reads 0.
तार्किक 5 पढ़ता है परिणाम से पता चलता है कि SQL सर्वर मेमोरी से डेटा प्राप्त करने के लिए 40 KB (5 * 8 KB) पेज पढ़ता है। क्वेरी को ऑप्टिमाइज़ करते समय, लॉजिकल रीड्स को नज़रअंदाज़ न करें क्योंकि यह लाइव सर्वर पर फिजिकल और लॉजिकल हो सकता है। आप कभी नहीं जान पाएंगे कि जिन पेजों का आप जिक्र कर रहे हैं वे मेमोरी पर हैं या डिस्क पर। लक्ष्य संचयी रीड ऑपरेशंस की संख्या को कम करना होना चाहिए।
अनुमानित बनाम वास्तविक योजनाएं
वास्तविक योजना तैयार होने के बाद, निष्पादन योजना में किसी भी ऑपरेशन ऑर्लॉजिकल यूनिट पर अपने माउस को घुमाएं। क्लस्टर इंडेक्स सीक या स्कैन जैसे भौतिक संचालन के प्रकार देखने के लिए निम्न छवि देखें परिणाम। निष्पादन की संख्या और पंक्तियों की वास्तविक और अनुमानित संख्या देखें। व्यक्तिगत संचालन की लागत को देखने से बचें क्योंकि यह पुराने हार्डवेयर के आधार पर सेकंड में एक अनुमान है और सटीक विवरण प्रदान नहीं कर सकता है। निम्न छवि में, संकुल अनुक्रमणिका खोज ऑपरेटर ने 100 रिकॉर्ड प्राप्त करने के लिए एक बार निष्पादित किया, और SQL 356 रिकॉर्ड का अनुमान लगाता है। अंतर पुराने आंकड़ों या क्वेरी प्रदर्शन के कारण हो सकता है।
निष्पादन पुनरावृत्तियां
निम्न छवि से पता चलता है कि निष्पादन की अनुमानित संख्या एक रिकॉर्ड प्राप्त करने के लिए क्लस्टर इंडेक्स पर 1154121 गुना है। यह महत्वपूर्ण है। भले ही ऑपरेटर की लागत कम हो, और हम इसे आसानी से अनदेखा कर सकते थे, इसके बजाय उच्च लागत वाले अन्य कार्यों को देखते हुए, यह एक महंगा विकल्प साबित हो सकता था। क्लस्टर इंडेक्स होने के बावजूद इस तरह के ऑपरेशन का क्वेरी प्रदर्शन पर उच्च प्रभाव पड़ता है। पंक्ति आईडी (RID) लुकअप हीप के लिए एक समान ऑपरेशन है।
अस्थायी डेटाबेस
रिकॉर्ड की अनुमानित और वास्तविक संख्या के बीच का अंतर कुछ और है जिस पर आपको विचार करना चाहिए। एक गलत अनुमान के परिणामस्वरूप सीमित मेमोरी आवंटित की गई क्वेरी हो सकती है। जब ऐसा होता है, तो यह काम पूरा करने के लिए एक अस्थायी डेटाबेस (tempdb) का उपयोग करता है। SQL सर्वर द्वारा किसी ऑपरेटर या योजना के गलत चुनाव के परिणामस्वरूप धीमी गति से संचालन और प्रश्नों का निष्कर्षण हो सकता है, जैसा कि निम्न छवि में दिखाया गया है। अभिलेखों की वास्तविक संख्या समान है, लेकिन अनुमान भिन्न हैं। यह पुराने या अनुपलब्ध आँकड़ों के कारण हो सकता है। ध्यान दें कि टेबलवेरिएबल में कोई आंकड़े नहीं होते हैं, इसलिए योजना हमेशा नई रिलीज में 1 और 1K लौटाती है जब तक कि पुन:संकलित करने के विकल्प का उपयोग नहीं किया जाता है। इस प्रकार, बड़ी संख्या में रिकॉर्ड के लिए तालिका चर एक अच्छा विकल्प नहीं हैं।
सॉर्ट ऑपरेटर
आपको छँटाई के प्रभाव पर विचार करने की आवश्यकता है। सॉर्ट ऑपरेटर का उपयोग ज्यादातर निम्नलिखित कार्यों के लिए किया जाता है:एग्रीगेट, मर्ज जॉइन, या ऑर्डर बाय क्लॉज। हो सकता है कि इसका प्रभाव केवल कुछ रिकॉर्ड के साथ न हो, लेकिन, प्रत्येक अतिरिक्त रिकॉर्ड के साथ, संसाधन धीमा हो जाता है। छँटाई से बचने की कोशिश करें या खंड द्वारा आदेश का उपयोग न करें। यदि सॉर्टिंग आवश्यक है, तो एप्लिकेशन को सॉर्ट किए गए डेटा भेजने के बजाय सॉर्ट करने के लिए एप्लिकेशन ग्रिड का उपयोग करें।
निम्न छवि सॉर्ट लागत दिखाती है:
स्पूल ऑपरेटर
एक अन्य प्रमुख ऑपरेटर जिसे आपको देखने की आवश्यकता है वह है स्पूल। स्पूल एक स्लोऑपरेटर है क्योंकि यह छिपी या अस्थायी वस्तुओं या कार्य तालिकाओं को इंटेम्पडब में संग्रहीत करता है। यह विशिष्ट ऑपरेटरों के साथ भी धीमा हो जाता है जो इसे रिबाइंडर रिवाइंड करने का कारण बनता है। SQL सर्वर में कई प्रकार के स्पूल होते हैं, जैसे Eager, Lazy, Table/Index इत्यादि। SQL सर्वर स्पूल का उपयोग करता है जब इंटरमीडिएट परिणाम सेट के लिए स्रोत तालिका पर वापस जाने के बजाय एटेम्प कार्य तालिका को संदर्भित करना बेहतर होता है। निम्न छवि एक उदाहरण दिखाती है:
स्पूल के साथ, रिबाइंड और रिवाइंड की संख्या पर ध्यान देना महत्वपूर्ण है। रिवाइंडिस रिबाइंड की तुलना में महंगा है। उदाहरण के लिए, निम्न छवि में, ऑपरेटर 2674 रिवाइंड दिखाता है, जिसका अर्थ है कि डेटा प्राप्त करने के लिए क्वेरी को 2674 बार फिर से निष्पादित किया जाता है। यह प्रत्येक ऑपरेटर को टेबल स्पूल से टेबल स्कैन में प्रत्येक रिकॉर्डिन रिवाइंड प्राप्त करने के लिए देता है। रिबाइंड का मतलब है कि इसे स्पूल से डेटा मिला और टेबल स्कैन के लिए वापस नहीं आया।
हैश और नेस्टेड लूप ऑपरेटर
क्योंकि वे छोटे रिकॉर्ड सेट पर अच्छा प्रदर्शन करते हैं, हैश और नेस्टेड लूप अगले ऑपरेटर हैं जिन पर आपको विचार करना चाहिए। हालांकि, बड़े रिकॉर्ड सेट के लिए, या जब अनुमानित और वास्तविक योजनाओं के बीच एक बड़ा अंतर होता है, तो ये ऑपरेटर एक बड़ा प्रभाव पैदा कर सकते हैं क्योंकि वे मेमोरी के बजाय टेम्पर्डब का उपयोग कर सकते हैं। SQL सर्वर ऑपरेटर विवरण में निम्नलिखित चेतावनी पोस्ट करता है:"निष्पादन के दौरान डेटा फैलाने के लिए आपरेटरयुक्त tempdb"। अगर ऐसा होता है तो आँकड़ों पर ध्यान दें। गलत अनुमान के साथ, स्मृति आवंटन पर लूप कम हो जाता है या यह पुनरावृत्त रहता है। निष्पादन के लिए आवंटित स्मृति को देखें। स्मृति आवंटन देखने के लिए, निष्पादन योजना के प्रारंभ बिंदु (बाएं से दाएं) का चयन करके संपत्ति बॉक्स खोलें। अगर कुछ भी असामान्य नहीं है, तो क्वेरी ट्यूनिंग आदर्श विकल्प होना चाहिए।
निष्कर्ष
किसी क्वेरी को अनुकूलित करने के लिए आपका पहला लक्ष्य समग्र पठन और लेखन (अर्थात डिस्क पर I/O) को कम करना होना चाहिए। मेमोरी में पढ़ने और लिखने के लिए तार्किक पढ़ना न भूलें। I/O को कम करने से अधिकांश समस्या का समाधान हो जाता है और क्वेरी बहुत तेज़ी से चलती हैं।
इसके बाद, अन्य कार्यों को देखें जो गतिविधि ontempdb के कारण महंगे हैं। याद रखें, tempdb का उपयोग कई कार्यों के लिए किया जाता है और यह हमेशा महंगा होता है। रिवाइंड की तलाश करें - किसी भी ऑपरेशन, स्पूल, सॉर्टिंग और लूप के निष्पादन की संख्या।
Tempdb के साथ उपयोग किए जाने पर ये महंगे होते हैं। प्रत्येक ऑपरेटर पर चेतावनियों की समीक्षा करना न भूलें क्योंकि वे अच्छे सुराग प्रदान करते हैं। हालांकि यह पोस्ट लापता इंडेक्स ऑपरेटर पर चर्चा नहीं करता है, इसका मतलब यह नहीं है कि आप इसे अनदेखा कर सकते हैं।
इसकी समीक्षा करें, लेकिन आँख बंद करके इंडेक्स न बनाएं। समान कॉलम पर उपलब्ध अन्य इंडेक्स की जांच करें, और अपने डेटाबेस में चल रही क्वेरी पर प्रभाव पर विचार करें।
कोई टिप्पणी करने या प्रश्न पूछने के लिए प्रतिक्रिया टैब का उपयोग करें। आप हमारे साथ बातचीत भी शुरू कर सकते हैं।