अधिकांश संकेत अनुकूलक के लिए हमारे इरादे को संप्रेषित करने का एक तरीका है। उदाहरण के लिए, leading आपके द्वारा उल्लेखित संकेत का अर्थ है इस क्रम में तालिकाओं में शामिल हों . यह क्यों जरूरी है? अक्सर ऐसा इसलिए होता है क्योंकि इष्टतम जॉइन ऑर्डर स्पष्ट नहीं होता है, क्योंकि क्वेरी बुरी तरह से लिखी गई है या डेटाबेस आंकड़े गलत हैं।
तो leading . जैसे संकेतों का एक उपयोग सर्वोत्तम निष्पादन पथ का पता लगाना है, फिर यह पता लगाना है कि डेटाबेस संकेत के बिना उस योजना का चयन क्यों नहीं करता है। क्या ताजा आंकड़े इकट्ठा करने से समस्या का समाधान हो जाता है? क्या FROM क्लॉज को फिर से लिखने से समस्या हल हो जाती है? यदि ऐसा है, तो हम संकेतों को हटा सकते हैं और नग्न SQL को परिनियोजित कर सकते हैं।
कभी-कभी ऐसे समय होते हैं जब हम इस पहेली को हल नहीं कर पाते हैं, और उत्पादन में संकेत रखने पड़ते हैं। हालांकि यह एक दुर्लभ अपवाद होना चाहिए। Oracle के पास कई वर्षों से लागत-आधारित अनुकूलक पर काम करने वाले बहुत होशियार लोग हैं, इसलिए इसके निर्णय आमतौर पर हमारे निर्णय से बेहतर होते हैं।
लेकिन ऐसे अन्य संकेत हैं जिन्हें हम प्रोडक्शन में देखने के लिए पलक नहीं झपकाएंगे। append थोक आवेषण ट्यूनिंग के लिए अक्सर महत्वपूर्ण होता है। driving_site वितरित प्रश्नों को ट्यून करने में महत्वपूर्ण हो सकता है।
इसके विपरीत अन्य संकेतों का लगभग हमेशा दुरुपयोग किया जाता है। हाँ parallel , मैं तुम्हारे बारे में बात कर रहा हूं। आँख बंद करके /*+ parallel (t23, 16) */ लगाना संभवत:आपकी क्वेरी को सोलह गुना तेज नहीं चलाएगा, और न ही कभी-कभी धीमे में परिणाम देगा एकल-थ्रेडेड निष्पादन की तुलना में पुनर्प्राप्ति।
इसलिए, संक्षेप में, हमें संकेतों का उपयोग कब करना चाहिए, इस बारे में कोई सार्वभौमिक रूप से लागू सलाह नहीं है। मुख्य बातें हैं:
- समझें कि डेटाबेस कैसे काम करता है, और विशेष रूप से लागत-आधारित अनुकूलक कैसे काम करता है;
- समझें कि प्रत्येक संकेत क्या करता है;
- उत्पादन-समकक्ष डेटा के साथ उचित ट्यूनिंग वातावरण में संकेतित प्रश्नों का परीक्षण करें।
स्पष्ट रूप से शुरू करने के लिए सबसे अच्छी जगह है Oracle प्रलेखन . हालांकि, अगर आपको कुछ पैसे खर्च करने का मन है, तो जोनाथन लुईस की पुस्तक लागत-आधारित अनुकूलक सबसे अच्छा निवेश है जो आप कर सकते हैं।
