गुच्छेदार सूचकांक पर पुनर्निर्माण, क्यों सिकुड़ता है?

Question

जब हमने एक टेबल पर क्लस्टर किए गए इंडेक्स पर पुनर्निर्माण किया, जिसमें लगभग 15 जीबी डेटा है और सिकुड़ कर 5 जीबी तक सिकुड़ गया है, तो यह कैसे हो सकता है? किस तरह का "डेटा" हटा दिया जाता है?

डेटा का आकार मेरा मतलब है कि DBCC sp_spaceused का "डेटा" कॉलम

संकुल अनुक्रमणिका के पुनर्निर्माण से पहले:

name                  rows        reserved    data        index_size  unused
LEDGERJOURNALTRANS    43583730    39169656 KB 15857960 KB 22916496 KB 395200 KB

---

संकुल अनुक्रमणिका के पुनर्निर्माण के बाद:

name                  rows        reserved    data        index_size  unused
LEDGERJOURNALTRANS    43583730    29076736 KB 5867048 KB  22880144 KB 329544 KB

पुनर्निर्माण के लिए TSQL:

USE [DAX5TEST]
GO
ALTER INDEX [I_212RECID] ON [dbo].[LEDGERJOURNALTRANS] REBUILD PARTITION = ALL WITH ( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, ONLINE = ON, SORT_IN_TEMPDB = OFF, DATA_COMPRESSION = PAGE, FILLFACTOR = 85 )
GO

Comments

क्या आप फ़ाइल आकार से डेटा आकार का निर्धारण कर रहे हैं?

— जेएनके

डेटा साइज़ का मतलब है कि DBCC sp_spaceused का डेटा "कॉलम"

— डैनियल ब्योर्क

वह "डेटा" कॉलम होगा EXEC sp_spaceused।

— RLF

क्या प्रत्येक निकाय ने याद किया कि ओपी पृष्ठ संपीड़न का उपयोग कर रहा है = अपनी पुनर्निर्माण स्क्रिप्ट में सक्षम है और मुझे लगता है कि यह पहले नहीं था। डैनियल क्या आप पुष्टि कर सकते हैं?

— शनकी

@ शैंकी: यह ALTER INDEXकथन ऐसा लगता है कि यह कोड द्वारा उत्पन्न किया गया था (क्योंकि इसमें उनकी डिफ़ॉल्ट सेटिंग में विकल्पों का एक समूह शामिल है) इसलिए मुझे संदेह है कि यह सूचकांक के मौजूदा विकल्पों में से बनाया गया था। लेकिन आप सही हैं: यदि संपीड़न को चलाने से पहले क्लस्टर किए गए अनुक्रमणिका पर सक्षम नहीं किया गया था, तो यह निश्चित रूप से डेटा फ़ुटप्रिंट में अधिकांश कमी की व्याख्या करेगा। (फिर से: डैनियल, क्या आप एक या दूसरे तरीके की पुष्टि कर सकते हैं?)

— डेविड स्पिललेट

Answer 1

एक मेज संकुल अनुक्रमणिका होता है तो सूचकांक है तालिका डेटा (अन्यथा आप एक ढेर प्रकार तालिका है)। क्लस्टर किए गए अनुक्रमणिका का पुन: निर्माण (वास्तव में कोई भी अनुक्रमणिका, लेकिन गैर-संकुल अनुक्रमणिका के लिए स्थान को "डेटा" के रूप में नहीं गिना जाएगा) इसके परिणामस्वरूप आंशिक रूप से उपयोग किए जाने वाले पृष्ठों को अधिक पूर्ण रूप में विलय कर दिया जाएगा।

जैसा कि आप इंडेक्स ऑर्डर पत्ता पृष्ठों में एक इंडेक्स (क्लस्टर या अन्यथा) में डेटा सम्मिलित करते हैं, आवश्यकतानुसार बनाए जाते हैं और आपके पास केवल एक आंशिक पेज होगा: अंत में एक। जब आप इंडेक्स ऑर्डर से डेटा दर्ज करते हैं, तो डेटा को सही जगह फिट करने के लिए एक पेज को विभाजित करने की आवश्यकता होती है: आप दो पृष्ठों के साथ समाप्त होते हैं जो लगभग आधे भरे हुए होते हैं और नई पंक्ति उनमें से एक में जाती है। समय के साथ यह बहुत कुछ हो सकता है, अतिरिक्त स्थान की उचित मात्रा का उपभोग करना, हालांकि एक हद तक भविष्य के आवेषण कुछ अंतराल भर देंगे। गैर-पत्ती पृष्ठों पर भी समान प्रभाव दिखाई देगा, लेकिन वास्तविक डेटा पृष्ठ आकार में कहीं अधिक महत्वपूर्ण हैं।

