अभिलेखीय उद्देश्यों के लिए डेटाबेस को डीफ़्रैग / कॉम्पैक्ट करने का सर्वोत्तम तरीका


9

हमें एक SQL सर्वर इंस्टेंस मिला है जिसका उपयोग ईमेल संग्रह (एक तृतीय पक्ष संग्रह पैकेज के सौजन्य से) के लिए किया जाता है। हर बार, सॉफ़्टवेयर को एक नए खाली डेटाबेस पर ले जाया जाता है। हमने इसे पूर्व में त्रैमासिक किया है, लेकिन हम इसे मासिक रूप से करना चाहते हैं। संग्रहीत किए जाने वाले डेटा की मात्रा लगभग 15 - 20 जीबी प्रति माह है, और डेटा का थोक केवल मुट्ठी भर तालिकाओं (आमतौर पर 2 - 4) में रहता है।

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

कुछ संभावनाएं जो मैं सोच सकता हूं:

  1. REBUILD / REORGANIZE इंडेक्स, DBCC SHRINKFILE (ठीक है, यह एक समझदार विकल्प नहीं है, क्योंकि DBCC SHRINKFILE कुछ भी छूने से पेशाब को अलग कर देगा, लेकिन मैं इसे पूर्णता के लिए शामिल कर रहा हूं।)
  2. ऑटो-स्टैटिस के साथ एक नया डेटाबेस बनाएँ। स्रोत डेटाबेस से सभी तालिकाओं को स्क्रिप्ट और फिर से बनाएँ। क्लस्टर-कुंजी क्रम में नए डेटाबेस में डेटा को निर्यात / आयात करने के लिए bcp का उपयोग करें। स्क्रिप्ट और सभी अनुक्रमों को फिर से बनाना। पूर्ण स्कैन के साथ सभी आँकड़ों को फिर से लिखें।
  3. ऑटो-स्टैटिस के साथ एक नया डेटाबेस बनाएँ। स्रोत डेटाबेस से सभी तालिकाओं को स्क्रिप्ट और फिर से बनाएँ। नए डेटाबेस में डेटा ट्रांसफर करने के लिए SSIS या T-SQL का उपयोग करें। स्क्रिप्ट और सभी अनुक्रमों को फिर से बनाना। पूर्ण स्कैन के साथ सभी आँकड़ों को फिर से लिखें।

हर मामले में अंतिम चरण डेटाबेस को केवल-पढ़ने के लिए मोड पर सेट करना होगा।

ऐसा करने के लिए अन्य अच्छे / बेहतर विकल्प क्या हैं? मेरी चिंता एक उच्च भरण कारक को संरक्षित करने के लिए इस तरह से डेटा पर बढ़ रही है, और एक तार्किक रूप से सन्निहित फैशन में है।

संपादित करें:

मुझे यह उल्लेख करना चाहिए कि लगभग 75% डेटा छवि (LOB) कॉलम में संग्रहीत किया जा रहा है।


3
क्या आप (या अनुप्रयोग) देखभाल करते हैं अगर टेबल शारीरिक रूप से एक फाइलग्रुप के अलावा अन्य में समाप्त होती है PRIMARY?
जॉन सीगल

@JonSeigel मुझे नहीं लगता, और वास्तव में यह एक बहुत अच्छा विचार है, क्योंकि यह मुझे एक टेम्पलेट डेटाबेस बनाने और सभी डेटा को स्थानांतरित करने की परेशानी से बचाएगा।
db2

क्या आप केवल उन समाधानों पर विचार कर रहे हैं जिन्हें आप स्वयं कोड करते हैं या आप कुछ एप्लिकेशन की समीक्षा भी कर सकते हैं ताकि आपकी सहायता हो सके? आप RedGate के SQL स्टोरेज कंप्रेशन को लाइव डेटा को कंप्रेस करने के लिए इस्तेमाल कर सकते हैं । या आप कंप्रेस्ड बैकअप को ऑनलाइन डीबीएस के रूप में उपलब्ध कराने के लिए वर्चुअल रिस्टोर की कोशिश कर सकते हैं (वास्तव में पूरी जगह की आवश्यकता के बिना)। वे सभी पुराने हाइपरबाक विंडोज़ फ़ाइल ड्राइवर पर आधारित हैं जो लाइव डेटा और बैकअप को संपीड़ित करने में बहुत अच्छे हैं।
मैरियन

@ मेरियन दिलचस्प लगता है, लेकिन मैं अभी के लिए देशी SQL सर्वर क्षमताओं से चिपके रहना चाहूंगा। मुझे बस बहुत प्रभावी ढंग से डेटाबेस को डीफ़्रैग्मेन्ट करने की ज़रूरत है, बिना फ़ाइल (एस) में छोड़े गए बहुत सारे अप्रयुक्त स्थान के बिना। यदि यह एक तृतीय-पक्ष उपकरण है जो मैन्युअल रूप से स्क्रिप्टिंग के बजाय कार्य करता है, तो यह ठीक है।
db2

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

जवाबों:


1

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

