SQL सर्वर में DB सिकुड़ने के कारण आपके पास अच्छा कारण है अक्सर "चूसना"। एसक्यूएल 2005 में स्टोरेज इंजन के प्रमुख पॉल रैंडल ने कहा, श्रिंकडीबी को बहुत खराब तरीके से लिखा गया है। यह डेटा को बहुत ही अंत में ले जाकर खाली स्थान प्राप्त करेगा और इसे बहुत शुरुआत में डाल देगा और इसे तब तक करता रहेगा जब तक कि इसके पास DB फाइलों के 'अंत' में खाली जगह न हो। इस बिंदु पर यह SQL सर्वर से स्थान को मुक्त कर सकता है और इसे OS को वापस दे सकता है। आप प्रभावी रूप से अपनी डेटाबेस फ़ाइलों को उलट रहे हैं इस प्रकार आप आमतौर पर बड़े पैमाने पर विखंडन देखेंगे। आप इस ब्लॉग पोस्ट या इस एमसीएम इंटर्नल वीडियो पर उनके विचारों के बारे में पढ़ सकते हैं
सब कुछ के साथ, आपको वास्तव में पहले अपने वातावरण में इनका परीक्षण करना चाहिए। इसे करने का एक बेहतर तरीका डेटा को एक अलग फ़ाइलग्रुप में ले जाना है। आप क्लस्टर किए गए अनुक्रमणिका के साथ एक ऑनलाइन अनुक्रमणिका पुन: निर्माण कर सकते हैं और फिर नए फ़ाइल समूह में reindex कर सकते हैं। फिर आप पुराने को छोड़ सकते हैं और अंतरिक्ष को छोड़ सकते हैं और लगभग कोई विखंडन नहीं कर सकते हैं। ध्यान दें कि यह लगभग 120% अतिरिक्त स्थान लेगा, जबकि यह इसके माध्यम से काम कर रहा है। इसके साथ समस्या यह है कि आपको अतिरिक्त अतिरिक्त स्थान की आवश्यकता है जो ऐसा दिखता है जैसे आपके पास नहीं हो सकता है। यह एक एंटरप्राइज फीचर है।
यदि नि: शुल्क स्थान प्रीमियम के इतने हिस्से में है, तो आपको लंबे समय तक चलने वाली प्रक्रियाओं से बचने के लिए बुलेट को काटने और धीरे-धीरे डीबी को एक छोटे से हिस्से को छोटा करना पड़ सकता है। ध्यान दें कि आपका डेटा बहुत अधिक खंडित हो जाएगा और आप फिर से सब कुछ फिर से लिखना चाहेंगे। ध्यान दें कि सब कुछ reindexing के बाद, आप फिर अपने इस्तेमाल की जगह को थोड़ा सा गुब्बारा करेंगे और अतिरिक्त खाली स्थान होने पर वापस जाएंगे। यहां ब्रेंट की सलाह देखें ।
जहां तक आपके लिए कितना खाली स्थान अच्छा है, यह एक बात है कि आप विखंडन और फ़ाइल विकास गतिविधियों को कितना बर्दाश्त कर सकते हैं। IFI सक्षम होने के साथ, फ़ाइल की वृद्धि लगभग तुरंत होती है लेकिन आपको अभी भी विखंडन मिलता है। अंगूठे का एक अच्छा नियम यह है कि जितना आपको लगता है कि अंतरिक्ष की जरूरत है, प्रचार करें, या विकास की निगरानी करें और यदि आप हैं तो समय-समय पर समायोजित करें। इससे शारीरिक विखंडन कम होता है।
इसके अलावा लॉग फ़ाइल वृद्धि एक बहुत अधिक महत्वपूर्ण है। अतिरिक्त लॉग फाइलें VLF विखंडन का कारण बन सकती हैं। यह आपके रेस्टोर को बहुत धीमा बनाता है और चेकपॉइंट / ट्रंकट्स को प्रभावित कर सकता है। यहां कुछ प्रदर्शन जोखिम हैं जो आप एक खंडित लॉग के साथ लेते हैं। एक है DBCC LOGINFO();प्रत्येक डेटाबेस पर। किम ट्रिप प्रति 50ish के आसपास संख्या रखने की कोशिश करें, लेकिन यदि आप सैकड़ों देखते हैं, तो आपके पास विखंडन मुद्दे हैं, जिसका अर्थ है कि आपकी लॉग फ़ाइलों को संचालन का समर्थन करने के लिए बढ़ना था। पॉल रान्डल के अनुसार आपकी लॉग फ़ाइल क्या होनी चाहिए, यह देखने का एक अच्छा तरीका है कि इसे एक सप्ताह के लिए बढ़ने दें और रीइन्डेक्स करें। यह एक अच्छा बिंदु हो सकता है, शायद आप सिर्फ मामले में वहां पर थोड़ी अधिक खाली जगह फेंक सकते हैं। सुनिश्चित करें कि आपके लॉग DBCC LOGINFO () के साथ खंडित नहीं हैं; फिर से और यदि वे हैं, तो इसका मतलब है कि वे बहुत बढ़ गए। का उपयोग करके लॉग फ़ाइल को सिकोड़ें और पुनः विस्तारित करेंयह विधि ।