SAP HANA Cloud में SQL Analyzer के साथ पैरामीटराइज्ड क्वेरी प्लान की तुलना करना

संदर्भ: पैरामीटराइज्ड क्वेरी और प्रदर्शन में उतार-चढ़ाव

एक पैरामीटराइज्ड क्वेरी कुछ इनपुट मानों के लिए तेज़ और दूसरों के लिए धीमी हो सकती है क्योंकि डेटा वितरण विषम (skewed) होता है। ऑप्टिमाइज़र प्रति स्टेटमेंट एक प्लान कंपाइल करता है, और वह प्लान एक छोटे चयनात्मकता रेंज के लिए इष्टतम हो सकता है लेकिन बड़े रेंज के लिए खराब। उदाहरण के लिए, एक टेबल फंक्शन जो रीजन पैरामीटर स्वीकार करता है, वह रीजन DE के लिए 20 मिलीसेकंड में 50 पंक्तियाँ लौटा सकता है, लेकिन रीजन GLOBAL के लिए 4 सेकंड में 2 मिलियन पंक्तियाँ। यह अंतर जरूरी नहीं कि क्वेरी में कोई बग हो; यह अक्सर चयनात्मकता-निर्भर प्लान चयन होता है। पहला कदम प्रत्येक पैरामीटर सेट के लिए निष्पादन प्लान को कैप्चर करना और SQL Analyzer के साथ उनकी तुलना करना है। लक्ष्य यह तय करना है कि क्या उतार-चढ़ाव प्लान चयन के कारण है और क्या Plan Variants को सक्षम करना या क्वेरी को फिर से लिखना सही समाधान है।

SQL Analyzer व्यू, टेबल और ग्राफ का एक सेट है जो आपको किसी भी SQL क्वेरी का विश्लेषण करने की अनुमति देता है। आप ग्राफ निष्पादन में गहराई से जा सकते हैं, क्वेरी कंपाइलेशन और निष्पादन की समयरेखा का विश्लेषण कर सकते हैं, यह देख सकते हैं कि किन टेबल का उपयोग किया गया था, यह देख सकते हैं कि प्रत्येक स्टेप ने कितने रिकॉर्ड प्रोसेस किए, और ऑपरेटरों के क्रम की जांच कर सकते हैं। यह केवल कैलकुलेशन व्यू तक सीमित नहीं है; यह टेबल फंक्शन और SQL कंसोल स्टेटमेंट में परिभाषित SQL का विश्लेषण कर सकता है। इसका उपयोग करने के लिए, आपको डेवलपमेंट स्पेस में SAP HANA Performance Tools एक्सटेंशन जोड़ना होगा, और यह केवल तब किया जा सकता है जब डेवलपमेंट स्पेस रुका हुआ (stopped) हो। विश्लेषण करने वाले उपयोगकर्ता को TRACE ADMIN और INIFILE ADMIN सिस्टम विशेषाधिकारों की आवश्यकता होती है। वर्कफ़्लो पैरामीटराइज्ड SQL को SQL कंसोल में रखकर शुरू होता है, फिर Analyze Generate SQL Analyzer Plan File के साथ एक प्लान फाइल जेनरेट की जाती है, और अंत में प्लान फाइल को HANA SQL Analyzer व्यू में खोला जाता है।

प्लान फाइलें एम्बेडेड SAP HANA डेटाबेस एक्सप्लोरर से जेनरेट की जा सकती हैं, जहाँ प्लान फाइल सीधे SQL Analyzer व्यू में खुलती है, या बाहरी टूल से, जहाँ प्लान फाइल को डाउनलोड करना होगा और SAP बिजनेस एप्लीकेशन स्टूडियो के एक्सप्लोरर व्यू में अपलोड करना होगा। जेनरेट की गई प्लान फाइलों का स्थान निश्चित होता है और इसे बदला नहीं जा सकता है। यदि आप बाद में किसी प्लान फाइल का विश्लेषण करना चाहते हैं, तो आप इसे एक्सप्लोरर व्यू से या बाहरी डेटाबेस एक्सप्लोरर के तहत Catalog Database Diagnostic Files DB Instance ID other से एक्सेस कर सकते हैं। मुख्य बात यह है कि आपको तुलना करने के लिए प्रत्येक पैरामीटर मान के लिए एक अलग प्लान फाइल की आवश्यकता होती है। जब पैरामीटर मानों में चयनात्मकता भिन्न होती है, तो एक कैश किया गया प्लान पर्याप्त नहीं होता है।

