2008-09-20 3 views
6

वर्तमान में, मैं एक ऐसे उत्पाद को विकसित कर रहा हूं जो एमएस एसक्यूएल सर्वर 2005 का उपयोग करके काफी गहन गणना करता है। उच्च स्तर पर, मेरे उत्पाद का आर्किटेक्चर "रन" की अवधारणा पर आधारित होता है जहां हर बार जब मैं कुछ विश्लेषिकी करता हूं तो यह संग्रहीत हो जाता है रन टेबल की एक श्रृंखला (प्रति रन ~ 100 टेबल)।क्या एकाधिक फ़ाइल समूह मेरे डेटाबेस को तेज करने में मदद करेंगे?

मेरी समस्या यह है कि जब कुछ महीनों के बाद रनों की संख्या लगभग 1000 या उससे अधिक हो जाती है, तो डेटाबेस पर प्रदर्शन वास्तव में बंद हो जाता है, और विशेष रूप से सरल प्रश्न जैसे टेबल के अस्तित्व की जांच करना या विचार बनाने में एक से दो तक का समय लग सकता है।

मैंने सुना है कि एकाधिक फ़ाइल समूह का उपयोग करके, जो मैं वर्तमान में नहीं कर रहा हूं, मदद कर सकता है। क्या यह सच है, और यदि हां, तो यह कैसे मदद करेगा? इसके अलावा, अगर अन्य सुझाव भी हैं, तो यहां तक ​​कि कम टेबल का उपयोग करने के लिए, मैं उनके लिए खुला हूं। मैं सिर्फ डेटाबेस को गति देना चाहता हूं और उम्मीद है कि इसे ऐसे राज्य में प्राप्त करें जहां यह स्केल होगा।

उत्तर

3

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

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

सामान्य रूप से, एसक्यूएल प्रोफाइलर उपकरण धीमी क्वेरी खोजने के लिए सबसे अच्छा प्रारंभिक बिंदु है।ऐसे डेटा कॉलम हैं जो प्रत्येक SQL बैच की सीपीयू और आईओ लागत को इंगित करते हैं, जो आपको सबसे खराब अपराधियों को इंगित करना चाहिए। एक बार जब आपको समस्याएं मिलती हैं, तो मैं इन प्रश्नों में से प्रत्येक के लिए क्वेरी योजनाएं उत्पन्न करने के लिए क्वेरी विश्लेषक का उपयोग करूंगा, और देख सकता हूं कि आप उन्हें बता सकते हैं कि उन्हें क्या धीमा कर रहा है। एक क्वेरी विंडो खोलकर, अपनी क्वेरी दर्ज करके और Ctrl + L दबाकर ऐसा करें। जो धीमा हो सकता है उसकी पूरी चर्चा पूरी किताब भर जाएगी, लेकिन अच्छी चीजें देखने के लिए टेबल स्कैन (बड़ी टेबल के लिए बहुत धीमी) और अक्षम शामिल हैं।

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

मैं भी कैसे चीजें तेजी से बनाने के लिए पर सुझाव के बहुत सारे के लिए इस वेबसाइट की सिफारिश:

http://www.sql-server-performance.com/

0

यदि आप उन्हें अलग-अलग ड्राइव पर रख सकते हैं - तार्किक लेकिन भौतिक ड्राइव नहीं तो आईओ आपको इतना धीमा नहीं कर रहा है।

0

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

0

यह प्रदर्शन के साथ मदद कर सकता है। कुछ टेबल/elemnts को डिस्क के अलग-अलग फ़ाइल क्षेत्रों/भागों में ले जाना। यह कुछ हद तक कम कर सकता है जिससे डाएबेस को प्रभावित करने वाले बाहरी विखंडन की मात्रा कम हो जाती है।

मैं अन्य कारकों जैसे कि tracesql को यह भी निर्धारित करने के लिए देखता हूं कि प्रश्न आदि क्यों धीमा हो रहे हैं - प्रश्न आंकड़े, एसपी रीकंपाइल आदि जैसे अन्य कारक भी ठीक हो सकते हैं जो आपको ठीक करने में आसान होते हैं और आपको प्रदर्शन में अधिक लाभ मिल सकते हैं।

1

लगभग 1000 क्या? एकल पंक्ति लिखती है? एकाधिक पंक्ति लेनदेन? हटाता है?

