SQL सर्वर 2012 में query_post_execution_showplan विस्तारित ईवेंट का प्रभाव

SQL सर्वर में सबसे कठिन चुनौतियों में से एक पैरामीटर संवेदनशीलता या कार्डिनैलिटी अनुमान के साथ समस्याओं का निवारण करना है जो कार्यभार के प्रदर्शन में गिरावट का कारण बनते हैं। प्रदर्शन में गिरावट का कारण निर्धारित करने में सक्षम होने के लिए आम तौर पर आपको कथन से वास्तविक निष्पादन योजना की आवश्यकता होगी। SQL सर्वर 2012 में, query_post_execution_showplan विस्तारित इवेंट कथनों के लिए वास्तविक निष्पादन योजना को कैप्चर करने की क्षमता प्रदान करता है। हालांकि, यह जितना उपयोगी प्रतीत होता है, यह घटना कुछ ऐसी नहीं है जिसका उपयोग सर्वर पर चल रहे कार्यभार पर महत्वपूर्ण प्रदर्शन प्रभाव के बिना किया जा सकता है।

एसक्यूएल ट्रेस बनाम एक्सटेंडेड इवेंट्स के "ऑब्जर्वर ओवरहेड" को मापने के अपने लेख में, मैंने SQL सर्वर 2012 में एक्सटेंडेड इवेंट्स का उपयोग करके एक समान कॉन्फ़िगरेशन के खिलाफ SQL ट्रेस के प्रदर्शन प्रभाव की तुलना दिखाई। उस समय मैंने मूल रूप से उस लेख के लिए परीक्षण किया था। मैंने SQL Server 2012 में query_post_execution_showplan ईवेंट का बहुत परीक्षण भी किया था।  इस ईवेंट को पहली बार SQL Server 2012 CTP1 में पेश किया गया था, जब SQL ट्रेस के साथ समानता प्रदान करने के लिए कई ट्रेस ईवेंट को विस्तारित ईवेंट में पोर्ट किया गया था। उस समय ईवेंट में केवल उन स्तंभों का एक सबसेट था जो SQL Server 2012 के अंतिम RTM में शामिल किए गए थे।

CTP1 के दौरान मैंने एक कनेक्ट आइटम सबमिट किया जिसमें अनुरोध किया गया था कि SQL सर्वर 2012 में घटनाओं के साथ वास्तविक निष्पादन योजना के संग्रह की अनुमति देने के लिए एक क्रिया बनाई जाए। या बयान अपनी सामान्य अवधि से अधिक है। उदाहरण के लिए, पैरामीटर संवेदनशीलता के परिदृश्य में, जहां सामान्य पैरामीटर मानों के लिए एक कम आदर्श योजना तैयार की जाती है, घटना का उपयोग एक क्रिया के माध्यम से उस कथन के लिए वास्तविक निष्पादन योजना एकत्र करने के लिए किया जा सकता है। जवाब में, SQL सर्वर टीम ने अवधि और cpu_time कॉलम को query_post_execution_showplan इवेंट में जोड़ा, ताकि केवल उन परिदृश्यों के लिए इस ईवेंट को एकत्रित करने के लिए विधेय परिभाषाएँ दी जा सकें।

दुर्भाग्य से इसका वही लाभ नहीं है जो एक क्रिया के रूप में एक कार्यान्वयन के प्रदर्शन पर होता। इस पोस्ट के बाकी हिस्सों में मैं समझाऊंगा कि क्यों।

प्रदर्शन प्रभाव

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

प्रदर्शन प्रभाव का परीक्षण करने के लिए, SQL ट्रेस बनाम विस्तारित ईवेंट आलेख के "ऑब्जर्वर ओवरहेड" को मापने से ठीक उसी कार्यभार और वितरित रीप्ले कॉन्फ़िगरेशन का उपयोग किया गया था। इस आलेख में दिखाए गए परीक्षण परिणामों के लिए एकमात्र अंतर यह है कि VM वातावरण के लिए एक नए, अधिक शक्तिशाली होस्ट सिस्टम का उपयोग किया गया था। उपयोग किए गए वीएम बिल्कुल समान थे, उनके कॉन्फ़िगरेशन में कोई बदलाव नहीं हुआ था, और उन्हें बस नई प्रणाली में कॉपी किया गया था, यही वजह है कि बेसलाइन वर्कलोड उच्च औसत बैच अनुरोध/सेकंड के साथ तेजी से रीप्ले करने में सक्षम था। सर्वर पर चल रहे केवल डिफ़ॉल्ट system_health ईवेंट सत्र के साथ मानक SQL Server 2012 स्थापना का उपयोग करके आधारभूत परिणाम कैप्चर किए गए थे।

