SQL Server 2008R2 के लिए इष्टतम ड्राइव कॉन्फ़िगरेशन


19

मेरे पास एक काफी व्यस्त डेटाबेस सर्वर है जो निम्न सेटअप वाले SQL Server 2008 R2 चला रहा है:

  • SATA RAID 1 (2 ड्राइव) - OS / प्रोग्राम
  • SAS RAID 10 (4 ड्राइव) - Sql डेटाबेस फ़ाइलें (डेटा और लॉग)
  • SAS RAID 1 (2 ड्राइव) - TempDB (डेटा और लॉग)

यह मानते हुए कि मैं इस सर्वर में अतिरिक्त ड्राइव नहीं जोड़ सकता, क्या मैंने उपलब्ध कॉन्फ़िगरेशन का सबसे अच्छा उपयोग किया है? या क्या मुझे यहाँ एक और योजना पर विचार करना चाहिए जहाँ लॉग को डेटा फ़ाइलों से अलग किया जाता है, उदाहरण के लिए?

अपडेट करें:

उन लोगों के लिए जो आगे हार्डवेयर विवरण का अनुरोध करते हैं:

  • SATA ड्राइव (OS / प्रोग्राम विभाजन के लिए प्रयुक्त) हैं: WD 7200 RPM 3 Gb / s 3.5 इंच SATA
  • अन्य सरणियों में उपयोग किए जाने वाले एसएएस ड्राइव हैं: सीगेट 15K आरपीएम 6 जीबी / एस 3.5 इंच एसएएस
  • RAID नियंत्रक का उपयोग किया जाता है: LSI 9260-8i SAS / SATA 6 Gb 8 पोर्ट

अपडेट 2:

मुझे मिली प्रतिक्रिया के आधार पर, ऐसा लगता है कि मेरे पास चुनने के लिए निम्नलिखित व्यवहार्य विकल्प हैं - मैं किसी को इनाम दूंगा जो मुझे बता सकता है कि जो वातावरण में सबसे अच्छा होने की संभावना है, जो मैंने उल्लिखित किया है:

  1. सब कुछ छोड़ दो - मैं शायद ज्यादा बेहतर नहीं करूँगा
  2. मेरे 2 SAS RAID 1 ड्राइव को मेरे मौजूदा RAID 10 सरणी में ले जाएं, ताकि कुल 6 डिस्क से बना हो
  3. एसएएस RAID 1 और / या टेम्प्डीबीडी (डेटा या लॉग्स) को वापस आरएसी 10 पर मेरी लॉग फाइलें स्थानांतरित करें

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

उच्च-प्रदर्शन NVMe और बाजार में अन्य SSD के डिस्क के साथ, SQL सर्वर डिस्क कॉन्फ़िगरेशन बेस्ट प्रैक्टिस के दृष्टिकोण से RAID अब बहुत महत्वपूर्ण नहीं है। डिस्क पूल (स्टोरेज स्पेस) आगे जाने का रास्ता है। हालाँकि, डिस्क से संबंधित प्रदर्शन समस्याओं के बेहतर निवारण के लिए आपको तार्किक रूप से वॉल्यूम को अलग करने की आवश्यकता होगी।
आईटी

जवाबों:


14

इस सवाल के वेरिएंट अर्ध-नियमित रूप से आते हैं:

डेटा / लॉग पृथक्करण "सर्वश्रेष्ठ अभ्यास" के बारे में कभी-कभार कुछ झगड़े भी होते हैं।

यह सर्वर क्या कर रहा है, इसके अधिक विस्तृत विश्लेषण के बिना, वही सलाह लागू होती है जो पहले दी गई थी।

  • ओएस के लिए RAID 1
  • RAID 10 (6 डिस्क) डेटा / लॉग / टेम्पर्ड के लिए

इतने कम स्पिंडल उपलब्ध होने के साथ विभाजन का कोई मतलब नहीं है। एक बड़ी IOP क्षमता वाला एक एकल सरणी आमतौर पर 2 छोटे सरणियों से बेहतर आपके कार्यभार के गांठ और धक्कों को सोख लेगा।

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

यह देखते हुए कि आपके OS ड्राइव 7200RPM कोस्टर हैं, मुझे आश्चर्य होगा कि OS ड्राइव कॉन्फिगर पर tempdb का कोई फायदा नहीं है।


7

यह सब आपके कार्यभार पर निर्भर करता है, लेकिन केवल 6 ड्राइव के साथ यह आपके विकल्पों को सीमित करता है। यदि आपका वर्कलोड टेम्पर्ड, हैश टेबल, और स्नैपशॉट अलगाव जैसी चीजों के लिए बहुत हद तक निर्भर नहीं है, तो आप RAID 10. में एक साथ 6 एसएएस ड्राइव का उपयोग करने से बेहतर हो सकते हैं। हालाँकि, यदि आप जानते हैं या साबित करने के लिए मेट्रिक्स हैं। tempdb का भारी उपयोग किया जाता है, फिर आपको इसे अपने पास अलग रखना चाहिए।


