जब मैं पंक्तियों को हटाता हूं तो मेरे गैर-अनुक्रमित सूचकांक अधिक स्थान का उपयोग क्यों करते हैं?


22

मेरे पास 7.5 बिलियन रो और 5 इंडेक्स वाली एक बड़ी टेबल है। जब मैं लगभग 10 मिलियन पंक्तियों को हटाता हूं, तो मैं ध्यान देता हूं कि गैर-अनुक्रमित अनुक्रमणिका उन पृष्ठों की संख्या में वृद्धि करती प्रतीत होती है, जिन पर वे संग्रहीत हैं।

मैंने dm_db_partition_statsपृष्ठों में अंतर (बाद में - पहले) की रिपोर्ट करने के खिलाफ एक प्रश्न लिखा :

dm_db_partition_stats डेल्टास

इंडेक्स 1 क्लस्टर इंडेक्स है, इंडेक्स 2 प्राथमिक कुंजी है। दूसरे गैर-अभिमानी और गैर-अद्वितीय हैं।

उन गैर-संकुलित अनुक्रमित पर पृष्ठ क्यों बढ़ रहे हैं?
मुझे उम्मीद थी कि संख्याएँ सबसे कम रहेंगी।
मुझे लगता है कि प्रदर्शन काउंटरों को हटाए जाने के दौरान पृष्ठ-विभाजन में वृद्धि की सूचना है।

हटाते समय, क्या भूत रिकॉर्ड को दूसरे पृष्ठ पर ले जाना पड़ता है? क्या यह "यूनीकफायर" के साथ करना है?

हम RCSI को चालू करने के बीच में हैं, लेकिन अभी, RCSI बंद है।

यह एक उपलब्धता समूह में एक प्राथमिक नोड है। मुझे पता है कि स्नैपचैट का इस्तेमाल सेकेंडरीज़ पर किसी तरह किया जाता है। अगर यह प्रासंगिक था तो मुझे आश्चर्य होगा। मैं इसे और अधिक जानने के लिए (dbcc पृष्ठ आउटपुट की तलाश में) खुदाई करने की योजना बना रहा हूं। यहां उम्मीद है कि किसी ने कुछ ऐसा ही देखा हो।


बस एक सवाल - एक सूचकांक पर एक रनगति चल रही है जो बढ़ी, क्या होता है? कितने पृष्ठ हटाए गए हैं? और यदि आप हटाने से पहले पुनर्गठन करते हैं, तो क्या होता है? मैं ज्यादातर सोच रहा हूं कि आंतरिक तंत्र को कुछ मामलों में एक नया पृष्ठ आवंटित करना और मर्ज करना आसान लग सकता है, लेकिन खाली पृष्ठों को साफ नहीं करता है। मुझे पता है कि REORGANIZE पृष्ठों की महत्वपूर्ण मात्रा को समाप्त कर देता है, यहां तक ​​कि अपेक्षाकृत अप्रकाशित लेकिन बड़े अनुक्रमित पर भी।
लाफिंग वर्गिल

अच्छा सवाल @LaughingVergil जब मेरे पास इसका जवाब है, तो मैं इसे रिपोर्ट करने के लिए यहां वापस आऊंगा। (लेकिन इसमें थोड़ा समय लग सकता है)।
माइकल जे।

हमारे मामले में, यह वृद्धि एक अस्थायी घटना थी। पर्याप्त धैर्य के साथ, भूत की सफाई ने आखिरकार अपना काम किया और सूचकांक के आकार में कमी आई।
माइकल जे स्वार्ट

जवाबों:


28

एक संभावित परिदृश्य जो मुझे बहुत भाता है:

  • पंक्तियाँ मूल रूप से तब लिखी गई थीं जब डेटाबेस में पढ़े हुए स्नैपशॉट (RCSI), स्नैपशॉट अलगाव (SI) या उपलब्धता समूह (AGs) सक्षम नहीं थे
  • RCSI या SI सक्षम किया गया था, या डेटाबेस को एक उपलब्धता समूह में जोड़ा गया था
  • हटाए जाने के दौरान, RCSI / SI / AG रीड्स का समर्थन करने के लिए हटाए गए पंक्तियों में एक 14-बाइट टाइमस्टैम्प जोड़ा गया था

