SQL सर्वर में स्वचालित योजना सुधार

डेटाबेस व्यवस्थापक या डेवलपर के रूप में आप प्रदर्शन समस्याओं के निवारण में कितना समय लगाते हैं? क्या आपने कभी इसे ट्रैक किया है? आपके दिन के औसत कुल प्रतिशत के रूप में, यह बहुत अधिक समय नहीं लग सकता है, लेकिन जब समस्या गंभीर होती है, तो आप इसे ट्रैक करने और मूल कारण विश्लेषण के माध्यम से काम करने में घंटों बिता सकते हैं। कभी-कभी समस्या दूर हो जाती है और आपको वास्तविक उत्पत्ति का पता नहीं चलता है। और भी बुरा? जब आपको आधी रात या सप्ताहांत में इन मुद्दों से जूझना पड़े। आप न केवल किसी समस्या को हल करने के लिए हाथ-पांव मार रहे हैं, बल्कि आप अपना निजी खाली समय भी गंवा रहे हैं। हम इसे कैसे कम करते हैं? हम समीकरण से अपना समय और प्रयास कैसे निकालते हैं, और एक ही समय में प्रदर्शन को कैसे ठीक करते हैं?

SQL सर्वर 2017 एंटरप्राइज़ संस्करण और Azure SQL डेटाबेस में स्वचालित ट्यूनिंग सुविधा डेटा पेशेवरों द्वारा समस्या निवारण और प्रदर्शन समस्याओं को हल करने में लगने वाले समय को कम करने की दिशा में पहला कदम है। इस सुविधा में स्वचालित योजना सुधार और स्वचालित अनुक्रमणिका प्रबंधन (केवल Azure SQL डेटाबेस में उपलब्ध) शामिल हैं, जो स्वतंत्र रूप से सक्षम हैं। इस पोस्ट में मैं स्वचालित योजना सुधार सुविधा पर ध्यान केंद्रित करना चाहता हूं। स्वचालित योजना सुधार के साथ, यदि SQL सर्वर को पता चलता है कि कोई क्वेरी महत्वपूर्ण रूप से वापस आ गई है, तो यह क्वेरी के लिए अंतिम ज्ञात अच्छी योजना को प्रदर्शन को स्थिर करने के लिए बाध्य करेगा। अनिवार्य रूप से, आपके बजाय, डीबीए या डेवलपर, सिस्टम प्रदर्शन के बारे में सप्ताहांत पर बुलाए जाने पर, SQL सर्वर इसे आपके लिए संबोधित करेगा। बहुत आसान लगता है, है ना? आइए एक नज़र डालते हैं।

अंडर द कवर्स

सबसे पहले, यह समझना आवश्यक है कि स्वचालित योजना सुधार क्वेरी स्टोर का उपयोग करता है, इसलिए इसे डेटाबेस के लिए सक्षम होना चाहिए। दूसरा, स्वचालित योजना सुधार केवल स्वचालित योजना बल है। जबकि क्वेरी स्टोर आपके डेटाबेस के लिए उड़ान-रिकॉर्डर के रूप में विपणन किया जाता है जो क्वेरी टेक्स्ट, योजनाओं, रनटाइम आंकड़ों और प्रतीक्षा आंकड़ों को ट्रैक करता है, यह आपको लगातार प्रदर्शन की अनुमति देने के लिए एक क्वेरी के लिए योजना को मजबूर करने की अनुमति देता है। स्वचालित योजना सुधार आपके हस्तक्षेप के बिना जबरदस्ती योजना है।

स्वचालित योजना सुधार सक्षम करना

जैसा कि उल्लेख किया गया है, क्वेरी स्टोर पहले उपयोगकर्ता डेटाबेस के लिए सक्षम होना चाहिए। यह एसएसएमएस में, टी-एसक्यूएल के साथ, और एज़ूर एसक्यूएल डीबी के लिए आरईएसटी एपीआई के साथ किया जा सकता है। ध्यान दें कि क्वेरी स्टोर Azure में डेटाबेस के लिए डिफ़ॉल्ट रूप से सक्षम है, और 2016 की चौथी तिमाही से है।

SSMS के माध्यम से क्वेरी स्टोर को सक्षम करना

