शून्य की जांच इस क्वेरी को धीमा क्यों करती है?

निष्पादन गति में उस तरह के अंतर को प्राप्त करने का एकमात्र तरीका यह होगा कि (ए) field4 पर एक अनुक्रमणिका हो , और (बी) के पास लॉट . है खाली डेटा ब्लॉक; संभवतः एक उच्च जल चिह्न से जो बार-बार प्रत्यक्ष-पथ भार द्वारा बहुत ऊंचा सेट किया गया हो।

पहली क्वेरी अभी भी अनुक्रमणिका का उपयोग करेगी और अपेक्षा के अनुरूप प्रदर्शन करेगी। लेकिन चूंकि शून्य मानों को अनुक्रमित नहीं किया जाता है, इसलिए अनुक्रमणिका का उपयोग or field4 is null की जांच के लिए नहीं किया जा सकता है। स्थिति, इसलिए यह एक पूर्ण तालिका स्कैन पर वापस आ जाएगा।

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

बहुत सारे खाली डेटा ब्लॉक प्राप्त करने का सबसे सरल तरीका है कि बहुत सारा डेटा हो और फिर उसमें से अधिकांश को हटा दें। लेकिन मेरा मानना ​​है कि आपने पहले के एक प्रश्न पर अब हटाई गई टिप्पणी में कहा था कि प्रदर्शन ठीक हुआ करता था और खराब हो गया है। ऐसा तब हो सकता है जब आप डायरेक्ट-पाथ इंसर्ट करते हैं , खासकर यदि आप डेटा को हटाकर और फिर डायरेक्ट-पाथ मोड में नया डेटा डालकर 'रीफ्रेश' करते हैं। आप ऐसा इन्सर्ट के साथ कर सकते हैं जिसमें /*+ append */ . हो संकेत देना; या समानांतर में; या एसक्यूएल * लोडर के माध्यम से। हर बार जब आपने ऐसा किया कि उच्च जल चिह्न हिल जाएगा, क्योंकि पुराने खाली ब्लॉकों का पुन:उपयोग नहीं किया जाएगा; और हर बार नल की जांच करने वाली क्वेरी का प्रदर्शन थोड़ा कम हो जाएगा। बहुत सारे पुनरावृत्तियों के बाद जो वास्तव में जुड़ना शुरू हो जाएगा।

alter table mytable move;