वास्तविक डेटा की तुलना में एमडीएफ फ़ाइल का आकार बहुत बड़ा

Question

किसी कारण से मेरी एमडीएफ फ़ाइल 154 गीगा है, हालांकि, मैंने केवल फ्लैट फाइलों से 7 गीगा मूल्य डेटा लोड किया है। वास्तविक स्रोत डेटा की तुलना में एमडीएफ फ़ाइल इतनी बड़ी क्यों है?

और जानकारी:

केवल एक ~ 25 मिलियन पंक्तियों के साथ कुछ तालिकाओं। कोई बड़ा वर्कर फ़ील्ड (सबसे बड़ा 300 है, अधिकांश वर्चर (50) से कम हैं। बहुत विस्तृत टेबल < 20 कॉलम नहीं हैं। इसके अलावा, बड़ी तालिकाओं में से कोई भी अनुक्रमित नहीं है। इंडेक्स के साथ टेबल्स में 1 मिलियन से कम पंक्तियां हैं। मैं ' टी उपयोग चार, केवल तार के लिए varchar। डाटाटाइप मुद्दा नहीं है।

पता चला यह लॉग फ़ाइल, नहीं mdf फ़ाइल था। MDF फ़ाइल वास्तव में 24gigs है जो अधिक उचित लगता है, लेकिन अभी भी बड़ा IMHO।

अद्यतन:

मैं सरल करने के लिए पूर्ण से वसूली मॉडल बदलकर एलडीएफ (लॉग) फ़ाइल के साथ समस्या तय यह ठीक है, क्योंकि इस सर्वर केवल आंतरिक विकास और ETL प्रसंस्करण के लिए प्रयोग किया जाता है।। इसके अलावा, सरल में बदलने से पहले मुझे LOG फ़ाइल को कम करना पड़ा। ज्यादातर मामलों में झुर्रियों की सिफारिश नहीं की जाती है, हालांकि, यह उन मामलों में से एक था जहां लॉग फ़ाइल इतनी बड़ी और इतनी तेज़ी से नहीं बढ़नी चाहिए थी। आगे पढ़ने के लिए this

Answer 1

हो सकता है कि आप वर्चर (5000) के बजाय चार (5000) का उपयोग कर रहे हों, शायद आप int, nvarchar के बजाय bigints का उपयोग कर रहे हैं, जब आपको केवल वक्रार इत्यादि की आवश्यकता हो। हो सकता है कि आप प्रति तालिका में बहुत से इंडेक्स का उपयोग कर रहे हों, ये सभी जोड़ देंगे। शायद आपकी autogrow सेटिंग्स गलत हैं। आप सुनिश्चित हैं कि यह एमडीएफ है और एलडीएफ फाइल सही नहीं है?

Answer 2

क्योंकि एमडीएफ को 154 जीबी के साथ आवंटित किया गया था, या विभिन्न परिचालनों के माध्यम से 154 जीबी तक बढ़ गया है। एक डेटाबेस फ़ाइल में कम से कम उस डेटा का आकार है, लेकिन यह किसी भी राशि द्वारा उपयोग की गई राशि से बड़ा हो सकता है।

एक स्पष्ट प्रश्न डेटाबेस डेटाबेस में डेटा की मात्रा को कैसे मापता है? क्या आपने sp_spaceused का उपयोग किया था? क्या आपने sys.allocation_units देखा था? क्या आपको लगता है?

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

यदि आप बिल्कुल सकारात्मक हैं तो समग्रकरण एक गलती है, आप सभी negative consequences of shrinking के साथ डेटाबेस को छोटा कर सकते हैं।

Answer 3

या तो ऑटो श्रिंक सक्षम नहीं है या प्रारंभिक आकार बड़े मान पर सेट किया गया था।