क्वेरी लागत बनाम निष्पादन गति + समांतरता

Question

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

हमें बताया गया था कि 100 से अधिक पूछताछ लागत बहुत दुर्लभ होनी चाहिए, और 1000 से अधिक लागत वाले प्रश्न कभी नहीं चलना चाहिए। जिन समस्याओं में मैं दौड़ रहा हूं वे हैं कि लागत निष्पादन समय के साथ कोई सहसंबंध नहीं है, और मैं अपने प्रश्नों को अनुकूलित करने की कोशिश करते समय उत्पादकता खो रहा हूं।

उदाहरण के तौर पर, मेरे पास एक प्रश्न है जो 10844 की लागत के साथ 5 सेकंड के भीतर निष्पादित करता है। मैं उस दृश्य का उपयोग करने के लिए क्वेरी को फिर से लिखता हूं जिसमें मुझे आवश्यक अधिकांश जानकारी शामिल है, और लागत को 109 तक घटा दिया गया है, लेकिन नई क्वेरी, जो एक ही परिणाम प्राप्त करती है, चलाने के लिए 40 सेकंड लगती है। मैं एक संभावित व्याख्या के साथ यहां एक सवाल पाया:

Measuring Query Performance : "Execution Plan Query Cost" vs "Time Taken"

यही सवाल मुझे समानांतरवाद संकेत का नेतृत्व किया। मैंने लागत 10884 क्वेरी में /*+ no_parallel*/ का उपयोग करने की कोशिश की, लेकिन लागत में बदलाव नहीं हुआ, न ही निष्पादन का समय था, इसलिए मुझे यकीन नहीं है कि समांतरता तेजी से निष्पादन समय के लिए स्पष्टीकरण है लेकिन उच्च लागत। फिर, मैंने /*+ parallel(n)*/ संकेत का उपयोग करने का प्रयास किया, और पाया कि n का मूल्य जितना अधिक होगा, क्वेरी की लागत कम होगी। लागत 10844 क्वेरी के मामले में, मैंने पाया कि /*+ parallel(140)*/ ने निष्पादन समय में बहुत मामूली वृद्धि के साथ लागत को 9 7 कर दिया।

यह लग रहा था जैसे एक आदर्श "धोखा" आवश्यकताओं कि उल्लिखित हमारे आईटी विभाग से मिलने के लिए, लेकिन फिर मैं इस पढ़ें:

समानांतर:

http://www.oracle.com/technetwork/articles/datawarehouse/twp-parallel-execution-fundamentals-133639.pdf

लेख इस वाक्य में शामिल है निष्पादन सभी सिस्टम संसाधनों का उपयोग करने के लिए एक एकल ऑपरेशन को सक्षम कर सकता है।

तो, मेरे सवाल कर रहे हैं:

मैं वास्तव में अधिक तनाव सर्वर संसाधनों पर समानांतरवाद की एक बहुत ही उच्च स्तर के साथ /*+ parallel(n)*/ संकेत का उपयोग करके, रखकर कर रहा हूँ, भले ही मैं लागत को कम कर रहा हूँ?

कोई समांतरता मानते हुए, निष्पादन गति लागत से उपयोग किए जाने वाले संसाधनों का एक बेहतर उपाय है?

Answer 1

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

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

यदि आप एक मीट्रिक की तलाश में हैं जो आपको बताता है कि कोई क्वेरी प्लान उचित है, तो मैं लॉजिकल I/O की मात्रा का उपयोग करूंगा। लॉजिकल I/O वास्तविक क्वेरी प्रदर्शन के साथ और आपकी क्वेरी का उपभोग करने वाले संसाधनों की मात्रा के साथ बहुत अच्छी तरह से सहसंबंधित है। निष्पादन समय को देखते हुए समस्याग्रस्त हो सकता है क्योंकि यह कैश किए जाने वाले डेटा के आधार पर महत्वपूर्ण रूप से भिन्न होता है (यही कारण है कि पूछताछ अक्सर दूसरी बार निष्पादित होने पर अक्सर तेज़ी से चलती है) जबकि तार्किक I/O नहीं बदलता है कि डेटा क्या है कैश में इससे आपको अपनी अपेक्षाओं को स्केल करने की सुविधा मिलती है क्योंकि आपके प्रश्नों को पंक्तियों की संख्या में परिवर्तन को संसाधित करने की आवश्यकता होती है। यदि आप एक प्रश्न लिख रहे हैं जिसे 1 मिलियन पंक्तियों से डेटा एकत्र करने की आवश्यकता है, उदाहरण के लिए, उस क्वेरी से कहीं अधिक संसाधनों का उपभोग करना चाहिए, जिसमें किसी भी तालिका के बिना किसी तालिका के डेटा की 100 पंक्तियां वापस करने की आवश्यकता होती है। यदि आप तार्किक I/O को देख रहे हैं, तो आप यह समझने के लिए अपनी अपेक्षाओं को आसानी से स्केल कर सकते हैं कि आपके प्रश्न वास्तव में कितने कुशल हो सकते हैं।