एक सामान्य टिप डेटा फ़ाइलों को रखने और अलग-अलग भौतिक ड्राइव पर फ़ाइलों को लॉग करने के लिए होगी। एसक्यूएल सर्वर लॉग को प्रत्येक लिखने का ट्रैक रखता है ताकि अलग-अलग ड्राइवों में आपको सामान्य बेहतर प्रदर्शन मिल सके।

लेकिन SQL सर्वर ट्यूनिंग इस बात पर निर्भर करती है कि एप्लिकेशन वास्तव में क्या कर रहा है। सामान्य युक्तियां हैं लेकिन आपको अपनी खुद की चीज मापनी है ...

1

जब आप रन प्रति के बारे में 100 टेबल बात करते हैं, आप वास्तव में मतलब है कि आप नए एसक्यूएल टेबल बना रहे हैं ? यदि ऐसा है, तो मुझे लगता है कि आपके आवेदन की वास्तुकला समस्या हो सकती है। मैं ऐसी परिस्थिति की कल्पना नहीं कर सकता जहां आपको कई नई तालिकाओं की आवश्यकता होगी क्योंकि कई ही तालिकाओं को कई बार पुन: उपयोग करने और रनों के बीच अंतर करने के लिए केवल एक कॉलम या दो जोड़ना है।

यदि आप पहले से ही टेबल के समान समूह का पुन: उपयोग कर रहे हैं और नए रनों का मतलब केवल उन तालिकाओं में अतिरिक्त पंक्तियों का है, तो समस्या यह हो सकती है कि समय के साथ नया डेटा कई तरीकों से प्रदर्शन को नुकसान पहुंचा रहा है। उदाहरण के लिए:

  1. कुछ समय बाद टेबल/इंडेक्स को खंडित किया जा सकता है। सुनिश्चित करें कि आपके सभी टेबलों में क्लस्टर्ड इंडेक्स है। Sys.DM_DB_INDEX_PHYSICAL_STATS का उपयोग करके विखंडन के लिए जांचें और उन्हें डिफ्रैग करने के लिए आवश्यक होने पर रीबिल विकल्प के साथ ALTER INDEX जारी करें।
  2. तालिकाएं बहुत बड़ी हो सकती हैं, ताकि छोटे टेबल पर अक्षम अब बड़ी तालिकाओं पर स्पष्ट हो। प्रदर्शन में सुधार के लिए टेबल पर उचित इंडेक्स देखें।
  3. SQL सर्वर क्वेरी योजनाओं (विशेष रूप से संग्रहीत प्रक्रियाओं के लिए) कैश करेगा, लेकिन यदि तालिका में डेटा महत्वपूर्ण समय के साथ बदलता है कि क्वेरी योजना अब उचित नहीं हो सकती है। यह देखने के लिए कि क्या इसकी आवश्यकता है, अपनी संग्रहीत प्रक्रियाओं के लिए sp_recompile में देखें।

# 2 वह अपराधी है जो मैं अक्सर वास्तविक दुनिया स्थितियों में देखता हूं। डेवलपर्स परीक्षण डेटा के केवल एक छोटे से सेट का उपयोग करके विकसित होते हैं और उचित अनुक्रमण को अनदेखा करते हैं क्योंकि आप 20 पंक्तियों की तालिका के साथ लगभग कुछ भी कर सकते हैं और यह तेज़ी से दिखाई देगा।

आशा है कि यह

0

अलग-अलग भौतिक ड्राइवों में तालिकाओं को विभाजित करें। यदि आपके पास वह डिस्क IO है, तो आपको एक सभ्य आईओ समाधान की आवश्यकता है। RAID 10, फास्ट डिस्क, लॉग और डीबी को अलग ड्राइव पर विभाजित करें।

अपनी वास्तुकला दोबारा जांचें - क्या आप एकाधिक डेटाबेस का उपयोग कर सकते हैं? यदि आप एक बार में कई टेबल बनाते हैं, तो आप जल्द ही कुछ रोचक बाधाओं को मार देंगे जिन्हें मुझे पहले से निपटना नहीं था। एकाधिक डीबी को हल करना चाहिए। एक "नियंत्रण" डीबी रखने के बारे में सोचें जिसमें आपके सभी मुख्य मेटा-डेटा, और फिर वास्तविक डेटा युक्त उपग्रह डीबी शामिल हैं।

आप अपने सर्वर के बारे में किसी भी चश्मा का उल्लेख नहीं करते हैं - लेकिन जब हम 8 जीबी से 20 जीबी रैम तक गए तो हमने प्रदर्शन में बढ़िया वृद्धि देखी।

संबंधित मुद्दे