चूंकि यह सर्वर एजी में एक प्राथमिक है, यह प्रभावित होता है जैसे कि सेकंडरी हैं। संस्करण की जानकारी प्राथमिक पर जोड़ी जाती है - डेटा पृष्ठ प्राइमरी और सेकंडरी दोनों पर समान होते हैं। सेकेंडरी स्टोर स्टोर का उपयोग अपनी रीडिंग करने के लिए करते हैं जबकि पंक्तियों को एजी द्वारा अपडेट किया जा रहा है, लेकिन सेकंडरी पेज के लिए टाइमस्टैम्प के अपने संस्करण नहीं लिखते हैं। वे सिर्फ प्राथमिक कार्य से संस्करणों को प्राप्त करते हैं।

विकास को प्रदर्शित करने के लिए, मैंने स्टैक ओवरफ्लो डेटाबेस निर्यात (जिसमें आरसीएसआई सक्षम नहीं है) लिया और पोस्ट टेबल पर अनुक्रमित का एक गुच्छा बनाया। मैंने sp_BlitzIndex @Mode = 2 के साथ सूचकांक आकार की जाँच की (कॉपी / एक स्प्रेडशीट में चिपकाया गया, और सूचना घनत्व को अधिकतम करने के लिए थोड़ा साफ किया):

sp_BlitzIndex से पहले

मैंने तब लगभग आधी पंक्तियों को हटा दिया:

BEGIN TRAN;
DELETE dbo.Posts WHERE Id % 2 = 0;
GO

कुल मिलाकर, जब डिलीट हो रहे थे, टाइमस्टैम्प को समायोजित करने के लिए डेटा फ़ाइल बढ़ रही थी! SSMS डिस्क उपयोग रिपोर्ट में वृद्धि की घटनाओं को दिखाया गया है - यहाँ वर्णन करने के लिए बस ऊपर है:

विकास की घटनाएँ

(एक डेमो से प्यार है जहाँ डिलीट करने से डेटाबेस बढ़ता है।) जबकि डिलीट चल रहा था, मैं फिर से sp_BlitzIndex चला गया। ध्यान दें कि क्लस्टर किए गए इंडेक्स में कम पंक्तियाँ हैं, लेकिन इसका आकार पहले ही लगभग 1.5GB बढ़ चुका है। AcceptedAnswerId पर गैर-अनुक्रमित अनुक्रमित नाटकीय रूप से बढ़े हैं - वे एक छोटे से मूल्य पर अनुक्रमित होते हैं जो ज्यादातर अशक्त होते हैं, इसलिए उनके सूचकांक का आकार लगभग दोगुना हो गया है!

हटाने के दौरान sp_BlitzIndex

मुझे उस सिद्ध को समाप्त करने के लिए विलोपन की प्रतीक्षा करने की आवश्यकता नहीं है, इसलिए मैं वहां प्रदर्शन रोक दूंगा। जा रहा बिंदु: जब आप RCSI, SI, या AGs सक्षम होने से पहले लागू की गई मेज पर बड़े विलोपन करते हैं, तो अनुक्रमणिका (क्लस्टर सहित) वास्तव में संस्करण स्टोर टाइमस्टैम्प के अतिरिक्त को समायोजित करने के लिए बढ़ सकती है।


3
यह स्पष्टीकरण है। यह पता चला है कि अन्य परिस्थितियां हैं जो लापता 14 संस्करण बाइट्स को जन्म दे सकती हैं। मेरे परीक्षण में ऐसा लगता है कि एक अनुक्रमणिका का पुनर्निर्माण ऑफ़लाइन संस्करण बाइट्स के बिना पंक्तियों का पुनर्निर्माण करेगा।
माइकल जे।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.