यदि आप कभी एंटरप्राइज में जाने का निर्णय लेते हैं, तो यह आपको एक टुकड़ा बहाल करने और डेटाबेस को बहुत तेज़ी से ऑनलाइन लाने की अनुमति देगा। एंटरप्राइज भी इस रीड ओनली डेटा के लिए बड़े पैमाने पर क्वेरी टाइम को कम करने के अलावा कॉलमस्टोर इंडेक्स की अनुमति देता है, जो कि बड़े पैमाने पर फाइललेट है।

आप फ़ाइल के अंत में स्थान को हटाने के लिए विखंडन के साथ केवल किसी भी गंभीर मुद्दों के बिना पढ़ने के लिए स्विच करने से पहले एक बार संकोचन विकल्प का उपयोग कर सकते हैं।

एक साइड नोट पर, बस जाँच कर रहे हैं कि आप अपने डेटा के लिए नवीनतम डेटाटिप्स का उपयोग कर रहे हैं। nvarchar (अधिकतम) या varchar (अधिकतम) बजाय ntext या पाठ, varbinary (अधिकतम) छवि के बजाय?


यह ज्यादातर दुर्भाग्य से पाठ और छवि का उपयोग करता है। यह एक 3 पार्टी अनुप्रयोग है, इसलिए मुझे इसे बदलने की क्षमता नहीं है।
db2

@ वास्तव में अनुप्रयोग के लिए पारदर्शी, SQL सर्वर के साथ पंक्ति में जानकारी संग्रहीत करने पर <8k। यदि विक्रेता कहता है कि यह असमर्थित है, तो मैं उनसे पूछूंगा कि वे अभी भी SQL सर्वर 2005 में मूल रूप से पदावनत किए गए डेटाटाइप का उपयोग क्यों कर रहे हैं!
DamagedGoods

मैं पूरी तरह से निश्चित नहीं हो सकता कि एप्लिकेशन WRITETEXT जैसे पाठ / छवि-विशिष्ट सामान नहीं करता है जो डेटा प्रकार बदलने के बाद विफल हो जाएगा। लेकिन मुख्य बिंदु पर वापस, ऐसा लगता है कि क्लस्टर इंडेक्स को फिर से बनाना वास्तव में इसके साथ LOB डेटा को स्थानांतरित नहीं करेगा।
db2

आप ऐसा कर सकते हैं लेकिन आपको GUI में डिज़ाइनर में जाना है, फिर गुणों का विस्तार करना है, फिर आपके पास एक 'नियमित डेटा स्पेस' है, लेकिन एक TEXTIMAGE फ़ाइलग्रुप भी है, जो इस वसीयत को बदल देगा, लेकिन सावधान रहें यह तालिका को फिर से बनाएगा! आप स्पष्ट रूप से इसे
लिपिबद्ध

समझ गया, कि उपयुक्त पुनर्निर्माण लिपियों को उत्पन्न करने का एक उपयोगी तरीका हो सकता है, बहुत कम से कम।
db2

0

मुझे तीसरे पक्ष के उपकरण के साथ इसी तरह के मुद्दे का सामना करना पड़ा जो कि असंरचित डेटा को संग्रहीत करने के लिए एक छवि डेटाटाइप का उपयोग कर रहा था, और मैंने इसे फिलस्ट्रीम का उपयोग करने के लिए कॉलम में परिवर्तित करके हल किया । आपको यह सुनिश्चित करने के लिए कुछ परीक्षण करने की आवश्यकता होगी कि ऐप अभी भी आपकी अपेक्षा के अनुसार काम करता है, लेकिन इससे आपको अपनी स्वयं की संग्रह प्रक्रिया लिखने की क्षमता मिलेगी जो आपके डेटा को एक कुशल तरीके से संग्रहित db में ले जाती है।


मुझे संदेह है कि इस मामले में फिल्मास्ट्रीम अच्छा नहीं होगा। हमें 17 डेटाबेस में 14 मिलियन से अधिक पंक्तियां मिली हैं, और हम प्रति दिन लगभग 15,000 पर संदेश प्राप्त कर रहे हैं। संदेश निकायों का एक बड़ा हिस्सा 4 KB से नीचे है, इसलिए NTFS क्लस्टर अपशिष्ट शायद क्रूर होगा (और यह तब भी है जब हम 64KB से छोटे ब्लॉक आकार के साथ एक नया डिस्क वॉल्यूम जोड़ते हैं)।
db2

उस स्थिति में, क्या आप डेटाटाइप को nvarchar (अधिकतम) की तरह कुछ में बदल सकते हैं और इन बड़ी वस्तुओं के लिए एक अलग फ़ाइलग्रुप निर्दिष्ट करने के लिए TEXTIMAGE_ON क्लॉज का उपयोग कर सकते हैं? यह आपको डेटा को पंक्तिबद्ध करने की अनुमति देगा और संग्रह करने के प्रबंधन के लिए अपनी प्रक्रिया बनाने की अनुमति देगा।
लियाम कन्फ्रे

फिलास्ट्रीम का उपयोग वास्तव में इस बात पर निर्भर करता है कि प्रत्येक एलओबी कितने बड़े हैं। मुझे लगता है कि 1MB प्रति रिकॉर्ड माना जाता है। इसलिए मैं इस मामले में सहमत होना चाहता हूं कि इसका विकल्प नहीं है
DamagedGoods
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.