तुलना स्टेप-लेवल निष्पादन समय, प्रोसेस किए गए रिकॉर्ड काउंट और ऑपरेटर सीक्वेंस पर केंद्रित होनी चाहिए। एक स्टेप जो दूसरों की तुलना में काफी अधिक समय लेता है, या एक स्टेप जो उम्मीद से कहीं अधिक रिकॉर्ड प्रोसेस करता है, वह एक बॉटलनेक है। ऑपरेटर सीक्वेंस आपको बताता है कि क्या ऑप्टिमाइज़र ने अलग जॉइन ऑर्डर, अलग एक्सेस पाथ या अलग प्रोसेसिंग इंजन चुना। यदि धीमी पैरामीटर वैल्यू के लिए प्लान अलग है, तो आप या तो Plan Variants को सक्षम कर सकते हैं ताकि HANA फ़िल्टर चयनात्मकता क्लस्टर के आधार पर कई प्लान कैश कर सके, या क्वेरी को फिर से लिख सकते हैं और मॉडल को पुनर्गठित कर सकते हैं ताकि ऑप्टिमाइज़र सभी चयनात्मकता रेंज में एक स्थिर प्लान तैयार करे। निर्णय इस बात पर निर्भर करता है कि क्या ऑप्टिमाइज़र चयनात्मकता क्लस्टर को अलग कर सकता है और क्या क्वेरी स्ट्रक्चर मौलिक रूप से कुशल है।

Plan Variants SAP HANA को टेबल फ़िल्टर की चयनात्मकता के आधार पर पैरामीटराइज्ड क्वेरी के लिए कई निष्पादन प्लान कैश करने की अनुमति देते हैं। ऑप्टिमाइज़र प्रेडिकेट्स का मूल्यांकन करता है, प्लान कंपाइल करता है, और फ़िल्टर मानों को क्लस्टर के साथ जोड़ता है। यह प्रदर्शन के उतार-चढ़ाव को कम करता है और अधिक स्थिर क्वेरी प्रदर्शन सुनिश्चित करता है। हालांकि, Plan Variants केवल तब मदद करते हैं जब ऑप्टिमाइज़र पैरामीटर मानों को अलग-अलग चयनात्मकता क्लस्टर में समूहबद्ध कर सकता है। यदि क्वेरी स्ट्रक्चर सभी इनपुट के लिए स्वाभाविक रूप से अक्षम है, या यदि ऑप्टिमाइज़र क्लस्टर को अलग नहीं कर पाता है, तो केवल प्लान प्रबंधन समस्या को हल नहीं करेगा। उस स्थिति में, क्वेरी को फिर से लिखना या मॉडल को पुनर्गठित करना एकमात्र विकल्प बचता है।

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

