अंतर यह है कि, आंकड़े एकत्र करना वर्तमान सूचकांक के बारे में मेटाडेटा को ताज़ा करता है जबकि सूचकांक को गिराना और फिर से बनाना, सूचकांक को गिराना और फिर से बनाना है।
शायद काम किए गए उदाहरण से अंतर को समझना आसान है। तो चलिए एक टेबल और एक इंडेक्स बनाते हैं:
SQL> create table t23
2 as select object_id as id, object_name as name from user_objects
3 /
Table created.
SQL> create index i23 on t23(id)
2 /
Index created.
SQL> select o.object_id, i.last_analyzed, i.distinct_keys
2 from user_objects o
3 join user_indexes i
4 on (i.index_name = o.object_name)
5 where o.object_type = 'INDEX'
6 and i.index_name = 'I23'
7 /
OBJECT_ID CREATED LAST_ANALYZED DISTINCT_KEYS
---------- -------------------- -------------------- -------------
116353 23-NOV-2013 00:15:39 23-NOV-2013 00:15:39 167
1 row selected.
SQL>
चूंकि 11g Oracle स्वचालित रूप से आंकड़े इकट्ठा करता है जब हम एक इंडेक्स बनाते हैं। तो सूचकांक निर्माण और अंतिम विश्लेषण एक ही डेटाटाइम दिखाते हैं। पिछले संस्करणों में हमें इंडेक्स बनाने के बाद स्पष्ट रूप से आंकड़े इकट्ठा करने पड़ते थे। और जानें ।
इसके बाद, हम कुछ डेटा जोड़ेंगे और आँकड़ों को ताज़ा करेंगे:
SQL> insert into t23 values (9999, 'TEST1')
2 /
1 row created.
SQL> insert into t23 values (-8888, 'TEST 2')
2 /
1 row created.
SQL> exec dbms_stats.gather_index_stats(user, 'I23')
PL/SQL procedure successfully completed.
SQL> select o.object_id, i.last_analyzed, i.distinct_keys
2 from user_objects o
3 join user_indexes i
4 on (i.index_name = o.object_name)
5 where o.object_type = 'INDEX'
6 and i.index_name = 'I23'
7 /
OBJECT_ID CREATED LAST_ANALYZED DISTINCT_KEYS
---------- -------------------- -------------------- -------------
116353 23-NOV-2013 00:15:39 23-NOV-2013 00:26:28 169
1 row selected.
SQL>
अब आंकड़ों से संबंधित मेटाडेटा बदल गया है लेकिन सूचकांक एक ही डेटाबेस ऑब्जेक्ट है। जबकि अगर हम इंडेक्स को छोड़ते हैं और फिर से बनाते हैं तो हमें एक नया डेटाबेस ऑब्जेक्ट मिलता है:
SQL> drop index i23
2 /
Index dropped.
SQL> create index i23 on t23(id)
2 /
Index created.
SQL> select o.object_id, i.last_analyzed, i.distinct_keys
2 from user_objects o
3 join user_indexes i
4 on (i.index_name = o.object_name)
5 where o.object_type = 'INDEX'
6 and i.index_name = 'I23'
7 /
OBJECT_ID CREATED LAST_ANALYZED DISTINCT_KEYS
---------- -------------------- -------------------- -------------
116354 23-NOV-2013 00:27:50 23-NOV-2013 00:27:50 169
1 row selected.
SQL>
सामान्य संचालन में हमें शायद ही कभी किसी इंडेक्स को छोड़ने और फिर से बनाने की आवश्यकता होती है। यह एक ऐसी तकनीक है जो बहुत बड़ी मात्रा में डेटा लोड करते समय और सूचकांक भ्रष्टाचार के बहुत ही दुर्लभ उदाहरणों में उपयुक्त होती है। इंटरवेब अभी भी उन साइटों को फेंकते हैं जो प्रदर्शन कारणों से अनुक्रमित के नियमित पुनर्निर्माण की सलाह देते हैं (कथित तौर पर यह तिरछी अनुक्रमणिका को "पुनः-संतुलन" करता है) लेकिन ये साइटें दीर्घकालिक लाभ साबित करने के लिए बेंचमार्क का उत्पादन नहीं करती हैं, और निश्चित रूप से कभी भी समय शामिल नहीं करती हैं और री-बिल्डिंग एक्सरसाइज से सीपीयू साइकिल बर्बाद हो जाती है।
किसी इंडेक्स को फिर से बनाने के लिए आँकड़ों को ताज़ा करने की तुलना में अधिक काम की आवश्यकता होती है। स्पष्ट रूप से सच है, क्योंकि पुनर्निर्माण में उप-कार्य के रूप में आंकड़े एकत्र करना शामिल है। सवाल यह है कि क्या इंडेक्स को छोड़ने और बाद में फिर से बनाने की तुलना में थोक डीएमएल को अपने इंडेक्स के साथ एक टेबल के खिलाफ करना अधिक कुशल है। इंडेक्स के बिना किसी तालिका में डेटा लोड करना और बाद में उन्हें फिर से बनाना तेज़ हो सकता है।
यहां कोई कठोर और तेज़ नियम नहीं है:यह इस बात पर निर्भर करता है कि आपके पास कितनी अनुक्रमणिकाएं हैं, तालिका के पूरे आकार के विरुद्ध प्रभावित पंक्तियों का अनुपात, क्या आपको संबंधपरक अखंडता बाधाओं को लागू करने के लिए अनुक्रमणिका की आवश्यकता है, और इसी तरह। संचालन के बीच एक बड़ा अंतर भी है:हो सकता है कि आप थोक प्रविष्टियों के लिए अनुक्रमणिका छोड़ना चाहें लेकिन उन्हें अपडेट के लिए बनाए रखें, इस पर निर्भर करता है कि आपके WHERE खंड के लिए आपको कौन सी अनुक्रमणिका की आवश्यकता है और क्या अद्यतन अनुक्रमित स्तंभों को प्रभावित करता है।
संक्षेप में, आपको अपने स्वयं के विशिष्ट परिदृश्य को बेंचमार्क करने की आवश्यकता है। जब प्रदर्शन प्रश्नों की बात आती है तो अक्सर यही उत्तर होता है।
