SQL सर्वर प्रदर्शन ट्यूनिंग के बारे में चर्चा में आने वाले सबसे सामान्य शब्दों में से एक है प्रतीक्षा आँकड़े . यह 2006 के Microsoft दस्तावेज़, "SQL Server 2005 प्रतीक्षा और कतार" से पहले भी बहुत पुराना है।
प्रतीक्षा पूरी तरह से सब कुछ नहीं है, और यह पद्धति किसी उदाहरण को ट्यून करने का एकमात्र तरीका नहीं है, किसी व्यक्तिगत प्रश्न पर ध्यान न दें। वास्तव में, प्रतीक्षा अक्सर बेकार होती है जब आपके पास केवल वह प्रश्न होता है जो उन्हें भुगतना पड़ता है, और कोई आसपास का संदर्भ नहीं होता है, विशेष रूप से इस तथ्य के लंबे समय बाद। ऐसा इसलिए है, क्योंकि अक्सर, जिस चीज़ पर एक क्वेरी प्रतीक्षा कर रही होती है वह उस क्वेरी की गलती नहीं है . किसी भी चीज़ की तरह, अपवाद भी हैं, लेकिन यदि आप कोई उपकरण या स्क्रिप्ट केवल इसलिए चुन रहे हैं क्योंकि यह बहुत विशिष्ट कार्यक्षमता प्रदान करता है, तो मुझे लगता है कि आप स्वयं को नुकसान पहुंचा रहे हैं। पॉल रान्डल ने मुझे कुछ समय पहले जो सलाह दी थी, मैं उसका पालन करता हूं:
…आम तौर पर मेरा सुझाव है कि पूरे इंस्टेंस वेटिंग के साथ शुरू करें। मैं कभी भी शुरू नहीं होता व्यक्तिगत क्वेरी प्रतीक्षा को देखकर समस्या निवारण।
कभी-कभी, हाँ, हो सकता है कि आप किसी व्यक्तिगत क्वेरी में गहराई से जाना चाहें और देखें कि वह किसकी प्रतीक्षा कर रहा है; वास्तव में Microsoft ने हाल ही में इस विश्लेषण में मदद करने के लिए शोप्लान के लिए क्वेरी-स्तरीय प्रतीक्षा आँकड़े जोड़े हैं। लेकिन ये संख्याएं आम तौर पर आपके इंस्टेंस के प्रदर्शन को समग्र रूप से ट्यून करने में आपकी मदद नहीं करने वाली हैं, जब तक कि वे कुछ ऐसा इंगित करने में मदद नहीं कर रही हैं जो आपके पूरे कार्यभार को प्रभावित कर रहा हो। यदि आपको कल की एक क्वेरी दिखाई देती है जो 5 मिनट तक चलती है, और ध्यान दें कि उसका प्रतीक्षा प्रकार LCK_M_S था , अब आप इसके बारे में क्या करने जा रहे हैं? आप कैसे पता लगाएंगे कि वास्तव में क्वेरी को क्या रोक रहा था और उस प्रतीक्षा प्रकार का कारण बन रहा था? यह किसी ऐसे लेन-देन के कारण हो सकता है जो किसी अन्य कारण से नहीं कर रहा था, लेकिन आप यह नहीं देख सकते हैं कि यदि आप पूरे सिस्टम की स्थिति नहीं देख सकते हैं और केवल व्यक्तिगत प्रश्नों और उनके द्वारा अनुभव की गई प्रतीक्षा पर ध्यान केंद्रित कर रहे हैं।
जेसन हॉल (@SQLSaurus) ने पास होने में कुछ ऐसा उल्लेख किया जो मेरे लिए भी दिलचस्प था। उन्होंने कहा कि यदि क्वेरी-स्तरीय प्रतीक्षा आँकड़े ट्यूनिंग प्रयासों का इतना महत्वपूर्ण हिस्सा होते हैं, तो यह कार्यप्रणाली शुरू से ही क्वेरी स्टोर में बेक हो जाती। इसे हाल ही में जोड़ा गया है (SQL सर्वर 2017 में)। लेकिन आपको अभी भी प्रति-निष्पादन प्रतीक्षा आँकड़े नहीं मिलते हैं; आप समय के साथ औसत प्राप्त करते हैं, जैसे कि क्वेरी आँकड़े और प्रक्रिया आँकड़े जो आप DMV में देखते हैं। इसलिए अचानक विसंगतियां अन्य मेट्रिक्स के आधार पर स्पष्ट हो सकती हैं जो प्रति क्वेरी निष्पादन कैप्चर की जाती हैं, लेकिन प्रतीक्षा समय के औसत पर आधारित नहीं होती हैं जो कि सभी पर खींची जाती हैं। निष्पादन आप उस श्रेणी प्रतीक्षा को कस्टमाइज़ कर सकते हैं, जो एकत्रित हो गई है, लेकिन व्यस्त सिस्टम पर यह अभी भी इतना विस्तृत नहीं हो सकता है कि आपको लगता है कि यह आपके लिए क्या करने जा रहा है।
इस पोस्ट का उद्देश्य कुछ अधिक सामान्य प्रतीक्षा प्रकारों पर चर्चा करना है जो हम अपने ग्राहक आधार में देखते हैं, और जब वे होते हैं तो आप किस प्रकार की कार्रवाइयां कर सकते हैं (और नहीं)। हमारे पास अज्ञात प्रतीक्षा आँकड़ों का एक डेटाबेस है जिसे हम अपने क्लाउड सिंक ग्राहकों से काफी समय से एकत्र कर रहे हैं, और 2017 के मई से हम सभी को दिखा रहे हैं कि ये SQLskills Waits लाइब्रेरी पर कैसे दिखते हैं।
पॉल पुस्तकालय के पीछे के कारण और इस मुफ्त सेवा के साथ हमारे एकीकरण के बारे में भी बात करता है। मूल रूप से, आप एक प्रतीक्षा प्रकार देखते हैं जिसके बारे में आप अनुभव कर रहे हैं या उत्सुक हैं, और वह बताता है कि इसका क्या अर्थ है और आप इसके बारे में क्या कर सकते हैं। हम इस गुणात्मक जानकारी को एक चार्ट के साथ पूरक करते हैं, यह दिखाते हुए कि हमारे उपयोगकर्ता आधार के बीच वर्तमान प्रतीक्षा कितनी प्रचलित है, इसकी तुलना हम सभी अन्य प्रतीक्षा प्रकारों से करते हैं, ताकि आप जल्दी से बता सकें कि क्या आप एक सामान्य प्रतीक्षा प्रकार या कुछ और के साथ काम कर रहे हैं। विदेशी। (ध्यान रखें कि SQL संतरी में सौम्य, पृष्ठभूमि और कतार शामिल नहीं है जो शोर की मात्रा का इंतजार करती है और अधिकांश स्क्रिप्ट फ़िल्टर हो जाती हैं, जैसे WAITFOR या LAZYWRITER_SLEEP - ये केवल प्रदर्शन समस्याओं के स्रोत नहीं हैं।)
यहां CXPACKET के लिए एक उदाहरण चार्ट दिया गया है , सबसे आम प्रतीक्षा प्रकार है:
मैंने इससे थोड़ा आगे जाना शुरू किया, कुछ अधिक सामान्य प्रतीक्षा प्रकारों की मैपिंग की, और उनके द्वारा साझा की गई कुछ संपत्तियों पर ध्यान दिया। प्रश्नों में अनुवादित एक ट्यूनर के पास उनके द्वारा अनुभव किए जा रहे प्रतीक्षा प्रकार के बारे में हो सकता है:
- क्या प्रतीक्षा प्रकार को क्वेरी स्तर पर हल किया जा सकता है?
- क्या प्रतीक्षा का मुख्य लक्षण अन्य प्रश्नों को प्रभावित करने की संभावना है?
- क्या यह संभव है कि समस्या को "समाधान" करने के लिए आपको किसी एकल क्वेरी और उसके द्वारा अनुभव किए गए प्रतीक्षा प्रकारों के संदर्भ में अधिक जानकारी की आवश्यकता होगी?
जब मैं इस पोस्ट को लिखने के लिए निकला, तो मेरा लक्ष्य केवल सबसे सामान्य प्रतीक्षा प्रकारों को एक साथ समूहित करना था, और फिर उपरोक्त प्रश्नों से संबंधित उनके बारे में नोट्स लिखना शुरू करना था। जेसन ने पुस्तकालय से सबसे आम लोगों को खींच लिया, और फिर मैंने एक व्हाइटबोर्ड पर कुछ चिकन खरोंच खींचे, जिसे मैंने बाद में थोड़ा साफ किया। इस प्रारंभिक शोध के कारण जेसन ने अलास्का में नवीनतम टेकऑउटबाउंड एसक्यूएल क्रूज पर एक बात की। मैं इस बात से शर्मिंदा हूं कि उन्होंने इस पोस्ट को समाप्त करने से महीनों पहले एक साथ बात की, तो चलिए इसके साथ आगे बढ़ते हैं। यहां हम देखते हैं शीर्ष प्रतीक्षाएं (जो काफी हद तक 2014 से पॉल के सर्वेक्षण से मेल खाती हैं), उपरोक्त प्रश्नों के मेरे उत्तर, और प्रत्येक पर कुछ टिप्पणी:
नीचे दी गई तालिका में लिंक के साथ बातचीत करने के लिए, कृपया इस पृष्ठ पर एक विस्तृत स्क्रीन पर जाएँ।
एक विशेष लॉक के साथ एक पंक्ति, पृष्ठ, विभाजन, आदि को अपडेट करने का प्रयास करते समय अवरुद्ध। यह स्कीमा लॉक (जैसे ऑफ़लाइन पुनर्निर्माण), स्पष्ट लॉकिंग संकेतों से वृद्धि, लंबे समय तक चलने वाले लेन-देन, या कई अन्य कारणों से हो सकता है। ऐसा अक्सर हो सकता है क्योंकि एक इंडेक्स "हॉट" होता है - यह क्वेरी से स्पष्ट हो सकता है कि यह कौन सा इंडेक्स है, या यह कि TABLOCKX जैसे स्पष्ट संकेत हैं। , लेकिन ऐसा नहीं हो सकता है। अकेले प्रतीक्षा प्रकार आपको इसके बारे में कुछ नहीं बताएगा; आपको अधिनियम में क्वेरी के लंबे समय से चल रहे संस्करण को पकड़ना होगा, और निष्पादन योजना, sys.dm_tran_locks जैसी चीजों की जांच करनी होगी। , sys.dm_os_waiting_tasks , और शायद नेता को अवरुद्ध करने वाली श्रृंखला का अनुसरण भी करें। लाइब्रेरी में और इस पोस्ट में घुटने के बल चलने वाली प्रतिक्रियाओं के बारे में अधिक जानकारी। | ||
| क्वेरी लेवल पर सॉल्व करने योग्य? | शायद | |
| अधिक बाहरी जानकारी चाहिए? | <वीं कक्षा=एसएम>हां||
|
अनिवार्य रूप से #10 के समान ही, सिवाय इसके कि यह केवल एक सामान्य अपडेट लॉक है, विशेष नहीं। लाइब्रेरी में और इस पोस्ट में घुटने के बल चलने वाली प्रतिक्रियाओं के बारे में अधिक जानकारी। | ||
| क्वेरी लेवल पर सॉल्व करने योग्य? | शायद | |
| अधिक बाहरी जानकारी चाहिए? | <वीं कक्षा=एसएम>हां||
|
डिस्क पर लॉग ब्लॉक लिखे जाने की प्रतीक्षा में अवरोधित। जबकि आप तर्क दे सकते हैं कि यह प्रतीक्षा इसलिए होती है क्योंकि आप लॉग में बहुत अधिक लिख रहे हैं, यह एक डेटाबेस- या सिस्टम-व्यापी समस्या है जो लगभग निश्चित रूप से वर्तमान क्वेरी से अधिक प्रभावित कर रही है जिसका आप समस्या निवारण कर रहे हैं। यह हो सकता है कि आपके पास लॉग पर लगातार लिखने वाले बहुत से बड़े लेन-देन हों, इस स्थिति में आप लिखने के संचालन को छोटा करने, ट्रंकेट/लोड प्रक्रियाओं को अप्सर्ट में बदलने, या यहां तक कि विलंबित स्थायित्व या इन-मेमोरी ओएलटीपी पर विचार कर सकते हैं। उच्च वीएलएफ गणना इस प्रतीक्षा प्रकार में योगदान दे सकती है, साथ ही अधिकतम समवर्ती लेखन सीमाओं को मार सकती है, और आपकी क्वेरी-स्तरीय प्रतीक्षा आपको यह भी नहीं बताएगी। यदि आप सिंक्रोनस HA तकनीक का उपयोग कर रहे हैं, जैसे मिररिंग या उपलब्धता समूह, तो यह अधिक प्रचलित हो सकता है। यह सामान्य रूप से धीमे I/O से जुड़ा होता है, इस स्थिति में आपको लॉग को SSD या बेहतर में ले जाने पर विचार करना चाहिए, यदि संभव हो तो। पुस्तकालय में अधिक विवरण, और पॉल (भाग एक | भाग दो), एरिन स्टेलेटो, और टिम रेडनी से ये पोस्ट देखें। | ||
| क्वेरी लेवल पर सॉल्व करने योग्य? | नहीं | |
| अधिक बाहरी जानकारी चाहिए? | शायद | |
|
ऊपर #9 और #10 की तरह, लेकिन इस बार यह एक इंटेंट एक्सक्लूसिव लॉक है (जिसकी चर्चा क्लॉस एसचेनब्रेनर ने यहां की है)। लाइब्रेरी में और इस पोस्ट में घुटने के बल चलने वाली प्रतिक्रियाओं के बारे में अधिक जानकारी। | ||
| क्वेरी लेवल पर सॉल्व करने योग्य? | शायद | |
| अधिक बाहरी जानकारी चाहिए? | <वीं कक्षा=एसएम>हां||
पेज बफ़र्स या डेटा या लॉग फ़ाइल जैसी गैर-पृष्ठ डेटा संरचना पर विशेष लैच की प्रतीक्षा कर रहा है। उदाहरणों में एक लॉग फ़ाइल के स्वतः बढ़ने की प्रतीक्षा करना या यहां तक कि एक NOLOCK . भी शामिल है क्वेरी के साझा लैच अपडेट में देरी कर रहे हैं। आपको sys.dm_os_waiting_tasks . का उपयोग करके इनका पीछा करना होगा और sys.dm_os_latch_stats , और फिर लैच क्लासेस लाइब्रेरी में लैच क्लास को देख रहे हैं, लेकिन ऐसा तभी करें जब यह आपके सिस्टम पर टॉप वेटिंग हो और बड़ी संख्या में क्वेरीज़ को प्रभावित कर रहा हो। पुस्तकालय में अधिक विवरण। | ||
| क्वेरी लेवल पर सॉल्व करने योग्य? | शायद | |
| शायद | ||
| अधिक बाहरी जानकारी चाहिए? | <वीं कक्षा=एसएम>हां||
|
पावती की प्रतीक्षा में कि डेटा TDS द्वारा भेजा गया है। अक्सर इसे धीमे नेटवर्क बैंडविड्थ के संकेतक के रूप में गलत समझा जाता है; मैं एक डीबीए को अपने पूरे कार्यालय में चिल्लाते हुए देखता हूं, "बड़ी फाइलें डाउनलोड करना बंद करो!" यह लगभग कभी भी नेटवर्क समस्या नहीं है; आमतौर पर क्लाइंट प्रोसेसिंग में देरी के कारण, जहां कर्सर जैसी प्रोसेसिंग, MARS, लिंक्ड सर्वर, या कम पावर वाले क्लाइंट चलन में हैं। अक्सर यह 4 जीबी रैम वाली मशीन पर एसएसएमएस ग्रिड में 50 अरब पंक्तियों को प्रस्तुत करने की कोशिश कर रहा है, या एक पेजिंग एप्लिकेशन जो पूरी तालिका को खींचता है, 50 पंक्तियों को दिखाता है, और फिर रुक जाता है, आपके लिए अगला क्लिक करने की प्रतीक्षा करता है। ऐप बस नहीं रख सकता (या नहीं) और SQL सर्वर इस प्रतीक्षा प्रकार को पंजीकृत करता है क्योंकि यह ऐप के अधिक पंक्तियों का उपभोग करने की प्रतीक्षा कर रहा है। लाइब्रेरी में और इस पोस्ट में घुटने के बल चलने वाली प्रतिक्रियाओं के बारे में अधिक जानकारी। | ||
| क्वेरी लेवल पर सॉल्व करने योग्य? | शायद | |
| शायद | ||
| अधिक बाहरी जानकारी चाहिए? | <वीं कक्षा=एसएम>हां||
इसका सीधा सा मतलब है कि एक धागा स्वेच्छा से अपने 4ms क्वांटम के अंत में निकला है। यह अनपेक्षित स्कैन, प्रकार, या संकलन समय का संकेत दे सकता है; या एक अंडर-पावर्ड/ओवर-सब्सक्राइब वर्चुअल मशीन। अगर यह एक शीर्ष है प्रतीक्षा करें, एक नया मुद्दा है, और वास्तविक प्रदर्शन समस्या के साथ सहसंबद्ध हो सकता है, इन प्रश्नों को sys.dm_exec_requests में देखें , देखें कि क्या वर्तमान योजना एक बड़ा स्कैन या सॉर्ट कर रही है जिसे टाला जा सकता है, और यदि कोई स्पष्ट कारण नहीं है, तो गहरी खुदाई करें। लाइब्रेरी में और इस पोस्ट में घुटने के बल चलने वाली प्रतिक्रियाओं के बारे में अधिक जानकारी। | ||
| क्वेरी लेवल पर सॉल्व करने योग्य? | शायद | |
| अधिक बाहरी जानकारी चाहिए? | नहीं | |
एक डेटा पेज को पढ़ने की प्रतीक्षा कर रहा है जिसे पहले डिस्क से पढ़ा जाना चाहिए। यह I/O सबसिस्टम के साथ एक समस्या की तरह लगता है, और आपको इसे sys.dm_io_virtual_file_stats में विलंबता के माध्यम से खोजना चाहिए . लेकिन यह आमतौर पर अपर्याप्त स्मृति के कारण होता है - या ऐसी चीजें जो पृष्ठों को स्मृति से बाहर धकेल रही हैं, जैसे स्पष्ट DBCC DROPCLEANBUFFERS कॉल या अलग-अलग, बड़ी तालिकाओं के बहुत सारे स्कैन। यदि संभव हो तो मेमोरी जोड़ें, अन्य मेमोरी-भूखे डेटाबेस या एप्लिकेशन को अन्य सर्वर पर ले जाएं, या अनावश्यक स्कैन को हटाने के लिए क्वेरी ट्यून करें। लाइब्रेरी में और इस पोस्ट में घुटने के बल चलने वाली प्रतिक्रियाओं के बारे में अधिक जानकारी। | ||
| क्वेरी लेवल पर सॉल्व करने योग्य? | शायद | |
| शायद | ||
| अधिक बाहरी जानकारी चाहिए? | <वीं कक्षा=एसएम>हां||
पंक्ति, पृष्ठ, विभाजन आदि पर साझा लॉक प्राप्त करने की प्रतीक्षा कर रहा है। यह संक्षिप्त रूप से तब हो सकता है जब संपूर्ण डेटाबेस पर एक S लॉक हटा दिया जाता है (उदाहरण के लिए कोई व्यक्ति बदल रहा है) एक डेटाबेस सेटिंग) या बुनियादी और अधिक सामान्य "पाठकों को अवरुद्ध करने वाले लेखक" परिदृश्य। यदि यह एक शीर्ष प्रतीक्षा है और आप इसे अपने कार्यभार में विशिष्ट प्रदर्शन समस्याओं से संबंधित कर सकते हैं, तो sys.dm_os_waiting_tasks के माध्यम से प्रभावित संसाधन(संसाधनों) को कैप्चर करने का प्रयास करें और sys.dm_tran_locks . एक शमन पठन प्रतिबद्ध स्नैपशॉट का उपयोग कर सकता है, लेकिन आपको tempdb के प्रभाव के बारे में पता होना चाहिए। लाइब्रेरी में और इस पोस्ट में घुटने के बल चलने वाली प्रतिक्रियाओं के बारे में अधिक जानकारी। | ||
| क्वेरी लेवल पर सॉल्व करने योग्य? | शायद | |
| अधिक बाहरी जानकारी चाहिए? | <वीं कक्षा=एसएम>हां||
अब तक अस्तित्व में सबसे चर्चित और गलत समझा जाने वाला प्रतीक्षा प्रकार है। अधिकांश समय, इसका सीधा सा मतलब है कि समानता हो रही है। सर्वर MAXDOP . को सेट करने के लिए नी-झटका प्रतिक्रिया है से 1. ऐसा मत करो।
सबसे लंबे समय तक,
SQL सर्वर 2016 SP2, 2017 CU3, और Azure SQL डेटाबेस में, यह सब बदल गया है। किसी भी मामले में, आप यहां और यहां पॉल की सलाह का पालन करते हुए कारण निर्धारित कर सकते हैं और उपचारात्मक कदम उठा सकते हैं, और पुस्तकालय में अधिक विवरण देख सकते हैं। | ||
| क्वेरी लेवल पर सॉल्व करने योग्य? | <वीं कक्षा=एसएम>हां||
| शायद | ||
| अधिक बाहरी जानकारी चाहिए? | <वीं कक्षा=एसएम>हां||
सारांश
इनमें से अधिकतर मामलों में, इंस्टेंस स्तर पर प्रतीक्षा को देखना बेहतर होता है, और केवल क्वेरी-स्तर पर प्रतीक्षा करना बेहतर होता है जब आप विशिष्ट प्रश्नों का निवारण कर रहे होते हैं जो प्रतीक्षा प्रकार की परवाह किए बिना प्रदर्शन समस्याओं को प्रदर्शित करते हैं। ये ऐसी चीजें हैं जो अन्य कारणों से सामने आती हैं, जैसे लंबी अवधि, उच्च CPU, या उच्च I/O, और सरल चीजों द्वारा समझाया नहीं जा सकता है (जैसे क्लस्टर इंडेक्स स्कैन जब आप एक तलाश की उम्मीद कर रहे थे)।
इंस्टेंस स्तर पर भी, हर उस प्रतीक्षा का पीछा न करें जो आपके सिस्टम पर शीर्ष प्रतीक्षा बन जाती है - आप हमेशा करेंगे एक शीर्ष प्रतीक्षा करें, और आप कभी भी इसका पीछा करना बंद नहीं कर पाएंगे। सुनिश्चित करें कि आप सौम्य प्रतीक्षा को अनदेखा करते हैं (पॉल एक सूची रखता है) और केवल उस प्रतीक्षा के बारे में चिंता करें जिसे आप वास्तविक प्रदर्शन समस्या से जोड़ सकते हैं जिसका आप अनुभव कर रहे हैं। अगर CXPACKET इंतजार ज्यादा है, तो क्या? क्या उस संख्या के "उच्च" होने या सूची में सबसे ऊपर होने के अलावा कोई अन्य लक्षण हैं?
यह सब नीचे आता है कि आप पहली बार में समस्या निवारण क्यों कर रहे हैं। क्या एक एकल उपयोगकर्ता एक दुष्ट क्वेरी के एकल उदाहरण के बारे में शिकायत कर रहा है? क्या आपका सर्वर घुटनों पर है? बीच में कुछ? पहले मामले में, निश्चित रूप से, यह जानना कि कोई क्वेरी धीमी क्यों है, उपयोगी हो सकती है, लेकिन यह ट्रैक करने के लिए काफी महंगा है (कभी भी अनिश्चित काल तक ध्यान न रखें) हर एक क्वेरी से जुड़े सभी प्रतीक्षा, पूरे दिन, हर दिन, अजीब मौके पर आप वापस आना चाहते हैं और बाद में उनकी समीक्षा करना चाहते हैं। यदि यह उस क्वेरी से अलग एक व्यापक समस्या है, तो आपको यह निर्धारित करने में सक्षम होना चाहिए कि उस क्वेरी को फिर से चलाकर और निष्पादन योजना, संकलन समय और अन्य रनटाइम मेट्रिक्स एकत्र करके क्या धीमा कर रहा है। यदि यह पिछले मंगलवार को हुई एक बार की बात थी, चाहे आपके पास क्वेरी के उस एकल उदाहरण की प्रतीक्षा हो या न हो, आप अधिक संदर्भ के बिना समस्या को हल करने में सक्षम नहीं हो सकते हैं। हो सकता है कि कोई अवरोध था, लेकिन आप नहीं जान पाएंगे कि क्या, या शायद एक I/O स्पाइक था, लेकिन आपको उस मुद्दे को अलग से ट्रैक करना होगा। प्रतीक्षा प्रकार अपने आप में आमतौर पर पर्याप्त जानकारी प्रदान नहीं करता है, सिवाय इसके कि, किसी और चीज़ के लिए एक सूचक।
बेशक, मुझे अपना रख-रखाव यहां भी कमाने की जरूरत है। हमारा प्रमुख उत्पाद, SQL संतरी, निगरानी के लिए एक समग्र दृष्टिकोण अपनाता है। हम इंस्टेंस-वाइड प्रतीक्षा आँकड़े एकत्र करते हैं, उन्हें आपके लिए वर्गीकृत करते हैं, और उन्हें हमारे डैशबोर्ड पर ग्राफ़ करते हैं:
आप अनुकूलित कर सकते हैं कि किसी व्यक्तिगत प्रतीक्षा को कैसे वर्गीकृत किया जाता है और वह श्रेणी डैशबोर्ड पर भी दिखाई देती है या नहीं। आप मौजूदा प्रतीक्षा आंकड़ों की तुलना बिल्ट-इन या कस्टम बेसलाइन से कर सकते हैं, और यहां तक कि अलर्ट या कार्रवाइयां भी सेट कर सकते हैं, जब वे बेसलाइन से कुछ निर्धारित विचलन को पार कर जाते हैं। और, शायद सबसे महत्वपूर्ण बात यह है कि आप अतीत के डेटा बिंदु को देख सकते हैं, और पूरे डैशबोर्ड को उस समय में सिंक कर सकते हैं, ताकि आप आसपास के सभी संदर्भों और किसी भी अन्य स्थिति को कैप्चर कर सकें, जिसने समस्या को प्रभावित किया हो। जब आपको ध्यान केंद्रित करने के लिए अधिक बारीक चीजें मिलती हैं, जैसे अवरुद्ध करना, उच्च डिस्क विलंबता, या उच्च I/O या लंबी अवधि वाली क्वेरी, तो आप उन मीट्रिक में ड्रिल कर सकते हैं और समस्या की जड़ तक जल्दी पहुंच सकते हैं।
सामान्य प्रतीक्षा आँकड़े दृष्टिकोण और विशेष रूप से हमारे समाधान दोनों के बारे में अधिक जानकारी के लिए, आप केविन क्लाइन के श्वेत पत्र, समस्या निवारण SQL सर्वर प्रतीक्षा आँकड़े देख सकते हैं, और आप पॉल रान्डल, एंडी यून (@SQLBek) द्वारा प्रस्तुत दो-भाग वाला वेबिनार डाउनलोड कर सकते हैं। और एंडी मॉलन (@AMtwo):
- भाग 1 :प्रतीक्षा सांख्यिकी का उपयोग करके प्रदर्शन समस्या निवारण
- भाग 2 :SentryOne के साथ प्रतीक्षा सांख्यिकी का तीव्र विश्लेषण
और अगर आप SentryOne प्लेटफॉर्म को एक स्पिन देना चाहते हैं, तो आप यहां सीमित समय के ऑफर के साथ शुरुआत कर सकते हैं:
15-दिन का निःशुल्क परीक्षण डाउनलोड करें