एक ठोस उदाहरण वह टेबल फंक्शन है जो रीजन पैरामीटर स्वीकार करता है। रीजन DE के लिए क्वेरी 20 मिलीसेकंड में 50 पंक्तियाँ लौटाती है; रीजन GLOBAL के लिए यह 4 सेकंड में 2 मिलियन पंक्तियाँ लौटाती है। दोनों पैरामीटराइज्ड कॉल को SQL कंसोल में रखें, दो प्लान फाइलें जेनरेट करें, उन्हें SQL Analyzer में अगल-बगल खोलें, और देखें कि GLOBAL के लिए ऑप्टिमाइज़र ने DE के लिए उपयोग किए गए इंडेक्स-सीक-प्लस-हैश-जॉइन के बजाय नेस्टेड-लूप जॉइन के साथ फुल कॉलम-स्टोर स्कैन चुना। यह पुष्टि करता है कि प्लान पैरामीटर मान के अनुसार भिन्न होता है और सुझाव देता है कि या तो Plan Variants को सक्षम करें ताकि दोनों प्लान कैश हो जाएं, या जॉइन ऑर्डर और फ़िल्टर पुशडाउन को फिर से लिखें ताकि ऑप्टिमाइज़र सभी चयनात्मकता रेंज में एक स्थिर प्लान तैयार करे।

SELECT * FROM TABLE(TABLE_FUNCTION(:region)) WHERE region = :region;

तर्क: Plan Variants बनाम क्वेरी रीराइटिंग

एक पैरामीटराइज्ड क्वेरी एक एकल निष्पादन प्लान के साथ कैश की जाती है, लेकिन वह प्लान एक समझौता होता है। जब एक फ़िल्टर की चयनात्मकता बदलती है, तो इष्टतम प्लान भी बदल सकता है। यदि ऑप्टिमाइज़र चयनात्मकता क्लस्टर को अलग नहीं कर पाता है, तो वह ऐसा प्लान चुन सकता है जो कुछ मानों के लिए अच्छा और दूसरों के लिए बुरा हो। यह SQL प्रदर्शन में उतार-चढ़ाव का मूल कारण है। Plan Variants टेबल फ़िल्टर की चयनात्मकता के आधार पर SAP HANA को पैरामीटराइज्ड क्वेरी के लिए कई प्लान कैश करने की अनुमति देकर इसे संबोधित करते हैं। ऑप्टिमाइज़र प्रेडिकेट्स का मूल्यांकन करता है, प्लान कंपाइल करता है, और फ़िल्टर मानों को क्लस्टर के साथ जोड़ता है। इसका मतलब है कि सिस्टम एक छोटे, चयनात्मक रेंज के लिए एक प्लान और एक बड़े, गैर-चयनात्मक रेंज के लिए एक अलग प्लान रख सकता है।

केवल एक निष्पादन प्लान कैश करने की सीमा यह है कि यह डेटा वितरण परिवर्तनों के अनुकूल नहीं हो सकता है। एक प्लान जो छोटे परिणाम सेट के लिए इष्टतम है, वह बड़े परिणाम सेट के लिए भयानक हो सकता है क्योंकि यह नेस्टेड-लूप जॉइन या फुल स्कैन का उपयोग करता है। Plan Variants प्रत्येक चयनात्मकता क्लस्टर के लिए अलग प्लान बनाकर इसे हल करते हैं। ऑप्टिमाइज़र तय करता है कि पैरामीटर मान किस क्लस्टर से संबंधित है और संबंधित प्लान का उपयोग करता है। यह प्रदर्शन के उतार-चढ़ाव को कम करता है और अधिक स्थिर क्वेरी प्रदर्शन सुनिश्चित करता है। मॉनिटरिंग व्यू M_SQL_PLAN_VARIANTS और M_SQL_PLAN_VARIANT_STATISTICS सक्रिय Plan Variants और उनके निष्पादन सांख्यिकी दिखाते हैं, ताकि आप सत्यापित कर सकें कि क्लस्टर सही ढंग से बनाए गए थे और प्लान का उपयोग किया जा रहा है।

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

