पृष्ठ संख्या <1000 के साथ अनुक्रमणिका का पुनर्निर्माण क्यों नहीं किया गया?


17

मैं सूचकांक रखरखाव के लिए ओला हॉलेनग्रेंस स्क्रिप्ट का उपयोग करता हूं। इससे पहले कि मैं ऐसा करता, मैंने निम्नलिखित क्वेरी का उपयोग करके देखा कि कौन से सूचकांक सबसे अधिक खंडित हैं:

SELECT dbschemas.[name] as 'Schema',
dbtables.[name] as 'Table',
dbindexes.[name] as 'Index',
indexstats.avg_fragmentation_in_percent,
indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
ORDER BY indexstats.avg_fragmentation_in_percent desc

मेरे मामले में, avg_fragmentation 15 इंडेक्स के लिए 70% से अधिक और 28 इंडेक्स के लिए 30% से अधिक था ।

इसलिए, मैं ओला हॉलेनग्रेन के समाधान का उपयोग करके प्रत्येक सूचकांक का पुनर्निर्माण करता हूं। जब मैंने फिर से क्वेरी चलाई, तो यह परिणाम था:

12 इंडेक्स के लिए 70% से अधिक फ्रैग्मेंटेशन , 15 इंडेक्स के लिए 30% से अधिक ।

मुझे लगा, इसका कारण था page_count, जो कि प्रत्येक अनुक्रमणिका के लिए 1000 से कम था जो अभी भी बहुत खंडित थे। उदाहरण के लिए, page_count 967 में से एक इंडेक्स में 98,98% का विखंडन प्रतिशत है ! मेरे लिए, यह उस सूचकांक के पुनर्निर्माण के लायक है! मैंने किया था, और बाद में, विखंडन 0% था । इसके अलावा, page_count132 के साथ एक सूचकांक 95% से 0% तक चला गया

तो, मेरा प्रश्न यह है कि उन कारणों का पुन: निर्माण न करने के क्या कारण होंगे? एक कारण यह हो सकता है कि पुनर्निर्माण के लिए समय और संसाधन खर्च होते हैं, लेकिन क्योंकि सूचकांक छोटे हैं, इसका मतलब यह नहीं है कि यह अपेक्षाकृत कुछ संसाधनों की लागत है और यह अभी भी इसे फिर से बनाने के लिए विशेष होगा?

इस साइट पर कई संबंधित प्रश्न हैं, लेकिन उनमें से सभी इस सवाल का जवाब देते हैं कि एक सूचकांक डीफ़्रैग्मेंट क्यों नहीं करेगा, या यदि वे अभी भी छोटे हैं तो इंडेक्स उपयोगी हैं और आप उन्हें डीफ़्रैग्मेंट नहीं करते हैं, जबकि यहां कथन में विखंडन कम हो जाता है, सवाल यह है कि ऐसा क्यों नहीं किया जा रहा है?


मेमोरी में छोटे इंडेक्स के कैश्ड होने की संभावना है। इंडेक्स जो IO को वैसे भी लाइक नहीं करते हैं वे डीफ़्रैग्मेन्टेशन से लाभ नहीं उठाते हैं। यह 1000 पेज की गिनती का नियम एक हेयुरिस्टिक है।
usr

जवाबों:


20

पृष्ठों की न्यूनतम संख्या से संबंधित मार्गदर्शन कुछ हद तक मनमाना है । विखंडन को कम करने के सबसे बड़े लाभ हैं:

  1. यह बड़ी रेंज स्कैन के लिए रीड-फॉरवर्ड प्रदर्शन में सुधार कर सकता है ; तथा
  2. यह पृष्ठ घनत्व (प्रति पृष्ठ पंक्तियों की संख्या) में सुधार कर सकता है

परिभाषा के अनुसार ये दोनों कारक छोटे सूचकांक के लिए कम महत्वपूर्ण हैं।

छोटे सूचकांक के पुनर्निर्माण के लिए तर्क-वितर्क अनिवार्य रूप से है:

"क्यों परेशान? क्या आपके पास चिंता करने के लिए अधिक महत्वपूर्ण चीजें नहीं हैं?"।

इसने कहा, पुनर्निर्माण / पुनर्गठन स्वतंत्र नहीं है। यह कुछ मामलों में अतिरिक्त प्रयास और लॉग पीढ़ी से बचने के लायक हो सकता है (उदाहरण के लिए, यदि लॉग को किसी भी संभावित कारणों के लिए WAN पर कॉपी / कॉपी किया जाता है - मिररिंग, उपलब्धता समूह, प्रतिकृति ...)। इसके अलावा, जब तक (या यहां तक ​​कि अगर, कुछ मामलों में) आप ऑनलाइन पुनर्निर्माण कर रहे हैं, तो पुनर्निर्माण लॉकिंग के माध्यम से अन्य समवर्ती प्रक्रियाओं को प्रभावित कर सकता है। अंत में, छोटे अनुक्रमितों के लिए, पुनर्निर्माण भी विखंडन को कम नहीं कर सकता है, मिश्रित extents से आवंटन के कारण (जब तक आप ट्रेस ध्वज 1118 सक्षम के साथ नहीं चल रहे हैं )।

यदि आप अभी भी इन छोटे अनुक्रमों के पुनर्निर्माण में खुशी महसूस करते हैं, और परिणामों को बुरा नहीं मानते हैं, तो हर तरह @PageCountLevelसे ओला की प्रक्रिया में पारित पैरामीटर के मूल्य को बदल दें ।

सभी विवरणों के लिए इंडेक्स फ्रेग्मेंटेशन पर पॉल रान्डल की प्रस्तुति की पास टीवी रिकॉर्डिंग देखें।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.