उत्तर के लिए धन्यवाद, श्रेणियों के विन्यास को बदलना (दुर्भाग्य से) एक विकल्प नहीं है क्योंकि यह सर्वर उत्पादन में है। मैं अस्थायी वापस स्विच करने के बारे में उत्सुक हूँ RAID 10 और सभी लॉग फाइल को RAID 1 पर रख रहा हूँ - हालांकि यह एक स्मार्ट विकल्प है?
दानप

2
याद रखें कि एसक्यूएल सर्वर को कमिटमेंट के हिस्से के रूप में लॉग इन करने के लिए सभी लेन-देन को भौतिक रूप से लिखने की आवश्यकता होती है, इसलिए आप चाहते हैं कि आपके कॉन्फिग के भीतर सबसे तेज लेखन प्रदर्शन संभव हो। RAID 10, RAID 1 से बेहतर लेखन प्रदर्शन प्रदान करता है, इसलिए मैं लॉग को तेज वॉल्यूम पर छोड़ दूंगा।
पैट्रिक किस्लर

2

यह बहुत हद तक इस बात पर निर्भर करता है कि आप "बहुत व्यस्त" से क्या मतलब रखते हैं: अलग-अलग वर्कलोड पैटर्न (भारी लिखें या नहीं, थोक संचालन सामान्य या नहीं, समवर्ती पहुंच का स्तर, नाम के लिए, लेकिन कई चर में से तीन) का व्यापक प्रभाव हो सकता है। किसी भी धुरी व्यवस्था का प्रदर्शन।

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

आपके कार्यभार (और उन ड्राइव और उनके और मशीन के बीच के किसी भी नियंत्रक की कल्पना) के संदर्भ के बिना, मैं तीन संस्करणों के लिए जाने के लिए इच्छुक हूं: ओएस + प्रोग्राम और टेम्पर्डब (डेटा) के लिए, मुख्य डीबी के लिए एक डेटा, और लॉग के लिए तीसरा (दोनों tempdb और मुख्य DBs)।

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


मैं निश्चित रूप से हमारे पर्यावरण को "भारी लेखन" के रूप में वर्णित करूंगा - मैं सोमवार को अधिक विस्तृत हार्डवेयर चश्मा के साथ अपने प्रश्न को अपडेट करूंगा।
डैनप

ओपी के पास ड्राइव की संख्या के बारे में कोई विचार है? मैं RAID 1 के बारे में अधिक सोच रहा हूं जो उसके पास लॉग फ़ाइलों के लिए है। लिखने के उद्देश्यों के लिए यह एक बढ़िया विकल्प की तरह नहीं लगता है, और AFAIK लॉग फ़ाइलें सीमित नहीं पढ़ी जाती हैं, लेकिन लिखें ..
Marian

मैंने मशीन के हार्डवेयर के बारे में अतिरिक्त चश्मा जोड़ा है।
दानप

1
यह गलतफहमी डेटा / लॉग जुदाई रेंट में से कई की जड़ में हो सकती है, इसलिए माफी मांगता हूं लेकिन मैं इसे बाहर करने जा रहा हूं। "... जैसा कि प्रत्येक लेखन में लॉग और डेटा फ़ाइलों दोनों को अपडेट करना शामिल है" - नहीं, यह नहीं है। डेटा पेजों पर लिखावट चेकपॉइंट पर होती है, हर संशोधन पर नहीं।
मार्क स्टोरी-स्मिथ

1
@DavidSpillett सच है, हमेशा ऐसे मामले होंगे जहां विभाजन फायदेमंद है। कुंजी यह है कि आपने परीक्षण किया और पुष्टि की कि कॉन्फ़िगरेशन उस विशेष कार्यभार के लिए फायदेमंद था।
मार्क स्टोरी-स्मिथ

2

वास्तविक उत्तर आपकी आवश्यकताओं पर निर्भर करता है लेकिन आम तौर पर "अलग-अलग सरणियों में डेटा और लॉग ऑन करें" "अपने स्वयं के सरणी पर टेम्पर्डब डाल" की तुलना में अधिक महत्व है।

आपके द्वारा उपलब्ध ड्राइव की संख्या को देखते हुए, मेरा शुरुआती बिंदु होगा:

  1. दो ड्राइव, RAID 1 - ऑपरेटिंग सिस्टम, निष्पादनयोग्य, पेजफाइल।
  2. चार ड्राइव, RAID 5 - सभी डेटा फ़ाइलें (वैकल्पिक रूप से, RAID 1 + 0)
  3. दो ड्राइव, RAID 1 - सभी लॉग फाइलें

विभिन्न ड्राइव कॉन्फ़िगरेशन के प्रदर्शन का परीक्षण करने के लिए SQLIO का उपयोग क्या करना चाहिए ।


यह निश्चित रूप से मेरे द्वारा पढ़ी गई सलाह के "दूसरे पक्ष" का प्रतिनिधित्व करता है। काश, यह निर्धारित करने की एक निश्चित विधि होती कि उत्पादन के माहौल में "इसे आज़माने" का सहारा लिए बिना कौन सा विकल्प बेहतर होगा।
दानप