वर्कफ़्लो प्रत्येक पैरामीटर मान के लिए प्लान फाइलें जेनरेट करना, SQL Analyzer में उनकी तुलना करना और फिर यह तय करना है कि Plan Variants या रीराइटिंग की आवश्यकता है। यदि प्लान फाइलें अलग ऑपरेटर सीक्वेंस, रिकॉर्ड काउंट या स्टेप टाइमिंग दिखाती हैं, तो ऑप्टिमाइज़र पहले से ही पैरामीटर मानों को अलग कर रहा है। तब Plan Variants को सक्षम करने से उतार-चढ़ाव कम हो सकता है। यदि प्लान फाइलें एक ही प्लान दिखाती हैं लेकिन वह प्लान किसी विशिष्ट पैरामीटर मान के लिए धीमा है, तो ऑप्टिमाइज़र क्लस्टर को अलग नहीं कर रहा है, और रीराइटिंग की संभावना है। मॉनिटरिंग व्यू यह सत्यापित करने में मदद करते हैं कि Plan Variants सक्रिय हैं और निष्पादन सांख्यिकी अपेक्षित चयनात्मकता क्लस्टर से मेल खाती है।

मुख्य अंतर प्लान प्रबंधन और क्वेरी स्ट्रक्चर के बीच है। Plan Variants एक पैरामीटराइज्ड क्वेरी के लिए कई प्लान प्रबंधित करते हैं, लेकिन वे ऐसी क्वेरी को ठीक नहीं करते जिसका स्ट्रक्चर सभी इनपुट के लिए अक्षम है। यदि ऑप्टिमाइज़र चयनात्मकता क्लस्टर को अलग नहीं कर सकता है, या यदि डेटा स्क्यू चरम पर है, तो क्वेरी को फिर से लिखना होगा। SQL Analyzer के प्रमाण निर्णय का मार्गदर्शन करने चाहिए। प्लान फाइलें दिखाती हैं कि क्या ऑप्टिमाइज़र अलग-अलग पैरामीटर मानों के लिए अलग-अलग प्लान चुन रहा है, और क्या वे प्लान स्थिर हैं। यदि प्लान स्थिर हैं लेकिन किसी विशिष्ट पैरामीटर मान के लिए धीमे हैं, तो क्वेरी स्ट्रक्चर समस्या है। यदि प्लान भिन्न हैं लेकिन बड़े चयनात्मकता रेंज के लिए धीमा प्लान चुना जाता है, तो Plan Variants पर्याप्त हो सकते हैं।

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

एक ठोस उदाहरण वह टेबल फंक्शन है जो रीजन पैरामीटर स्वीकार करता है। रीजन DE के लिए क्वेरी 20 मिलीसेकंड में 50 पंक्तियाँ लौटाती है; रीजन GLOBAL के लिए यह 4 सेकंड में 2 मिलियन पंक्तियाँ लौटाती है। दोनों पैरामीटराइज्ड कॉल को SQL कंसोल में रखें, दो प्लान फाइलें जेनरेट करें, उन्हें SQL Analyzer में अगल-बगल खोलें, और देखें कि GLOBAL के लिए ऑप्टिमाइज़र ने DE के लिए उपयोग किए गए इंडेक्स-सीक-प्लस-हैश-जॉइन के बजाय नेस्टेड-लूप जॉइन के साथ फुल कॉलम-स्टोर स्कैन चुना। यह पुष्टि करता है कि प्लान पैरामीटर मान के अनुसार भिन्न होता है और सुझाव देता है कि या तो Plan Variants को सक्षम करें ताकि दोनों प्लान कैश हो जाएं, या जॉइन ऑर्डर और फ़िल्टर पुशडाउन को फिर से लिखें ताकि ऑप्टिमाइज़र सभी चयनात्मकता रेंज में एक स्थिर प्लान तैयार करे।

SELECT * FROM M_SQL_PLAN_VARIANTS WHERE SCHEMA_NAME = '<container_schema_name>' AND OBJECT_NAME = '<calculation_view_or_function>';

ठोस उदाहरण: SQL Analyzer में प्लान फाइलों की तुलना करना

