संकुल अनुक्रमणिका को जोड़े/छोड़े बिना SQL सर्वर तालिका विखंडन को कम करें?

समस्या

आइए कुछ स्पष्टता प्राप्त करें, क्योंकि यह एक सामान्य समस्या है, SQL सर्वर का उपयोग करने वाली प्रत्येक कंपनी के लिए एक गंभीर समस्या है।

यह समस्या, और CREATE CLUSTERED INDEX की आवश्यकता को गलत समझा जाता है।

सहमत हूं कि एक स्थायी क्लस्टर इंडेक्स होना एक नहीं होने से बेहतर है। लेकिन यह बात नहीं है, और वैसे भी यह एक लंबी चर्चा का कारण बनेगी, तो चलिए इसे एक तरफ रख देते हैं और पोस्ट किए गए प्रश्न पर ध्यान केंद्रित करते हैं।

मुद्दा यह है कि, आपके पास ढेर . पर पर्याप्त विखंडन है . आप इसे "टेबल" कहते रहते हैं, लेकिन भौतिक डेटा संग्रहण या डेटास्ट्रक्चर स्तर पर ऐसा कुछ नहीं है। तालिका एक तार्किक अवधारणा है, भौतिक नहीं। यह भौतिक डेटा संरचनाओं का एक संग्रह है। संग्रह दो संभावनाओं में से एक है:

• ढेर
  प्लस सभी गैर-क्लस्टर इंडेक्स
  प्लस टेक्स्ट/इमेज चेन

• या एक संकुलित अनुक्रमणिका
  (ढेर को हटाता है और एक नॉन-क्लस्टर इंडेक्स)
  प्लस सभी नॉन-क्लस्टर इंडेक्स
  प्लस टेक्स्ट/इमेज चेन।

ढेर बुरी तरह खंडित हो जाते हैं; जितने अधिक इंटरसेप्टेड (यादृच्छिक) सम्मिलित/हटाएं/अपडेट हैं, उतने ही अधिक विखंडन।

ढेर को साफ करने का कोई तरीका नहीं है, जैसा है। MS कोई सुविधा प्रदान नहीं करता (अन्य विक्रेता करते हैं)।

समाधान

हालाँकि, हम जानते हैं कि क्रिएट क्लस्टर्ड इंडेक्स हीप को पूरी तरह से फिर से लिखता है और फिर से ऑर्डर करता है। इसलिए, विधि (एक चाल नहीं) है, क्लस्टर इंडेक्स बनाना है केवल ढेर को डी-फ्रैगमेंट करने के उद्देश्य से , और बाद में इसे छोड़ दें। आपको टेबल_साइज x 1.25 के डीबी में खाली जगह चाहिए।

जब आप इसमें हों, तो हर तरह से भविष्य . को कम करने के लिए FILLFACTOR का उपयोग करें विखंडन। इसके बाद हीप अधिक आवंटित स्थान लेगा, जिससे अपडेट के कारण भविष्य में इन्सर्ट, डिलीट और पंक्ति विस्तार की अनुमति मिल जाएगी।

नोट

1. ध्यान दें कि तीन स्तर . हैं विखंडन का; यह केवल स्तर III से संबंधित है, ढेर के भीतर विखंडन, जो क्लस्टर इंडेक्स की कमी के कारण होता है

2. एक अलग कार्य के रूप में, किसी अन्य समय में, आप एक स्थायी क्लस्टर इंडेक्स के कार्यान्वयन पर विचार करना चाह सकते हैं, जो विखंडन को पूरी तरह से समाप्त कर देता है ... लेकिन यह पोस्ट की गई समस्या से अलग है।

टिप्पणी का जवाब

काफी नहीं। मैं इसे "सीमा" नहीं कहूंगा।

1. ढेर में विखंडन को खत्म करने के लिए मैंने जो तरीका दिया है, वह है एक क्लस्टर इंडेक्स बनाना, और फिर उसे छोड़ देना। अर्थात। अस्थायी रूप से, जिसका एकमात्र उद्देश्य विखंडन को ठीक करना है।

2. टेबल पर (स्थायी रूप से) क्लस्टर्ड इंडेक्स को लागू करना एक बेहतर समाधान है, क्योंकि यह कुल मिलाकर को कम करता है विखंडन (डेटा संरचना अभी भी खंडित हो सकती है, नीचे दिए गए लिंक में विस्तृत जानकारी देखें), जो कि ढेर में होने वाले विखंडन से बहुत कम है।

   • रिलेशनल डेटाबेस में प्रत्येक तालिका ("पाइप" या "क्यू" टेबल को छोड़कर) में इसके विभिन्न लाभों का लाभ उठाने के लिए एक क्लस्टर इंडेक्स होना चाहिए।

   • क्लस्टर्ड इंडेक्स उन स्तंभों पर होना चाहिए जो डेटा वितरित करते हैं (INSERT संघर्षों से बचना), कभी भी एक समान रूप से बढ़ते कॉलम पर अनुक्रमित नहीं होना चाहिए, जैसे रिकॉर्ड आईडी, जो अंतिम पृष्ठ में एक INSERT हॉट स्पॉट की गारंटी देता है।

MS SQL और Sybase ASE में, तीन स्तर हैं विखंडन का, और प्रत्येक स्तर के भीतर, कई अलग-अलग प्रकार . ध्यान रखें कि फ्रैगमेंटेशन के साथ काम करते समय, हमें डेटास्ट्रक्चर पर ध्यान देना चाहिए, न कि टेबल पर (एक टेबल डेटास्ट्रक्चर का एक संग्रह है, जैसा कि ऊपर बताया गया है)। स्तर हैं:

• स्तर I • अतिरिक्त डेटा संरचना
  संबंधित डेटा संरचना के बाहर, डेटाबेस में या उसके भीतर।

• स्तर II • डेटा संरचना
  संबंधित डेटा संरचना के अंतर्गत, उपरोक्त पृष्ठों (सभी पृष्ठों में)
  यह डीबीए द्वारा सबसे अधिक बार संबोधित किया जाने वाला स्तर है।

• स्तर III • पृष्ठ
  संबंधित डेटा संरचना के भीतर, पृष्ठों के भीतर

ये लिंक फ्रैगमेंटेशन का पूरा विवरण प्रदान करते हैं। वे Sybase ASE के लिए विशिष्ट हैं, हालांकि, संरचनात्मक स्तर पर, जानकारी MS SQL पर लागू होती है।

• विखंडन परिभाषा

• विखंडन प्रभाव

• विखंडन प्रकार

ध्यान दें कि मैंने जो तरीका दिया है वह लेवल II है, यह लेवल II और III फ्रैग्मेंटेशन को ठीक करता है।