2
@DPP खैर, मैं व्यक्तिगत रूप से मार्क की सलाह के साथ चला गया और बाकी ड्राइव (OS को छोड़कर) के साथ एक RAID10 चुना। लॉग फ़ाइलों को गहन लिखा जाता है और RAID 1 की पेशकश की तुलना में बेहतर प्रदर्शन की आवश्यकता होती है, जहां तक ​​मुझे लगता है। लेकिन मैं हार्डवेयर विशेषज्ञ नहीं हूं। बस मेरे 2 सेंट।
मैरियन

2
मुझे यह उल्लेख करना चाहिए कि मेरी राय केवल एक बेहतर सर्वर के अतीत (तरह) के असफल प्रवास के अनुभव से आती है, लेकिन खराब प्रदर्शन के साथ। हमने कभी भी इस नए सर्वर पर वास्तविक लोड का परीक्षण नहीं किया, हमारे पास कभी मौका नहीं था, सर्वर समय पर तैयार नहीं था। सर्वर के परीक्षण से बाहर निकलता है उत्पादन के लिए पलायन MANDATORY होना चाहिए। जोर देने के लिए क्षमा करें। इसलिए सभी माइग्रेशन / अपग्रेड के लिए मेरा मंत्र है: टेस्ट, टेस्ट, टेस्ट, ... जितना संभव हो उतना परीक्षण।
मारी

1
यकीन नहीं है कि RAID 5 या SQLIOSIM से शुरू करना है ... चलो बाद में अपने लिए पूर्व की बोलती है। SQLIOSIM एक शुद्धता और तनाव परीक्षण उपकरण है , यह एक प्रदर्शन या लोड परीक्षण उपकरण नहीं है। वर्कलोड-जेड के लिए config-X vs config-Y के प्रदर्शन की तुलना करने में इसकी कोई जगह नहीं है। सब आपको बताएगा कि SQLIOSIM रन में config-Y के खिलाफ कितनी अच्छी तरह से config-X प्रदर्शन करता है। यदि आप वर्कलोड-जेड के लिए प्रदर्शन की तुलना करना चाहते हैं, तो वर्कलोड-जेड का परीक्षण करें।
मार्क स्टोरी-स्मिथ

1
@GreenstoneWalker "RAID1, RAID1 + 0 की तुलना में लिखने के लिए तेज़ है" बकवास है। यह विचार कहां से आया?
मार्क स्टोरी-स्मिथ

-1

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

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

एक बात जिसका आपने उल्लेख नहीं किया, लेकिन कोशिश कर सकते हैं (यदि आप पहले से ही नहीं हैं): Microsoft आपके TempDB को कई फाइलों (एक सीपीयू प्रति) पर विभाजित करने की सलाह देता है। बेशक, यह सबसे अच्छा है अगर वे अलग-अलग डिस्क पर हैं, लेकिन बस अलग-अलग फाइलें होने से मदद मिलती है। http://msdn.microsoft.com/en-us/library/ms175527(v=SQL.105).aspx


4
Tempdb का उपयोग कई चीजों के लिए किया जाता है, लेकिन इसे फेंकने वाले डेटाबेस के रूप में नहीं मानते हैं और इसे RAID 0. पर रखते हैं। ध्यान रखें कि यदि RAID 0 वॉल्यूम विफल रहता है, तो SQL सर्वर प्रारंभ नहीं हो पाएगा।
पैट्रिक कीसलर

मैंने वास्तव में सुझाए गए अनुसार एक अस्थायी डीबी प्रति कोर बनाया है, लेकिन उस बिंदु को भी बढ़ाने के लिए धन्यवाद :)
DanP

1
वैसे ये सुझाव बहुत अच्छे नहीं हैं और हर पर्यावरण के लिए उचित नहीं हैं। पहले @PatrickKeisler द्वारा पहले उल्लेख किया गया है। दूसरा एक मिथक है कि कुछ समय पहले पॉल रान्डल ने डेब्यू किया था। लेख यह है: एक SQL सर्वर DBA एक दिन मिथक: (12/30) tempdb में हमेशा एक प्रोसेसर कोर के साथ एक डेटा फ़ाइल होनी चाहिए । तो एमएस प्रलेखन गलत हो सकता है, इसे दिल से न लें।
मारी

2
"चूंकि TempDB केवल डेटा बफ़र करता है, आप डेटा हानि का अनुभव नहीं कर सकते हैं" ... और मुझे यकीन है कि सिस्टम के उपयोगकर्ता इस बात की सराहना करेंगे कि डाउनटाइम के X घंटे के दौरान वे पीड़ित हैं) प्रतिस्थापन डिस्क या बी) एक डीबीए अपने मोबाइल फोन से हेल्पडेस्क को टेम्पर्डब को स्थानांतरित करने के तरीके को समझाने की कोशिश करता है।
मार्क स्टोरी-स्मिथ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.