query_post_execution_showplan . के प्रदर्शन प्रभाव की तुलना के लिए ईवेंट, निम्न ईवेंट सत्र परिभाषा का उपयोग किया गया था।

ईवेंट सत्र बनाएं [query_post_execution_showplan ओवरहेड]सर्वर पर ईवेंट sqlserver.query_post_execution_showplan(WHERE ([duration]=(5000000)));जाओ

यह सत्र वास्तव में एक लक्ष्य का उपयोग करके घटना डेटा एकत्र नहीं करता है और घटना की अवधि के लिए 5000000 माइक्रोसेकंड, या पांच सेकंड की अवधि के बराबर एक विधेय का उपयोग करता है। रीप्ले वर्कलोड के लिए, किसी भी स्टेटमेंट को क्रियान्वित करने की अवधि ठीक पाँच सेकंड की नहीं होती है, इसलिए query_post_execution_showplan ईवेंट वास्तव में सर्वर में कभी भी सक्रिय नहीं होता है, और किसी भी प्रदर्शन में गिरावट सख्ती से ईवेंट डेटा संग्रह का परिणाम है और फिर मूल्यांकन का अनुमान लगाता है। परीक्षणों के परिणाम तालिका 1 में दिखाए गए हैं और चार्ट 2 में चार्ट किए गए हैं।

तालिका 1 - query_post_execution ईवेंट ओवरहेड

चार्ट 2 - query_post_execution इवेंट ओवरहेड

परीक्षणों के इस दौर के लिए, इस ईवेंट को केवल ईवेंट सत्र में सक्षम करने से कार्यभार का प्रदर्शन लगभग 30% कम हो जाता है, भले ही यह सर्वर पर फिर से चलाए जा रहे किसी भी ईवेंट के लिए सक्रिय नहीं होगा। समग्र गिरावट सर्वर के लिए वास्तविक कार्यभार पर निर्भर करेगी, और यह ध्यान रखना महत्वपूर्ण है कि परीक्षणों की यह श्रृंखला सबसे खराब स्थिति को दर्शाती है क्योंकि डिस्ट्रीब्यूटेड रिप्ले को स्ट्रेस मोड में चलाया गया था और SQL सर्वर पर CPU उपयोग आंका गया था। परीक्षणों के दौरान औसतन 94% पर।

प्रदर्शन प्रभाव को समझना

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

query_post_exection_showplan ईवेंट के लिए, सभी प्रदर्शन प्रभाव डेटा संग्रह से जुड़े ओवरहेड से होते हैं। यहां तक ​​​​कि उस मामले में जहां पांच सेकंड के बराबर अवधि के लिए एक विधेय है, केवल एक ईवेंट सत्र में ईवेंट को चालू करके, इसे सर्वर पर निष्पादित प्रत्येक कथन के लिए शोप्लान एक्सएमएल एकत्र करना होगा ताकि वह भविष्यवाणी का मूल्यांकन कर सके और फिर निर्धारित करें कि ईवेंट सक्रिय नहीं होगा। इस कारण से, उत्पादन कार्यभार के लिए query_post_execution_showplan घटना से बचना चाहिए। टेस्ट रीप्ले वर्कलोड के लिए, इवेंट का मूल्यांकन लगभग 440, 000 बार किया जाना था, भले ही यह वास्तव में वर्कलोड और इवेंट सेशन के परीक्षण के लिए फायर नहीं करता है क्योंकि रिप्ले इवेंट में से किसी में भी ठीक पांच सेकंड की अवधि नहीं होती है। इवेंट की गिनती की जानकारी इवेंट सेशन में इवेंट_काउंटर टारगेट जोड़कर और अवधि विधेय को हटाकर और फिर निम्नलिखित सत्र परिभाषा के साथ रीप्ले वर्कलोड को फिर से टेस्ट करके इकट्ठा की गई थी।

ईवेंट सत्र बनाएं [query_post_execution_showplan ओवरहेड] sqlserver.query_post_execution_showplanADD TARGET package0.event_counter;GO

