सरल DELETE, लेकिन जटिल निष्पादन योजना

Question

जब मैं इसे हटाता हूं:

DELETE FROM ETLHeaders WHERE ETLHeaderID < 32465870

... यह 39,157 पंक्तियों को हटाता है। यह सरल होना चाहिए क्योंकि यह ETLHeaderID पर हटा रहा है जो क्लस्टर इंडेक्स और प्राथमिक कुंजी है। लेकिन (निष्पादन योजना के अनुसार) यह 361,190 पंक्तियों को मारता हुआ और अन्य सूचकांक का उपयोग करता हुआ प्रतीत होता है। तालिका में XML डेटा प्रकार (इस DELETE को प्रभावित करने वाली स्थिति) के साथ एक फ़ील्ड है।

कोई भी विचार क्यों और कैसे मैं इस DELETE को गति दे सकता हूं?

यहाँ निष्पादन योजना: http://sharetext.org/qwDY तालिका स्कीमा यहाँ: http://sharetext.org/Vl9j

धन्यवाद

Answer 1

योजना के शीर्ष स्तर बेस टेबल (क्लस्टर इंडेक्स) से पंक्तियों को हटाने और चार गैर-अनुक्रमित इंडेक्स को बनाए रखने से संबंधित हैं। इनमें से दो इंडेक्स को पंक्ति-दर-पंक्ति बनाए रखा जाता है उसी समय क्लस्टर इंडेक्स विलोपन को संसाधित किया जाता है। ये "+2 गैर-क्लस्टर किए गए अनुक्रमित" हैं जो नीचे हरे रंग में हाइलाइट किए गए हैं।

अन्य दो गैर-अनुक्रमित अनुक्रमितों के लिए, ऑप्टिमाइज़र ने निर्णय लिया है कि इन अनुक्रमितों की कुंजियों को एक टेम्पर्ड वर्कटेबल (ईगर स्पूल) में सहेजना सबसे अच्छा है, फिर क्रमिक पहुंच पैटर्न को बढ़ावा देने के लिए सूचकांक कुंजियों को छाँटते हुए दो बार स्पूल चलाएं।

संचालन का अंतिम अनुक्रम प्राथमिक और द्वितीयक xmlअनुक्रमिकाओं को बनाए रखने से संबंधित है , जो आपकी DDL स्क्रिप्ट में शामिल नहीं थे:

इस बारे में बहुत कुछ किया जाना बाकी है। xmlआधार तालिका में डेटा के साथ गैर-अनुक्रमित अनुक्रमित और अनुक्रमित को सिंक्रनाइज़ रखा जाना चाहिए। इस तरह के सूचकांक को बनाए रखने की लागत एक टेबल पर अतिरिक्त सूचकांक बनाते समय आपके द्वारा किए गए ट्रेड-ऑफ का हिस्सा है।

इसने कहा, xmlसूचकांक विशेष रूप से समस्याग्रस्त हैं। ऑप्टिमाइज़र के लिए यह आकलन करना बहुत कठिन है कि इस स्थिति में कितनी पंक्तियाँ योग्य होंगी। वास्तव में, यह xmlसूचकांक के लिए बेतहाशा अधिक अनुमान लगाता है , जिसके परिणामस्वरूप इस क्वेरी के लिए लगभग 12GB मेमोरी दी जा रही है (हालांकि रनटाइम में केवल 28MB का उपयोग किया जाता है):

आप अधिक मेमोरी अनुदान के प्रभाव को कम करने की उम्मीद में, छोटे बैचों में विलोपन करने पर विचार कर सकते हैं।

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

Answer 2

आप सही रास्ते पर हैं - XML ​​इंडेक्स समस्या है। जाहिर है, वहाँ एक प्राथमिक और साथ ही एक माध्यमिक XML सूचकांक है।

बेस टेबल (ETLHeaders) के खिलाफ DELETE करते समय डेटा को इस तालिका के प्रत्येक सूचकांक से भी हटाना पड़ता है। यह ओवरहेड महत्वपूर्ण हो सकता है, खासकर XML इंडेक्स के लिए।

लंबी अवधि का सूचकांक वाला सूचकांक माध्यमिक XML सूचकांक [XML_IX_ETLHeaders_Property] है। आपकी "संबंधपरक तालिका" में 39,157 पंक्तियाँ प्राथमिक XML सूचकांक [XML_IX_ETLHeaders] में 361,909 पंक्तियों को संदर्भित करती हैं। और उन 361k पंक्तियों को क्रमबद्ध करने की आवश्यकता है ताकि माध्यमिक सूचकांक को हटाने के लिए उपयोग किया जा सके। और यह सॉर्ट ऑपरेशन क्वेरी की लंबी अवधि का कारण बन रहा है। (एक साइड नोट के रूप में, दोनों xml इंडेक्स के इंडेक्स आँकड़े इस तरह से दिखते हैं: प्राइमरी xml इंडेक्स की 361k पंक्तियों का वास्तविक डेटा साइज़ 160MB है जबकि अनुमानित डेटा साइज़ लगभग 4TB है (हाँ, 4 TerraBitte!)) !! ।

इस क्वेरी को गति देने के लिए एकमात्र विकल्प मैं माध्यमिक XML इंडेक्स को समाप्त करना चाहता हूं। डेटा के आधार पर यह एक बेहतर विकल्प हो सकता है कि XML डेटा को रिलेशनल टेबल में डाल दिया जाए।