बेंजामिन नेवारेज़ लॉस एंजिल्स, कैलिफ़ोर्निया में स्थित एक स्वतंत्र सलाहकार हैं जो SQL सर्वर क्वेरी ट्यूनिंग और अनुकूलन में माहिर हैं। वह "एसक्यूएल सर्वर 2014 क्वेरी ट्यूनिंग और ऑप्टिमाइज़ेशन" और "इनसाइड द एसक्यूएल सर्वर क्वेरी ऑप्टिमाइज़र" के लेखक हैं और "एसक्यूएल सर्वर 2012 इंटर्नल्स" के सह-लेखक हैं। रिलेशनल डेटाबेस में 20 से अधिक वर्षों के अनुभव के साथ, बेंजामिन कई SQL सर्वर सम्मेलनों में एक वक्ता भी रहे हैं, जिसमें PASS समिट, SQL सर्वर कनेक्शन और SQLBits शामिल हैं। बेंजामिन का ब्लॉग http://www.benjaminnevarez.com पर पाया जा सकता है और उस तक बेंजामिननेवारेज़ डॉट कॉम के एडमिन और @BenjaminNevarez पर ट्विटर पर ई-मेल द्वारा भी पहुंचा जा सकता है।
क्या आपने कभी SQL सर्वर अपग्रेड के बाद एक योजना प्रतिगमन पाया है और जानना चाहते हैं कि पिछली निष्पादन योजना क्या थी? क्या आपको इस तथ्य के कारण कभी भी कोई क्वेरी प्रदर्शन समस्या हुई है कि किसी क्वेरी को अप्रत्याशित रूप से एक नई निष्पादन योजना मिली है? पिछले पास शिखर सम्मेलन में, कॉनर कनिंघम ने एक नई SQL सर्वर सुविधा का खुलासा किया, जो निष्पादन योजनाओं में इन और अन्य परिवर्तनों से संबंधित प्रदर्शन समस्याओं को हल करने में सहायक हो सकती है।
यह सुविधा, जिसे क्वेरी स्टोर कहा जाता है, योजना परिवर्तनों से संबंधित प्रदर्शन समस्याओं में आपकी सहायता कर सकती है और जल्द ही SQL Azure और बाद में SQL सर्वर के अगले संस्करण पर उपलब्ध होगी। यद्यपि यह SQL सर्वर के एंटरप्राइज़ संस्करण पर उपलब्ध होने की उम्मीद है, यह अभी तक ज्ञात नहीं है कि यह मानक या किसी अन्य संस्करण पर उपलब्ध होगा या नहीं। क्वेरी स्टोर के लाभों को समझने के लिए, मुझे क्वेरी समस्या निवारण प्रक्रिया के बारे में संक्षेप में बात करने दें।
क्वेरी धीमी क्यों होती है?
एक बार जब आप यह पता लगा लेते हैं कि एक प्रदर्शन समस्या इसलिए है क्योंकि एक क्वेरी धीमी है, तो अगला कदम यह पता लगाना है कि क्यों। जाहिर है कि हर समस्या योजना में बदलाव से जुड़ी नहीं होती है। एक क्वेरी जो अच्छा प्रदर्शन कर रही है, अचानक धीमी होने के कई कारण हो सकते हैं। कभी-कभी यह अवरोधन या अन्य सिस्टम संसाधनों की समस्या से संबंधित हो सकता है। हो सकता है कि कुछ और बदल गया हो, लेकिन चुनौती यह पता लगाने की हो सकती है कि क्या है। कई बार हमारे पास सिस्टम संसाधन उपयोग, क्वेरी निष्पादन आंकड़े या प्रदर्शन इतिहास के बारे में आधार रेखा नहीं होती है। और आमतौर पर हमें पता नहीं होता कि पुरानी योजना क्या थी। ऐसा हो सकता है कि कुछ परिवर्तन, उदाहरण के लिए, डेटा, स्कीमा या क्वेरी पैरामीटर, ने क्वेरी प्रोसेसर को एक नई योजना तैयार की।
योजना परिवर्तन
सत्र में, कॉनर ने पिकासो डेटाबेस क्वेरी ऑप्टिमाइज़र विज़ुअलाइज़र टूल का उपयोग किया, हालांकि इसका नाम से उल्लेख नहीं किया, यह दिखाने के लिए कि एक ही क्वेरी में योजनाएं क्यों बदल गईं, और इस तथ्य को समझाया कि एक ही क्वेरी के आधार पर विभिन्न योजनाओं का चयन किया जा सकता है उनकी विधेय की चयनात्मकता। उन्होंने यह भी उल्लेख किया कि क्वेरी ऑप्टिमाइज़र टीम इस टूल का उपयोग करती है, जिसे भारतीय विज्ञान संस्थान द्वारा विकसित किया गया था। विज़ुअलाइज़ेशन का एक उदाहरण (विस्तार करने के लिए क्लिक करें):
पिकासो डेटाबेस क्वेरी ऑप्टिमाइज़र विज़ुअलाइज़र
आरेख में प्रत्येक रंग एक अलग योजना है, और प्रत्येक योजना का चयन विधेय की चयनात्मकता के आधार पर किया जाता है। एक महत्वपूर्ण तथ्य यह है कि जब ग्राफ में एक सीमा पार की जाती है और एक अलग योजना का चयन किया जाता है, तो ज्यादातर समय दोनों योजनाओं की लागत और प्रदर्शन समान होना चाहिए, क्योंकि चयनात्मकता या पंक्तियों की अनुमानित संख्या में केवल थोड़ा बदलाव होता है। यह उदाहरण के लिए हो सकता है जब एक तालिका में एक नई पंक्ति जोड़ी जाती है जो प्रयुक्त विधेय के लिए योग्य होती है। हालांकि, कुछ मामलों में, ज्यादातर क्वेरी ऑप्टिमाइज़र लागत मॉडल में सीमाओं के कारण, जिसमें यह कुछ सही ढंग से मॉडल करने में सक्षम नहीं है, नई योजना में पिछले एक की तुलना में एक बड़ा प्रदर्शन अंतर हो सकता है, जो आपके आवेदन के लिए एक समस्या पैदा कर सकता है। वैसे, आरेख पर दिखाए गए प्लान क्वेरी ऑप्टिमाइज़र द्वारा चुनी गई अंतिम योजना हैं, इसे उन कई विकल्पों के साथ भ्रमित न करें जिन्हें ऑप्टिमाइज़र को केवल एक का चयन करने पर विचार करना होगा।
एक महत्वपूर्ण तथ्य, मेरी राय में, जिसे कॉनर ने सीधे तौर पर कवर नहीं किया था, वह था संचयी अपडेट (सीयू), सर्विस पैक या संस्करण अपग्रेड में बदलाव के बाद प्रतिगमन के कारण योजनाओं में बदलाव। एक प्रमुख चिंता जो क्वेरी ऑप्टिमाइज़र के अंदर परिवर्तनों के साथ दिमाग में आती है वह है योजना प्रतिगमन। क्वेरी ऑप्टिमाइज़र सुधारों के लिए योजना प्रतिगमन के डर को सबसे बड़ी बाधा माना गया है। रिग्रेशन समस्याएँ हैं जो क्वेरी ऑप्टिमाइज़र पर एक फ़िक्स लागू होने के बाद शुरू की जाती हैं, और कभी-कभी क्लासिक के रूप में संदर्भित होती हैं "दो या दो से अधिक गलतियाँ सही होती हैं।" यह तब हो सकता है, उदाहरण के लिए, दो खराब अनुमान, एक मूल्य को अधिक आंकना और दूसरा इसे कम करके आंकना, एक दूसरे को रद्द करना, सौभाग्य से एक अच्छा अनुमान देना। इनमें से केवल एक मान को ठीक करने से अब एक खराब अनुमान हो सकता है जो योजना चयन की पसंद को नकारात्मक रूप से प्रभावित कर सकता है, जिससे एक प्रतिगमन हो सकता है।
क्वेरी स्टोर क्या करता है?
कॉनर ने उल्लेख किया कि क्वेरी स्टोर प्रदर्शन करता है और निम्नलिखित के साथ मदद कर सकता है:
- क्वेरी प्लान के इतिहास को सिस्टम में स्टोर करें;
- समय के साथ प्रत्येक क्वेरी योजना के प्रदर्शन को कैप्चर करें;
- उन क्वेरी की पहचान करें जो "हाल ही में धीमी हो गई हैं";
- आपको योजनाओं को शीघ्रता से लागू करने की अनुमति देता है; और,
- सुनिश्चित करें कि यह सर्वर रीस्टार्ट, अपग्रेड और क्वेरी रीकंपाइल पर काम करता है।
इसलिए यह सुविधा न केवल योजनाओं और संबंधित क्वेरी प्रदर्शन जानकारी को संग्रहीत करती है, बल्कि पुरानी क्वेरी योजना को आसानी से लागू करने में भी आपकी मदद कर सकती है, जो कई मामलों में प्रदर्शन समस्या को हल कर सकती है।
क्वेरी स्टोर का उपयोग कैसे करें
आपको ALTER DATABASE CURRENT SET QUERY_STORE = ON; का उपयोग करके क्वेरी स्टोर को सक्षम करने की आवश्यकता है। बयान। मैंने इसे अपनी वर्तमान SQL Azure सदस्यता में आज़माया, लेकिन कथन ने एक त्रुटि लौटा दी क्योंकि ऐसा लगता है कि यह सुविधा अभी तक उपलब्ध नहीं है। मैंने कॉनर से संपर्क किया और उन्होंने मुझे बताया कि यह सुविधा जल्द ही उपलब्ध होगी।
एक बार क्वेरी स्टोर सक्षम हो जाने पर, यह योजनाओं और क्वेरी प्रदर्शन डेटा को एकत्रित करना शुरू कर देगा और आप क्वेरी स्टोर तालिकाओं को देखकर उस डेटा का विश्लेषण कर सकते हैं। मैं वर्तमान में SQL Azure पर उन तालिकाओं को देख सकता हूं, लेकिन चूंकि मैं क्वेरी स्टोर को सक्षम करने में सक्षम नहीं था, इसलिए कैटलॉग ने कोई डेटा नहीं लौटाया।
आप एकत्र की गई जानकारी का विश्लेषण या तो अपने आवेदन में क्वेरी प्रदर्शन परिवर्तनों को समझने के लिए कर सकते हैं, या यदि आपको कोई प्रदर्शन समस्या है तो पूर्वव्यापी रूप से विश्लेषण कर सकते हैं। एक बार जब आप समस्या की पहचान कर लेते हैं तो आप समस्या को ठीक करने के लिए पारंपरिक क्वेरी ट्यूनिंग तकनीकों का उपयोग कर सकते हैं, या आप sp_query_store_force_plan का उपयोग कर सकते हैं पिछली योजना को लागू करने के लिए संग्रहीत प्रक्रिया। योजना को मजबूर करने के लिए क्वेरी स्टोर में कैप्चर किया जाना है, जिसका स्पष्ट रूप से अर्थ है कि यह एक वैध योजना है (कम से कम जब इसे एकत्र किया गया था; उस पर और बाद में) और इसे पहले क्वेरी ऑप्टिमाइज़र द्वारा उत्पन्न किया गया था। किसी योजना को लागू करने के लिए आपको plan_id . की आवश्यकता होगी , sys.query_store_plan . में उपलब्ध है सूची एक बार जब आप स्टोर किए गए विभिन्न मेट्रिक को देखते हैं, जो बहुत हद तक उसी तरह के होते हैं जैसे कि sys.dm_exec_query_stats में स्टोर किया जाता है। , आप सीपीयू, आई/ओ इत्यादि जैसे विशिष्ट मीट्रिक के लिए अनुकूलित करने का निर्णय ले सकते हैं। फिर आप बस इस तरह के एक कथन का उपयोग कर सकते हैं:
EXEC sys.sp_query_store_force_plan @query_id = 1, @plan_id = 1;
यह SQL सर्वर को क्वेरी 1 पर योजना 1 को बाध्य करने के लिए कह रहा है। तकनीकी रूप से आप एक योजना मार्गदर्शिका का उपयोग करके वही काम कर सकते हैं, लेकिन यह अधिक जटिल होगा और आपको पहले स्थान पर आवश्यक योजना को मैन्युअल रूप से एकत्रित और ढूंढना होगा।
क्वेरी स्टोर कैसे काम करता है?
वास्तव में किसी योजना को बाध्य करने के लिए पृष्ठभूमि में योजना मार्गदर्शिकाओं का उपयोग किया जाता है। कॉनर ने उल्लेख किया कि "जब आप एक प्रश्न संकलित करते हैं, तो हम उस कथन से जुड़े XML योजना के टुकड़े के साथ एक USE PLAN संकेत जोड़ते हैं।" इसलिए अब आपको किसी योजना मार्गदर्शिका का उपयोग करने की आवश्यकता नहीं है। यह भी ध्यान रखें कि, योजना गाइड का उपयोग करने के समान, यह गारंटी नहीं है कि वास्तव में मजबूर योजना है लेकिन कम से कम इसके समान कुछ है। योजना मार्गदर्शिकाएँ कैसे काम करती हैं, इसकी याद दिलाने के लिए इस लेख पर एक नज़र डालें। इसके अलावा, आपको इस बात की जानकारी होनी चाहिए कि कुछ ऐसे मामले हैं जहां किसी योजना को बाध्य करना काम नहीं करता है, एक विशिष्ट उदाहरण है जब स्कीमा बदल गया है, अर्थात यदि कोई संग्रहीत योजना किसी अनुक्रमणिका का उपयोग करती है लेकिन अनुक्रमणिका अब मौजूद नहीं है। इस स्थिति में SQL सर्वर योजना को बाध्य नहीं कर सकता, एक सामान्य अनुकूलन करेगा और यह इस तथ्य को रिकॉर्ड करेगा कि जबरन योजना संचालन sys.query_store_plan में विफल रहा। कैटलॉग।
वास्तुकला
हर बार जब SQL सर्वर किसी क्वेरी को संकलित या निष्पादित करता है, तो क्वेरी स्टोर को एक संदेश भेजा जाता है। यह आगे दिखाया गया है।
क्वेरी स्टोर वर्कफ़्लो ओवरव्यू
संकलन और निष्पादन जानकारी को पहले मेमोरी में रखा जाता है और फिर डिस्क पर सहेजा जाता है, जो क्वेरी स्टोर कॉन्फ़िगरेशन पर निर्भर करता है (डेटा INTERVAL_LENGTH_MINUTES के अनुसार एकत्रित किया जाता है) पैरामीटर, जो डिफ़ॉल्ट रूप से एक घंटे तक रहता है, और DATA_FLUSH_INTERVAL_SECONDS के अनुसार डिस्क पर फ़्लश हो जाता है पैरामीटर)। सिस्टम पर मेमोरी प्रेशर होने पर डेटा को डिस्क पर भी फ्लश किया जा सकता है। किसी भी स्थिति में, जब आप sys.query_store_runtime_stats चलाते हैं, तो आप मेमोरी और डिस्क दोनों में सभी डेटा तक पहुंचने में सक्षम होंगे। कैटलॉग।
कैटलॉग
एकत्रित डेटा डिस्क पर बना रहता है और उपयोगकर्ता डेटाबेस में संग्रहीत होता है जहां क्वेरी स्टोर सक्षम होता है (और सेटिंग्स sys.database_query_store_options में संग्रहीत होती हैं। . क्वेरी स्टोर कैटलॉग हैं:
sys.query_store_query_text | क्वेरी टेक्स्ट जानकारी |
sys.query_store_query | क्वेरी टेक्स्ट और SET विकल्पों को प्रभावित करने वाली उपयोग की गई योजना |
sys.query_store_plan | इतिहास सहित निष्पादन योजनाएं |
sys.query_store_runtime_stats | क्वेरी रनटाइम आँकड़े |
sys.query_store_runtime_stats_interval | अंतराल के लिए प्रारंभ और समाप्ति समय |
sys.query_context_settings | क्वेरी प्रसंग सेटिंग जानकारी |
क्वेरी स्टोर दृश्य
रनटाइम आँकड़े औसत, अंतिम, न्यूनतम, अधिकतम और मानक विचलन सहित कई मीट्रिक को कैप्चर करते हैं। यहां sys.query_store_runtime_stats . के लिए कॉलम का पूरा सेट दिया गया है :
runtime_stats_id | plan_id | runtime_stats_interval_id | ||
execution_type | execution_type_desc | first_execution_time | last_execution_time | count_executions |
avg_duration | last_duration | min_duration | max_duration | stdev_duration |
avg_cpu_time | last_cpu_time | min_cpu_time | max_cpu_time | stdev_cpu_time |
avg_logical_io_reads | last_logical_io_reads | min_logical_io_reads | max_logical_io_reads | stdev_logical_io_reads |
avg_logical_io_writes | last_logical_io_writes | min_logical_io_writes | max_logical_io_writes | stdev_logical_io_writes |
avg_physical_io_reads | last_physical_io_reads | min_physical_io_reads | max_physical_io_reads | stdev_physical_io_reads |
avg_clr_time | last_clr_time | min_clr_time | max_clr_time | stdev_clr_time |
avg_dop | last_dop | min_dop | max_dop | stdev_dop |
avg_query_max_used_memory | last_query_max_used_memory | min_query_max_used_memory | max_query_max_used_memory | stdev_query_max_used_memory |
avg_rowcount | last_rowcount | min_rowcount | max_rowcount | stdev_rowcount |
sys.query_store_runtime_stats में कॉलम
क्वेरी निष्पादन समाप्त होने पर ही यह डेटा कैप्चर किया जाता है। क्वेरी स्टोर क्वेरी के SET . पर भी विचार करता है विकल्प, जो एक निष्पादन योजना की पसंद को प्रभावित कर सकते हैं, क्योंकि वे अनुकूलन प्रक्रिया के दौरान निरंतर अभिव्यक्तियों के मूल्यांकन के परिणामों जैसी चीजों को प्रभावित करते हैं। मैंने इस विषय को पिछली पोस्ट में कवर किया है।
निष्कर्ष
यह निश्चित रूप से एक महान विशेषता होगी और कुछ ऐसा जो मैं जल्द से जल्द कोशिश करना चाहता हूं (वैसे, कॉनर का डेमो "एसक्यूएल सर्वर 15 सीटीपी 1" दिखाता है लेकिन वे बिट्स सार्वजनिक रूप से उपलब्ध नहीं हैं)। क्वेरी स्टोर अपग्रेड के लिए उपयोगी हो सकता है जो एक सीयू, सर्विस पैक, या SQL सर्वर संस्करण हो सकता है, क्योंकि आप क्वेरी स्टोर द्वारा एकत्र की गई जानकारी का विश्लेषण पहले और बाद में कर सकते हैं यह देखने के लिए कि क्या कोई क्वेरी वापस आ गई है। (और यदि सुविधा निचले संस्करणों में उपलब्ध है, तो आप इसे SKU अपग्रेड परिदृश्य में भी कर सकते हैं।) यह जानने से आपको समस्या के आधार पर कुछ विशिष्ट कार्रवाई करने में मदद मिल सकती है, और उन समाधानों में से एक पिछली योजना को लागू करना हो सकता है। जैसा कि पहले बताया गया है।