कार्यप्रवाह की शुरुआत SQL कंसोल में पैरामीटराइज्ड SQL रखकर होती है। आपको क्वेरी चलाने की आवश्यकता नहीं है; आपको केवल प्लान फाइल जेनरेट करने की आवश्यकता है। Analyze Generate SQL Analyzer Plan File मेनू विकल्प का उपयोग करें, एक फाइल नाम प्रीफिक्स चुनें और सेव करें। लोकेशन पहले से सेट है और इसे बदला नहीं जा सकता है। यदि SQL कंसोल को एम्बेडेड SAP HANA डेटाबेस एक्सप्लोरर से खोला गया था, तो प्लान फाइल तुरंत HANA SQL Analyzer व्यू में खुल जाती है। यदि प्लान फाइल किसी अन्य टूल, जैसे डेटा प्रीव्यू या बाहरी SAP HANA डेटाबेस एक्सप्लोरर से जेनरेट की गई थी, तो आपको प्लान फाइल डाउनलोड करनी होगी और उसे SAP बिजनेस एप्लीकेशन स्टूडियो के एक्सप्लोरर व्यू में अपलोड करना होगा। डेवलपमेंट स्पेस में SAP HANA Performance Tools एक्सटेंशन जोड़ा जाना चाहिए, और यह केवल तभी किया जा सकता है जब डेवलपमेंट स्पेस बंद हो।

एक बार प्लान फाइल अपलोड हो जाने के बाद, मुख्य विंडो में परिणाम प्रदर्शित करने के लिए इसे चुनें। SQL Analyzer व्यू निष्पादन योजना (execution plan) को एक ग्राफ के रूप में दिखाता है, जिसमें स्टेप-लेवल निष्पादन समय, प्रोसेस किए गए रिकॉर्ड की संख्या और ऑपरेटर सीक्वेंस होता है। आप ग्राफ निष्पादन में गहराई से जा सकते हैं, क्वेरी कंपाइलेशन और निष्पादन की समयरेखा का विश्लेषण कर सकते हैं, और यह देख सकते हैं कि कितनी टेबल का उपयोग किया गया था। लक्ष्य उन स्टेप्स की पहचान करना है जिनमें दूसरों की तुलना में काफी अधिक समय लगता है, वे स्टेप्स जो उम्मीद से कहीं अधिक रिकॉर्ड प्रोसेस करते हैं, और वे ऑपरेटर सीक्वेंस जो पैरामीटर वैल्यू के बीच भिन्न होते हैं। ये चयनात्मकता-निर्भर (selectivity-dependent) प्लान चयन के संकेत हैं।

ठोस उदाहरण के लिए, दो प्लान फाइलें जेनरेट करें: एक रीजन DE के लिए और एक रीजन GLOBAL के लिए। SQL Analyzer में दोनों फाइलें खोलें और उनकी साथ-साथ तुलना करें। रीजन DE के लिए, प्लान में एक इंडेक्स सीक और एक हैश जॉइन दिखना चाहिए, जिसमें प्रोसेस किए गए रिकॉर्ड की संख्या कम होगी। रीजन GLOBAL के लिए, प्लान में एक फुल कॉलम-स्टोर स्कैन और एक नेस्टेड-लूप जॉइन दिखना चाहिए, जिसमें प्रोसेस किए गए रिकॉर्ड की संख्या अधिक होगी। स्टेप-लेवल निष्पादन समय और रिकॉर्ड काउंट इस अंतर की पुष्टि करेंगे। यह प्रमाण दर्शाता है कि ऑप्टिमाइज़र ने धीमी पैरामीटर वैल्यू के लिए एक अलग प्लान चुना, और यह सुझाव देता है कि प्लान वेरिएंट्स या क्वेरी रीराइटिंग की आवश्यकता है।