तेजी से फायरिंग की घटनाओं की तुलना

इस प्रदर्शन प्रभाव के लिए संदर्भ का एक फ्रेम प्रदान करने के लिए हम सर्वर में बार-बार निष्पादित होने वाली घटनाओं के एक सेट को चालू करने और उसी रीप्ले वर्कलोड को निष्पादित करने के ऊपरी हिस्से को देख सकते हैं। SQL सर्वर में सबसे अधिक बार निष्पादित होने वाली घटनाओं में से दो हैं lock_acquired और lock_released ईवेंट। इन दो घटनाओं के ऊपरी हिस्से की तुलना करने के लिए, निम्नलिखित ईवेंट सत्र का उपयोग किया जा सकता है, जो बिना किसी विधेय के ईवेंट एकत्र करता है ताकि प्रत्येक निष्पादन एकत्र किया जा सके और यह गिन सके कि वे कितनी बार ईवेंट_काउंटर लक्ष्य का उपयोग करके आग लगाते हैं।

ईवेंट सत्र बनाएं [लॉकिंग ओवरहेड] sqlserver.lock_acquired,ईवेंट जोड़ें 

 हमारे रीप्ले वर्कलोड के लिए, ये दो घटनाएं लगभग 111,180,000 बार आग लगती हैं। इन घटनाओं को एकत्रित करने से जुड़े ओवरहेड को तालिका 3 और चार्ट 4 में देखा जा सकता है।
 

 
तालिका 3 - ओवरहेड तुलना लॉक करना 
 

 
 चार्ट 4 - लॉकिंग इवेंट ओवरहेड तुलना  
 

 जैसा कि आप डेटा से देख सकते हैं, इन घटनाओं का प्रदर्शन प्रभाव query_post_execution_showplan की तुलना में काफी कम है, भले ही लॉकिंग ईवेंट सत्र परिभाषा को सभी ईवेंट को सर्वर पर सक्रिय करने की अनुमति देने के लिए कॉन्फ़िगर किया गया था, कुल ओवरहेड कुल मिलाकर 1% से कम था . ध्यान रखें कि लॉकिंग इवेंट सेशन ने 500 गुना अधिक इवेंट के बराबर मूल्यांकन किया, और इस मामले में सभी इवेंट्स को इवेंट सेशन के लिए वास्तव में सक्रिय करना पड़ा, जहां query_post_execution_showplan इवेंट को मूल्यांकन के बाद वास्तव में सक्रिय नहीं होना था। 
सारांश
 

 जबकि query_post_execution_showplan घटना एक बयान के लिए वास्तविक क्वेरी योजना एकत्र करने की क्षमता प्रदान करती है जो निष्पादित होती है, केवल घटना का मूल्यांकन करने के लिए डेटा संग्रह का प्रदर्शन प्रभाव इसे कुछ ऐसा बनाता है जो उत्पादन उपयोग के लिए व्यवहार्य नहीं है। उत्पादन कार्यभार के विरुद्ध इस घटना का उपयोग करने से पहले कम से कम, ओवरहेड पर विचार किया जाना चाहिए। यहां तक ​​कि माइक्रोसॉफ्ट द्वारा प्रदान किया गया घटना विवरण भी स्वीकार करता है कि घटना का एक महत्वपूर्ण प्रदर्शन प्रभाव हो सकता है (मेरी हाइलाइटिंग):
 SQL कथन निष्पादित होने के बाद होता है। यह इवेंट वास्तविक क्वेरी योजना का XML प्रतिनिधित्व देता है। इस घटना का उपयोग करने से एक महत्वपूर्ण प्रदर्शन ओवरहेड हो सकता है, इसलिए इसका उपयोग केवल तभी किया जाना चाहिए जब कुछ समय के लिए विशिष्ट समस्याओं का निवारण या निगरानी की जाए। 

 घटना का विवरण sys.dm_xe_objects कैटलॉग दृश्य के विवरण कॉलम में या नए सत्र UI में पाया जा सकता है जैसा कि चित्र 5 (मेरी हाइलाइटिंग) में दिखाया गया है:
 

 
चित्र 5 - नए सत्र UI से ईवेंट विवरण 
 

 उत्पादन परिवेश में वास्तव में उपयोग करने से पहले मैं वर्णन में इस चेतावनी के साथ किसी भी घटना के प्रदर्शन को बेंचमार्क करने की अनुशंसा करता हूं।