ईसाई Antognini के दशक में "Troubleshooting Oracle Performance" (पेज 450), उदाहरण के लिए, वह अंगूठे कि बहुत उचित

• 5 तार्किक है का एक नियम देता पंक्ति है कि वापस लौटे/एकत्रित किया प्रति पढ़ता शायद बहुत अच्छा है
• 10 तार्किक पंक्ति कि लौटा दिया जाता है/एकत्रित किया प्रति पढ़ता शायद पर्याप्त
• 20+ तार्किक पंक्ति है कि वापस आ/एकत्रित किया शायद अक्षम है और

देखते किए जाने की आवश्यकता प्रति पढ़ता है

विभिन्न डेटा मॉडल वाले विभिन्न सिस्टम बाल्टी को थोड़ा सा ट्विक कर सकते हैं लेकिन वे अच्छे शुरुआती बिंदु होने की संभावना है।

मेरा अनुमान है कि यदि आप ऐसे शोधकर्ता हैं जो डेवलपर्स नहीं हैं, तो संभवतः आप उन प्रश्नों को चला रहे हैं जिन्हें कम से कम बड़े डेटा सेट एकत्र करने या लाने की आवश्यकता है, कम से कम उन अनुप्रयोगों की तुलना में जो डेवलपर्स आमतौर पर लिख रहे हैं। यदि आप कुछ समग्र परिणामों को उत्पन्न करने के लिए डेटा की दस लाख पंक्तियों को स्कैन कर रहे हैं, तो आपके प्रश्न स्वाभाविक रूप से एक एप्लिकेशन डेवलपर की तुलना में कहीं अधिक संसाधनों का उपभोग करने जा रहे हैं जिनके प्रश्न कुछ पंक्तियों को पढ़ रहे हैं या लिख ​​रहे हैं। आप ऐसे प्रश्न लिख रहे हैं जो प्रति पंक्ति परिप्रेक्ष्य में लॉजिकल I/O से उतने ही कुशल हैं, आप बस कई और पंक्तियों को देख सकते हैं।

यदि आप लाइव उत्पादन डेटाबेस के खिलाफ प्रश्न पूछ रहे हैं, तो आप अच्छी स्थिति में हो सकते हैं जहां वर्कलोड को अलग करना शुरू हो जाता है। अधिकांश संगठन ऐसे बिंदु तक पहुंचते हैं जहां लाइव डेटाबेस के विरुद्ध रिपोर्टिंग क्वेरी चलाना उत्पादन प्रणाली के लिए समस्याएं उत्पन्न करना शुरू कर देता है। इस तरह की समस्या का एक आम समाधान उत्पादन प्रणाली से खिलाया गया एक अलग रिपोर्टिंग डेटाबेस बनाना है (या तो रात के स्नैपशॉट के माध्यम से या चल रहे प्रतिकृति प्रक्रिया के माध्यम से) जहां रिपोर्टिंग प्रश्न उत्पादन अनुप्रयोग को परेशान किए बिना चला सकते हैं। उच्च प्राथमिकता उपयोगकर्ताओं (इस मामले में, उत्पादन के उपयोगकर्ता) पर प्रभाव को कम करने के लिए उपयोगकर्ताओं के एक समूह (इस मामले में, रिपोर्ट डेवलपर्स) को उपलब्ध संसाधनों की मात्रा को सीमित करने के लिए ओरेकल संसाधन प्रबंधक जैसे कुछ का उपयोग करना एक और आम समाधान है। प्रणाली)।