तुलना ऑपरेटर सीक्वेंस पर केंद्रित होनी चाहिए, क्योंकि यह प्रकट करता है कि क्या ऑप्टिमाइज़र ने एक अलग जॉइन ऑर्डर, एक्सेस पाथ या प्रोसेसिंग इंजन चुना है। इंडेक्स सीक के बजाय फुल कॉलम-स्टोर स्कैन चयनात्मकता बेमेल (selectivity mismatch) का एक सामान्य संकेत है। हैश जॉइन के बजाय नेस्टेड-लूप जॉइन एक और संकेत है। प्रत्येक स्टेप पर प्रोसेस किए गए रिकॉर्ड काउंट आपको बताते हैं कि प्लान कितना डेटा हैंडल कर रहा है। यदि कोई स्टेप लाखों पंक्तियों को प्रोसेस करता है जबकि उसे दर्जनों प्रोसेस करना चाहिए, तो वह स्टेप एक बॉटलनैक है। क्वेरी कंपाइलेशन और निष्पादन की समयरेखा आपको यह देखने में मदद करती है कि धीमापन कंपाइलेशन में है, निष्पादन में है, या किसी विशिष्ट ऑपरेटर में है।

तुलना के बाद, आप यह तय कर सकते हैं कि प्लान वेरिएंट्स को सक्षम करना है या क्वेरी को रीराइट करना है। यदि प्लान फाइलें अलग-अलग पैरामीटर वैल्यू के लिए अलग-अलग प्लान दिखाती हैं, और ऑप्टिमाइज़र चयनात्मकता क्लस्टर्स (selectivity clusters) के बीच अंतर कर सकता है, तो प्लान वेरिएंट्स को सक्षम करने से उतार-चढ़ाव कम हो सकता है। यदि प्लान फाइलें एक ही प्लान दिखाती हैं लेकिन वह प्लान किसी विशिष्ट पैरामीटर वैल्यू के लिए धीमा है, तो ऑप्टिमाइज़र क्लस्टर्स के बीच अंतर नहीं कर पा रहा है, और रीराइटिंग की संभावना है। मॉनिटरिंग व्यू M_SQL_PLAN_VARIANTS और M_SQL_PLAN_VARIANT_STATISTICS यह सत्यापित कर सकते हैं कि प्लान वेरिएंट्स सक्रिय हैं और निष्पादन आंकड़े अपेक्षित चयनात्मकता क्लस्टर्स से मेल खाते हैं।

ठोस उदाहरण एक टेबल फंक्शन है जो रीजन पैरामीटर स्वीकार करता है। रीजन DE के लिए क्वेरी 20 मिलीसेकंड में 50 पंक्तियाँ लौटाती है; रीजन GLOBAL के लिए यह 4 सेकंड में 2 मिलियन पंक्तियाँ लौटाती है। दोनों पैरामीटराइज्ड कॉल्स को SQL कंसोल में रखें, दो प्लान फाइलें जेनरेट करें, उन्हें SQL Analyzer में साथ-साथ खोलें, और देखें कि GLOBAL के लिए ऑप्टिमाइज़र ने DE के लिए उपयोग किए गए इंडेक्स-सीक-प्लस-हैश-जॉइन के बजाय नेस्टेड-लूप जॉइन के साथ फुल कॉलम-स्टोर स्कैन चुना। यह पुष्टि करता है कि प्लान पैरामीटर वैल्यू के अनुसार भिन्न होता है और सुझाव देता है कि या तो प्लान वेरिएंट्स को सक्षम किया जाए ताकि दोनों प्लान कैश हो सकें, या जॉइन ऑर्डर और फिल्टर पुशडाउन को रीराइट किया जाए ताकि ऑप्टिमाइज़र सभी चयनात्मकता श्रेणियों में एक स्थिर प्लान तैयार करे।

EXPLAIN PLAN FOR SELECT * FROM TABLE(TABLE_FUNCTION(:region)) WHERE region = :region;

उपयोगिता सीमाएं