USE [master];
GO
ALTER DATABASE [WideWorldImporters] 
	SET QUERY_STORE = ON;
GO
ALTER DATABASE [WideWorldImporters] 
	SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

T-SQL का उपयोग करके क्वेरी स्टोर को सक्षम करना

यदि आप इसे स्क्रिप्ट करते हैं तो उपरोक्त कोड एसएसएमएस से डिफ़ॉल्ट टी-एसक्यूएल है। Azure SQL डेटाबेस में आप USE स्टेटमेंट नहीं चलाते हैं। यदि आप किसी भी डिफ़ॉल्ट विकल्प को बदलना चाहते हैं, तो कृपया मेरी क्वेरी स्टोर सेटिंग्स पोस्ट पढ़ें कि वे विकल्प क्या हैं और वैकल्पिक मूल्यों के लिए विचार क्या हैं।

एक बार क्वेरी स्टोर सक्षम हो जाने पर, आप Azure SQL डेटाबेस में स्वचालित योजना सुधार को सक्षम करने के लिए Azure पोर्टल, T-SQL, या EST API का उपयोग कर सकते हैं ((और C# और PowerShell काम कर रहे हैं)। इसे केवल T-SQL के साथ सक्षम किया जा सकता है SQL सर्वर 2017 में।

Azure पोर्टल में स्वचालित योजना सुधार सक्षम करना

ALTER DATABASE [WideWorldImporters] 
	SET AUTOMATIC_TUNING (
		FORCE_LAST_GOOD_PLAN = ON
	);
GO

टी-एसक्यूएल में स्वचालित योजना सुधार सक्षम करना

ध्यान दें कि निकट भविष्य में Azure में नए डेटाबेस के लिए स्वचालित योजना सुधार डिफ़ॉल्ट रूप से सक्षम हो जाएगा। जनवरी 2018 से, Azure SQL डेटाबेस के लिए स्वचालित ट्यूनिंग सक्षम की जा रही है, जिसमें पहले से ही इसे सक्षम नहीं किया गया है, व्यवस्थापकों को सूचनाएं भेजी गई हैं ताकि विकल्प को वांछित होने पर अक्षम किया जा सके।

यह कैसे काम करता है

स्वचालित योजना सुधार सक्षम होने के साथ, SQL सर्वर क्वेरी स्टोर डेटा का उपयोग करके क्वेरी प्रदर्शन की निगरानी करता है। यह 48 घंटे की विंडो *** के साथ CPU** प्रदर्शन में एक महत्वपूर्ण बदलाव* की तलाश में है। उस वाक्य में तारांकन पर ध्यान दें... वे उद्देश्य पर हैं:

• *महत्वपूर्ण परिवर्तन की सीमा का दस्तावेजीकरण नहीं किया गया है क्योंकि Microsoft इसे बदलने का अधिकार सुरक्षित रखता है।
• **प्रदर्शन में परिवर्तन (CPU) को निर्धारित करने के लिए प्रयुक्त मीट्रिक का दस्तावेजीकरण नहीं किया गया है क्योंकि Microsoft इसे बदलने का अधिकार सुरक्षित रखता है। मतलब, माइक्रोसॉफ्ट प्रदर्शन को देखने के लिए अतिरिक्त आयामों पर विचार कर सकता है यदि वह अकेले सीपीयू से बेहतर/बेहतर प्रदर्शन करेगा।
• *** जिस समयावधि के दौरान क्वेरी प्रदर्शन डेटा की तुलना की जाती है, उसी कारण से प्रलेखित नहीं किया जाता है, Microsoft इसे बदलने का अधिकार सुरक्षित रखता है।
• ध्यान दें:जबकि उपरोक्त मदों का दस्तावेजीकरण नहीं किया गया है, मैंने माइक्रोसॉफ्ट में उपयुक्त व्यक्तियों के साथ पुष्टि की है कि यह जानकारी किसी भी एनडीए को तोड़ने के साथ साझा की जा सकती है। यह समझना अत्यंत महत्वपूर्ण है कि मान निश्चित नहीं हैं और बदल सकते हैं, इस उम्मीद के साथ कि वे सुविधा की विश्वसनीयता में सुधार करने के लिए बदलेंगे।

दस्तावेज़ीकरण की कमी और सीमा में बदलाव की संभावना कुछ व्यक्तियों के लिए निराशाजनक हो सकती है, लेकिन यहाँ यह याद रखना महत्वपूर्ण है:

Microsoft प्रतिदिन SQL Azure डेटाबेस से ऑपरेशनल टेलीमेट्री डेटा के टेराबाइट्स को कैप्चर करता है, और यह डेटा विकसित की जा रही स्वचालित सुविधाओं के लिए महत्वपूर्ण है। इस डेटा में query_id, query_plan_id, और query_hash जैसी चीज़ें शामिल हैं, और Microsoft query_text या query_plan को कैप्चर नहीं करता (वे आपके वास्तविक डेटा को नहीं देख रहे हैं)। Microsoft केवल उस परिचालन टेलीमेट्री को संग्रहीत नहीं कर रहा है या समस्या निवारण के लिए इसका उपयोग कर रहा है, वे उस डेटा का खनन कर रहे हैं और इसका उपयोग एल्गोरिदम और मॉडल विकसित करने के लिए कर रहे हैं ताकि SQL सर्वर को स्वतंत्र, बुद्धिमान निर्णय लेने की अनुमति मिल सके।

SQL सर्वर क्वेरी स्टोर में डेटा की अधिकता का लाभ उठा सकता है जो प्रश्नों के प्रदर्शन का विवरण देता है, और स्वचालित योजना सुधार एक क्वेरी के लिए वर्तमान प्रदर्शन की तुलना पिछले प्रदर्शन के विरुद्ध यह निर्धारित करने के लिए शुरू होता है कि प्रदर्शन में कोई प्रतिगमन है या नहीं। क्या प्रदर्शन कम हो गया है, या खराब हो गया है, और यदि हां, तो क्या यह एक महत्वपूर्ण राशि से है?

यदि क्वेरी प्रदर्शन में कोई प्रतिगमन रहा है, तो SQL सर्वर उस क्वेरी के लिए अंतिम ज्ञात अच्छी योजना को बाध्य करेगा, जिसे निश्चित रूप से क्वेरी स्टोर से खींचा गया है। लेकिन यह वहाँ नहीं रुकता। SQL सर्वर तब प्रदर्शन की निगरानी करना जारी रखता है - अभी भी क्वेरी स्टोर का उपयोग कर रहा है - यह पुष्टि करने के लिए कि मजबूर योजना अभी भी उस क्वेरी के लिए एक अच्छी योजना है, जिसका अर्थ है कि मजबूर योजना के साथ क्वेरी वापस किए गए संस्करण से बेहतर प्रदर्शन करती है। यदि वह प्रश्न बेहतर प्रदर्शन नहीं कर रहा है, तो यह योजना को लागू नहीं करेगा। यदि कोई पुनर्संकलन है, या यदि बलपूर्वक विफल रहता है, तो एक योजना भी अन-मजबूर हो सकती है।

यह सिलसिला जारी है; यदि किसी प्रश्न में एक मजबूर योजना है, और फिर वह योजना उपरोक्त कारणों में से किसी एक के लिए मजबूर नहीं है, तो उसी योजना को बाद में फिर से मजबूर किया जा सकता है, या बाद में उस प्रश्न के लिए किसी अन्य योजना को मजबूर किया जा सकता है। यह एक सतत प्रक्रिया है जो तब तक होती है जब तक आपके पास डेटाबेस के लिए स्वचालित योजना सुधार विकल्प सक्षम है। अब, जो दिलचस्प है वह यह है कि आप उसी जानकारी को देख सकते हैं जो यह सुविधा कैप्चर करती है और इसे मैन्युअल रूप से बल योजना का उपयोग करती है। अर्थात्, SQL सर्वर 2017 एंटरप्राइज़ संस्करण और Azure SQL डेटाबेस में, यह डेटा sys.dm_db_tuning_recommendations DMV में एकत्र किया जा रहा है, भले ही स्वचालित योजना सुधार सुविधा सक्षम न हो, इसलिए आप उस डेटा की जांच कर सकते हैं और योजनाओं को लागू करने के लिए इसकी अनुशंसाओं का पालन कर सकते हैं। अपने आप पर विशिष्ट प्रश्नों के लिए। ध्यान दें कि यदि आप sys.dm_db_tuning_recommendations से अनुशंसाओं का उपयोग करके किसी योजना को बाध्य करते हैं, तो यह स्वचालित रूप से कभी भी बाध्य नहीं होगी। इसके अलावा, यदि आपके पास स्वचालित योजना सुधार सक्षम है, और आप किसी योजना को मैन्युअल रूप से लागू करते हैं, तो यह स्वचालित रूप से कभी भी बाध्य नहीं होगा। केवल वे योजनाएँ जो स्वचालित योजना सुधार सुविधा के साथ ज़बरदस्ती की गई हैं, स्वचालित रूप से अप्रभावित हो जाएँगी।

क्या मैं वाकई SQL सर्वर को नियंत्रण करने दूंगा?

यदि आप संशय में हैं और सोच रहे हैं कि क्या आप वास्तव में SQL सर्वर पर एक योजना-मजबूर निर्णय लेने के लिए भरोसा कर सकते हैं, तो यहां मैं आपको याद रखने के लिए प्रोत्साहित करूंगा:

1. यह सुविधा लगभग दो मिलियन Azure SQL डेटाबेस से कैप्चर किए गए डेटा की एक चौंका देने वाली मात्रा के साथ विकसित की गई थी। यह SQL सर्वर 2017 में एक नई सुविधा है, लेकिन इसने इसे 2016 में Azure में वैश्विक उपलब्धता में बनाया है, इसलिए यह सुविधा वास्तव में एक वर्ष से अधिक समय से उपलब्ध है, और इसे परिष्कृत किया गया है।
2. इंजीनियरों ने समय के साथ एल्गोरिथम में बदलाव किए हैं, क्योंकि उन्होंने अधिक डेटा कैप्चर किया है। हो सकता है कि इसमें होने वाले प्रत्येक प्रतिगमन को न पाया जाए - क्योंकि एक प्रतिगमन पर्याप्त गंभीर नहीं हो सकता है, लेकिन मैं शर्त लगा सकता हूं कि आप में से कई लोग इस सुविधा बल को बहुत कम बार चाहते हैं।
3. उसके ऊपर, यदि कोई योजना मजबूर है, लेकिन एक समस्या का कारण बनती है, तो SQL सर्वर की क्षमता उससे उबरने और योजना को अन-फोर्स करने की क्षमता अत्यंत विश्वसनीय है और बहुत जल्दी होती है।

सारांश

हो सकता है कि आप अपने लिए प्रदर्शन समस्याओं को संबोधित करने वाले SQL सर्वर के विचार से सहज न हों। लेकिन क्या यह असुविधा इसलिए है क्योंकि आपको लगता है कि यह एक खराब निर्णय लेगा? या आप ऑटोमेशन को लेकर चिंतित हैं कि आपकी नौकरी पर कब्ज़ा कर लिया जाए? बहुत सीधा सवाल, मुझे पता है। यदि यह पूर्व है, तो मेरी सिफारिश है कि sys.dm_db_tuning_recommendations (स्वचालित योजना सुधार को सक्षम किए बिना) में कैप्चर किए गए डेटा को देखें और देखें कि SQL सर्वर क्या करना चाहता है। क्या यह आपके द्वारा किए जाने वाले कार्यों के अनुरूप है? क्या यह उन प्रतिगमनों को ढूंढता है जिन्हें आप याद कर सकते हैं? यदि आप इस सुविधा को सक्षम नहीं करना चाहते हैं क्योंकि आप डरते हैं कि अचानक आपके पास करने के लिए पर्याप्त नहीं होगा, तो मैं आपको कॉनर कनिंघम की हालिया पोस्ट पढ़ने के लिए प्रोत्साहित करता हूं, कैसे क्लाउड स्पीड SQL सर्वर डीबीए में मदद करती है। Microsoft आपको नौकरी से निकालने का प्रयास नहीं कर रहा है। वे केवल कम लटके फलों को संभालने की कोशिश कर रहे हैं ताकि आप अधिक महत्वपूर्ण कार्यों पर ध्यान केंद्रित कर सकें।