इसके अलावा डिलीट होने के कारण आंशिक पृष्ठ हो सकते हैं। यदि आप किसी पृष्ठ की सभी पंक्तियों को हटा देते हैं, तो इसे "अप्रयुक्त" के रूप में गिना जाता है, लेकिन यदि इसमें डेटा की एक या अधिक पंक्ति शेष हैं, तो इसे अभी भी उपयोग के रूप में गिना जाता है। यहां तक ​​कि अगर एक पृष्ठ में 10 बाइट्स का उपयोग करने वाली केवल एक पंक्ति है, तो उस पृष्ठ का उपयोग की गई जगह की गिनती में 8192 बाइट्स के रूप में गिना जाता है। फिर से भविष्य के आवेषण कुछ अंतराल को भर सकते हैं।

परिवर्तनशील लंबाई वाली पंक्तियों के लिए, अपडेट का भी एक ही प्रभाव हो सकता है: जैसे-जैसे कोई पंक्ति छोटी होती जाती है, वह अपने पृष्ठ में स्थान छोड़ सकती है, जो बाद में पुन: उपयोग करना आसान नहीं होता है, और यदि लगभग पूर्ण पृष्ठ में कोई पंक्ति लंबी होती है, तो यह पृष्ठ विभाजन को बाध्य कर सकती है ।

एसक्यूएल सर्वर समय का उपयोग करके डेटा को सामान्य करने की कोशिश में समय नहीं बिताता है, पृष्ठों का उपयोग कैसे किया जाता है, जब तक कि स्पष्ट रूप से आपके सूचकांक के आदेश के रूप में इस तरह के बारे में नहीं बताया जाता है, क्योंकि इस तरह के कचरा संग्रह अभ्यास एक प्रदर्शन दुःस्वप्न हो सकते हैं।

मुझे संदेह है कि यह वही है जो आप देख रहे हैं, हालांकि मैं कहूंगा कि ~ 2.7 गुना राशि के लिए पर्याप्त स्थान आवंटित किया जाना चाहिए, जो कि डेटा को विशेष रूप से खराब स्थिति के लिए बिल्कुल आवश्यक है। इसका अर्थ यह हो सकता है कि आपके पास इंडेक्स में एक महत्वपूर्ण कुंजी (यूयूआईडी कॉलम शायद) में से कुछ के रूप में यादृच्छिक है, जिसका अर्थ है कि नई पंक्तियों को इंडेक्स ऑर्डर में कभी भी जोड़ा जाने की संभावना नहीं है, और / या हाल ही में डिलीट की एक महत्वपूर्ण संख्या हुई है।

पेज स्प्लिट उदाहरण

अनुक्रमणिका क्रम में निश्चित लंबाई पंक्तियों के साथ सम्मिलित करना, जिनमें से चार एक पृष्ठ में फिट होते हैं:

Start with one empty page: 
        [__|__|__|__]
Add the first item in index order:
        [00|__|__|__]
Add the next three
        [00|02|04|06]
Adding the next will result in a new page:
        [00|02|04|06] [08|__|__|__]
And so on...
        [00|02|04|06] [08|10|12|14] [16|18|__|__]

अब सूचकांक क्रम से बाहर की पंक्तियों को जोड़ने के लिए (यही कारण है कि मैंने केवल ऊपर भी संख्याओं का उपयोग किया है): जोड़ने 11का मतलब या तो उस दूसरे पृष्ठ को फैलाना होगा (संभव नहीं जैसा कि वे निश्चित आकार के हैं), सब कुछ 11 से ऊपर बढ़ना (अभी तक बहुत महंगा है) एक बड़ा सूचकांक) या पेज को विभाजित करना जैसे:

[00|02|04|06] [08|10|11|__] [12|14|__|__] [16|18|__|__]

यहाँ से, जोड़ने 13और 17परिणाम नहीं होगा क्योंकि वर्तमान में संबंधित पृष्ठों में कमरा है:

[00|02|04|06] [08|10|11|__] [12|13|14|__] [16|17|18|__]

लेकिन 03 वसीयत जोड़ना:

[00|02|03|__] [04|06|__|__] [08|10|11|__] [12|13|14|__] [16|17|18|__]

जैसा कि आप देख सकते हैं, उन सम्मिलित परिचालनों के बाद हमारे पास वर्तमान में 5 डेटा पृष्ठ आबंटित हैं, जो कुल 20 पंक्तियों में फिट हो सकते हैं, लेकिन हमारे पास केवल 14 पंक्तियाँ हैं (अंतरिक्ष का 30% "बर्बाद कर रहे हैं")।

डिफ़ॉल्ट विकल्प के साथ पुनर्निर्माण ("कारक भरें" के बारे में नीचे देखें) में परिणाम होगा:

[00|02|03|04] [06|08|10|11] [12|13|14|16] [17|18|__|__]

इस सरल उदाहरण में एक पृष्ठ को सहेजना। यह देखना आसान है कि कैसे हटाए जाने से आउट-ऑफ-इंडेक्स-ऑर्डर आवेषण के समान प्रभाव हो सकता है।

शमन

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

पृष्ठ विभाजन, विशेष रूप से क्लस्टर किए गए सूचकांक पर, आवेषण / अपडेट के लिए एक प्रदर्शन निहितार्थ हो सकता है इसलिए FILLFACTORडेटाबेस में स्थान उपयोग के मुद्दे के बजाय कभी-कभी इसका कारण बनता है जो बहुत अधिक लेखन गतिविधि को देखते हैं (लेकिन अधिकांश एप्लिकेशन के लिए, जहां आउटरहॉट रीड लिखते हैं परिमाण के कई आदेशों से, आप आम तौर पर विशिष्ट मामलों को छोड़कर 100% पर फिल-फैक्टर को छोड़ने से बेहतर हैं, जहां आप प्रभावी रूप से यादृच्छिक सामग्री वाले स्तंभों पर अनुक्रमित करते हैं)।

मुझे लगता है कि अन्य बड़े नाम डीबी के पास एक समान विकल्प है, अगर आपको उनमें इस स्तर के नियंत्रण की आवश्यकता है।

अपडेट करें

ALTER INDEXउपरोक्त टाइपिंग शुरू करने के बाद प्रश्न में जोड़े गए कथन के बारे में : मेरा मानना ​​है कि विकल्प वही हैं जब सूचकांक पहली बार बनाया गया था (या अंतिम पुनर्निर्माण) लेकिन यदि ऐसा नहीं था तो संपीड़न विकल्प बहुत महत्वपूर्ण हो सकता है समय के आसपास। इसके अलावा उस बयान में फिल्फ़ेक्टर 85% 100% पर सेट नहीं है, इसलिए प्रत्येक पत्ती पृष्ठ पुनर्निर्माण के तुरंत बाद ~ 15% खाली हो जाएगा।

Comments

+1 यदि पृष्ठ भरण कारक 100% से कम है, उदाहरण के लिए यदि पृष्ठ भरण कारक 50% था, तो नवनिर्मित क्लस्टर अनुक्रमणिका ( तालिका ) 100% भरण कारक के साथ निर्मित होने पर दोगुनी होगी।

— मैक्स वर्नोन

Answer 2

जब आप किसी इंडेक्स का पुनर्निर्माण करते हैं, तो यह वस्तुतः सभी डेटा को नए पृष्ठों पर रखता है। मुझे जो संदेह हुआ वह यह है कि आपने पुनर्निर्माण से पहले बहुत अधिक डेटा हटा दिया, उदाहरण के लिए एक कॉलम को हटा दिया, कम डेटा वाले एक चर-चौड़ाई वाले कॉलम को अपडेट किया, एक निश्चित-चौड़ाई वाले कॉलम के आकार को बदल दिया, या बहुत सी पंक्तियों को हटा दिया। इनमें से कोई भी संचालन पृष्ठों पर बहुत सारी खाली जगह छोड़ सकता है, जो पुनर्निर्माण तक वापस नहीं मिलेगा। "डेटा" कॉलम sp_spaceusedवास्तविक डेटा को नहीं माप रहा है, लेकिन डेटा को संग्रहीत करने के लिए उपयोग किए जाने वाले 8K पृष्ठों की संख्या। पुनर्निर्माण के कारण वे पृष्ठ अब अधिक भरे हुए हैं, इसलिए डेटा की समान मात्रा कम पृष्ठों पर फिटिंग कर रही है।

Answer 3

sp_spaceusedसंग्रहीत प्रक्रिया डेटाबेस में पंक्तियों की कुल culmulative आकार की जांच नहीं कर रहा है। यह उस डेटा को रखने के लिए आवंटित स्थान के आकार की रिपोर्टिंग कर रहा है, जो डेटा के लिए आवंटित किए गए विस्तार के संचयी आकार में है।

यदि महत्वपूर्ण फ्रीस्पेस उपलब्ध है, जैसे कि कई हटाई गई पंक्तियों से, तो क्लस्टर इंडेक्स के पुनर्निर्माण से पन्नों में जगह कम हो जाएगी और प्रदर्शन कारणों से अधिक कुशल (यानी छोटा) हो जाएगा।

इसलिए, किसी भी डेटा को खारिज नहीं किया जाना चाहिए था, लेकिन पुनर्निर्माण की प्रक्रिया ने उस खाली स्थान को बनाया जो डेटा पृष्ठों में फिर से उपलब्ध था।