SQL Analyzer को डेवलपमेंट स्पेस में SAP HANA Performance Tools एक्सटेंशन की आवश्यकता होती है, और वह एक्सटेंशन केवल तभी जोड़ा जा सकता है जब डेवलपमेंट स्पेस बंद हो। यह एक पूर्व शर्त है जिसे कार्यप्रवाह शुरू करने से पहले सत्यापित किया जाना चाहिए। विश्लेषण करने वाले उपयोगकर्ता को TRACE ADMIN और INIFILE ADMIN सिस्टम प्रिविलेज की आवश्यकता होती है। ये प्रिविलेज सिस्टम-लेवल हैं और उत्पादन (production) में एप्लीकेशन उपयोगकर्ताओं को नहीं दिए जा सकते हैं, इसलिए यह कार्यप्रवाह सभी उपयोगकर्ताओं के लिए उपलब्ध नहीं हो सकता है। एम्बेडेड SAP HANA डेटाबेस एक्सप्लोरर के बाहर जेनरेट की गई प्लान फाइलों को मैन्युअल रूप से डाउनलोड और अपलोड करना होगा, जिससे कार्यप्रवाह में एक अतिरिक्त स्टेप जुड़ जाता है। जेनरेट की गई प्लान फाइलों की लोकेशन निश्चित है और इसे बदला नहीं जा सकता है, जो प्रक्रिया को जटिल बना सकता है।

प्लान वेरिएंट्स केवल तब मदद करते हैं जब ऑप्टिमाइज़र पैरामीटर वैल्यू को अलग-अलग चयनात्मकता क्लस्टर्स में समूहबद्ध कर सके। वे ऐसी क्वेरी को ठीक नहीं करते जिसकी संरचना सभी इनपुट के लिए स्वाभाविक रूप से अक्षम है। यदि ऑप्टिमाइज़र चयनात्मकता क्लस्टर्स के बीच अंतर नहीं कर पाता है, या यदि डेटा स्क्यू (data skew) अत्यधिक है, तो केवल प्लान प्रबंधन समस्या को हल नहीं करेगा। उस स्थिति में, क्वेरी को रीराइट करना या मॉडल को पुनर्गठित करना ही एकमात्र विकल्प बचता है। मॉनिटरिंग व्यू M_SQL_PLAN_VARIANTS और M_SQL_PLAN_VARIANT_STATISTICS आपको यह सत्यापित करने में मदद कर सकते हैं कि ऑप्टिमाइज़र ने अपेक्षित क्लस्टर्स बनाए हैं और प्लान का उपयोग किया जा रहा है, लेकिन वे अंतर्निहित क्वेरी संरचना को नहीं बदलते हैं।

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

ठोस उदाहरण एक टेबल फंक्शन है जो रीजन पैरामीटर स्वीकार करता है। रीजन DE के लिए क्वेरी 20 मिलीसेकंड में 50 पंक्तियाँ लौटाती है; रीजन GLOBAL के लिए यह 4 सेकंड में 2 मिलियन पंक्तियाँ लौटाती है। दोनों पैरामीटराइज्ड कॉल्स को SQL कंसोल में रखें, दो प्लान फाइलें जेनरेट करें, उन्हें SQL Analyzer में साथ-साथ खोलें, और देखें कि GLOBAL के लिए ऑप्टिमाइज़र ने DE के लिए उपयोग किए गए इंडेक्स-सीक-प्लस-हैश-जॉइन के बजाय नेस्टेड-लूप जॉइन के साथ फुल कॉलम-स्टोर स्कैन चुना। यह पुष्टि करता है कि प्लान पैरामीटर वैल्यू के अनुसार भिन्न होता है और सुझाव देता है कि या तो प्लान वेरिएंट्स को सक्षम किया जाए ताकि दोनों प्लान कैश हो सकें, या जॉइन ऑर्डर और फिल्टर पुशडाउन को रीराइट किया जाए ताकि ऑप्टिमाइज़र सभी चयनात्मकता श्रेणियों में एक स्थिर प्लान तैयार करे।

SELECT * FROM M_SQL_PLAN_VARIANTS WHERE SCHEMA_NAME = '<container_schema_name>' AND OBJECT_NAME = '<calculation_view_or_function>';