SQL सर्वर: फ़ाइलसमूह केवल सिस्टम तालिकाओं के लिए?


11

हमारे कॉर्पोरेट मानकों में से एक उपयोगकर्ता टेबल / इंडेक्स के लिए एक अलग फ़ाइल समूह / फ़ाइल है। इसे डिफ़ॉल्ट के रूप में सेट किया गया है ताकि सृजन सारणी विवरणों को अर्हता प्राप्त करने की कोई आवश्यकता नहीं है।

तो ऐसा दिखता है

  • फ़ाइल 1 = सिस्टम टेबल, एमडीएफ
  • fileid 2 = t-log = LDF
  • fileid 3 = उपयोगकर्ता सामग्री = NDF

क्या यहां कोई मुझे मूल औचित्य को समझने में मदद कर सकता है कि यह क्यों अनिवार्य था?


मैं साफ-सुथरी अवस्था में आऊंगा और मुझे लगता है कि यह बहुत अच्छा है। क्या मैं गलत हूं ...?

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

जवाबों:


9

Microsoft की 70-432 प्रशिक्षण पुस्तक कहती है, "प्राथमिक फ़ाइल समूह पर आपकी किसी भी वस्तु को न रखने का मुख्य कारण I / O में यथासंभव अलगाव प्रदान करना है। सिस्टम ऑब्जेक्ट्स में डेटा के रूप में अक्सर डेटा नहीं बदलता है। अपनी वस्तुओं में। प्राथमिक डेटा फ़ाइल में लेखन गतिविधि को कम करके, आप हार्डवेयर विफलताओं के कारण भ्रष्टाचार को शुरू करने की संभावना को कम करते हैं। इसके अलावा, क्योंकि प्राथमिक फ़ाइल समूह की स्थिति भी डेटाबेस की स्थिति निर्धारित करती है, आप उपलब्धता बढ़ा सकते हैं। डेटाबेस के प्राथमिक प्राथमिक फ़ाइल समूह में किए गए परिवर्तनों को कम से कम। "

इसलिए, जैसा आप चाहते हैं वैसा ही लें। दूसरों का कहना है कि कुछ परिस्थितियों में यह आवश्यक नहीं है और निश्चित रूप से बनाए रखने के लिए अधिक है। बस मैंने सोचा कि मैं Microsoft का तर्क प्रदान करूँगा।


उचित, इसके लिए कुछ लिखित औचित्य। मैं इसे स्वीकार करूंगा
gbn

1
एक और कारण यह है कि एक आंशिक डेटाबेस पुनर्स्थापना एक सही ढंग से डिज़ाइन किए गए VLDB की त्वरित पुनर्प्राप्ति की अनुमति देने वाले प्राथमिक फ़ाइल समूह के चयनित प्लसग्रुप को पुनर्स्थापित करने की अनुमति देता है। संग्रहीत / द्वितीयक फ़ाइल समूह को बाद में बहाल किया जाना है।
मार्टिन 0

@MartinC: मैं आंशिक पुनर्स्थापना आदि के बारे में जानता हूं, लेकिन मैंने सिस्टम तालिकाओं को स्पष्ट रूप से अलग करने के तर्क को कभी नहीं समझा। प्रदर्शन, संग्रह, रखरखाव, विभाजन आदि के लिए फाइल ग्रुप्स लेकिन सिस्टम टेबल? जारेड ने अब तक की सबसे अच्छी व्याख्या की ..
gbn

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

12

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

यदि ऐसा है, तो वे यह कहते हैं, मैं नहीं कह सकता, लेकिन यह प्राइमेरी फ़ाइलग्रुप में सिर्फ सिस्टम ऑब्जेक्ट्स के साथ कई फ़ाइल समूह होने का एक लाभ होगा।

हालाँकि आपको यह कहने के लिए कबाड़ में किक करनी चाहिए कि AutoShrink सक्षम होना चाहिए।


इसके बारे में अधिक जानने के लिए, आप ऑनलाइन पुस्तक में ऑनलाइन टुकड़ा पुनर्स्थापित करें खोज सकते हैं।
ब्रेंट ओजर

1
मैंने हमेशा सोचा है कि यह वूडू भी है 2 फाइलग्रुप एक ही वॉल्यूम पर हैं (एक SAN पर)। क्या भ्रष्टाचार का खतरा इतना अधिक है? (वास्तविक परिचालन DBAs ने AutoShrink को झूठा सेट किया)
gbn

ऑड्स हैं अगर भ्रष्टाचार है तो यह एक सिंगल फाइल के भीतर एक ही पेज होगा क्योंकि स्टोरेज डिस्क पर पेज लिखने पर हिचअप होगा। डेटाबेस भ्रष्टाचार के 99.9999% की तरह कुछ एक भंडारण समस्या है। बाकी समस्याओं में से 1/2 खराब मेमोरी हैं, बाकी SQL बग्स हैं। चूंकि डेटाबेस बड़ा हो जाता है (मल्टी-टीबी) यह अधिक महत्वपूर्ण हो जाता है, क्योंकि मल्टी-टीबी डेटाबेस को पुनर्स्थापित करने में कई दिन लगेंगे।
mrdenny

क्या मैं यह सोचने में सही नहीं रहूंगा कि यदि सिस्टम ऑब्जेक्ट केवल प्राथमिक फ़ाइलग्रुप में हैं, तो आपको भविष्य में क्या करना चाहिए, आप निम्न कार्य करने में सक्षम होंगे। किसी अन्य फ़ाइल समूह में x अतिरिक्त फ़ाइलें बनाएँ। अपने मौजूदा डेटा फ़ाइल से अपने डेटा को स्थानांतरित करके आनुपातिक रूप से इन फ़ाइलों को भरें?
सहयोगी रीली

4

मुझे यकीन नहीं है कि क्या आप किसी से अपने कॉर्पोरेट मानक को सही ठहराने के लिए कह रहे हैं? मुझे लगता है कि जिसने भी लिखा है कि आपकी कंपनी के लिए जो मानक हैं वे कुछ प्रकाश डालेंगे क्योंकि ऐसा क्यों किया जाएगा।

यह कहा जा रहा है, कुछ दुकानों के लिए उपयोगकर्ता डेटा से सिस्टम डेटा को तोड़ना नहीं करना असामान्य नहीं है। और अगर डिस्क के समर्पित सेट के साथ संयोजन में उपयोग किया जाता है, तो आप कुछ प्रदर्शन लाभ प्राप्त कर सकते हैं।


धन्यवाद। इसे सही नहीं ठहराते, बल्कि समझाते हैं। यह वही DB इंजीनियरिंग टीम है जो AutoShrink पर कहती है। यह देखते हुए कि सिस्टम टेबल कुछ एमबी पर हैं और वैसे भी मेमोरी में रहेंगे, क्या आप किसी भी प्रदर्शन लाभ पर विश्वास करते हैं?
gbn
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.