जैसा कि डेटाबेस का प्रबंधन करने वाला कोई भी व्यक्ति बहुत अच्छी तरह से जानता है, इष्टतम प्रदर्शन सुनिश्चित करने के लिए SQL सर्वर प्रदर्शन ट्यूनिंग एक महत्वपूर्ण कार्य है। मेमोरी, कॉन्फ़िगरेशन, क्वेरी डिज़ाइन और संसाधन उपयोग जैसे विभिन्न कारकों पर निर्भर प्रदर्शन के साथ, प्रदर्शन में गिरावट के मूल कारण को अलग करना कोई छोटी उपलब्धि नहीं है।
प्रदर्शन समस्याओं के होने की प्रतीक्षा करने के बजाय, SQL सर्वर को सक्रिय रूप से ट्यून करने से आपके SQL कथनों को यथासंभव कुशलता से चलाने में मदद मिलेगी, जिससे SQL को आपके क्वेरी परिणाम देने के लिए सबसे तेज़ मार्ग खोजने में मदद मिलेगी।
यदि आप सुस्त प्रदर्शन के साथ संघर्ष कर रहे हैं—या आप केवल समस्याओं के उत्पन्न होने की प्रतीक्षा करने वाले व्यक्ति नहीं हैं—इष्टतम प्रदर्शन और स्वस्थ सिस्टम प्राप्त करने के लिए अपने SQL सर्वर प्रदर्शन ट्यूनिंग पर ध्यान केंद्रित करने के लिए यहां तीन प्रमुख क्षेत्र हैं।
टिप #1:अपना TempDB ऑप्टिमाइज़ करें
प्रदर्शन में गिरावट को देखते समय गलत तरीके से कॉन्फ़िगर किया गया TempDB एक सामान्य अपराधी है। यदि आप बार-बार अपना TempDB भर रहे हैं, तो यह देखने का समय है कि क्या बदलने की आवश्यकता है।
सबसे पहले, TempDB आकार देखें। यह कितना बड़ा होना चाहिए, इसके बारे में कोई कठोर और तेज़ नियम नहीं है, लेकिन अंगूठे का एक अच्छा नियम है कि TempDB को आपके सबसे बड़े डेटाबेस के 25 प्रतिशत या आपके सबसे बड़े सूचकांक के समान आकार में रखा जाए। यह पुनर्निर्माण के दौरान TempDB को बढ़ाने से रोकता है।
TempDB के साथ, ड्राइव जितनी तेज़ होगी, उतना ही बेहतर होगा। जब TempDB को धीमी ड्राइव या OS के समान ड्राइव पर रखा जाता है, तो आप निश्चित रूप से डेटाबेस प्रदर्शन समस्याओं को देखेंगे। यदि संभव हो, तो TempDB को एक समर्पित स्थानीय SSD पर रखें। यदि यह संभव नहीं है, तो आपका अगला सबसे अच्छा विकल्प पर्याप्त पूर्व-आवंटित डिस्क स्थान के साथ इसे अपने स्वयं के समर्पित वॉल्यूम पर रखना है।
डेटा और लॉग फ़ाइलों को अलग रखना और TempDB ऑटोग्रोथ के लिए एक बड़ा निश्चित मान निर्धारित करना भी महत्वपूर्ण है। अन्यथा, हर बार जब TempDB भरता है, तो आपको अनावश्यक ओवरहेड से मारा जाएगा।
TempDB डेटा फ़ाइलों की संख्या को नियंत्रित करने से TempDB अनुकूलन में योगदान होता है। लेकिन बड़ा सवाल यह है कि आपको कितने TempDB डेटा फ़ाइलों की आवश्यकता है? आदर्श रूप से, आपके पास प्रत्येक तार्किक CPU के लिए एक TempDB डेटा फ़ाइल होगी, लेकिन कुल आठ से अधिक नहीं (कुछ अपवादों के साथ)। उदाहरण के लिए, यदि आपके पास चार तार्किक CPU हैं, तो आपको चार TempDB डेटा फ़ाइलों की आवश्यकता है। यदि आपके पास 12 तार्किक CPU हैं, तो आपके पास आठ TempDB डेटा फ़ाइलें हो सकती हैं।
टिप #2:प्रदर्शन बाधाओं को रोकें
तीन मुख्य प्रकार के SQL सर्वर प्रदर्शन बाधाएं हैं जो खराब प्रदर्शन में योगदान करती हैं:CPU, मेमोरी और I/O। कारण, लक्षण और निदान अड़चन के प्रकार से भिन्न होते हैं, इसलिए यहां एक नज़र में यह देखने के लिए कि क्या देखना है:
CPU अड़चनें
कारण: अपर्याप्त हार्डवेयर संसाधन
लक्षण: लगातार उच्च प्रोसेसर उपयोग
निगरानी के लिए मीट्रिक: % प्रोसेसर समय, बैच अनुरोध/सेकंड, SQL संकलन/सेकंड और SQL पुनर्संयोजन/सेकंड
स्मृति बाधाएं
कारण: SQL सर्वर, सिस्टम या अन्य एप्लिकेशन गतिविधि के कारण उपलब्ध मेमोरी और मेमोरी दबाव में सीमाएं
लक्षण: धीमी एप्लिकेशन प्रतिक्रिया, संपूर्ण सिस्टम मंदी और एप्लिकेशन क्रैश
निगरानी के लिए मीट्रिक: मेमोरी उपलब्ध (केबी), कुल सर्वर मेमोरी (केबी), लक्ष्य सर्वर मेमोरी (केबी), पेज/सेक, चेकपॉइंट पेज/सेक, आलसी राइट्स/सेक और बफर कैश हिट अनुपात
I/O अड़चनें
कारण: डिस्क से और उस पर डेटाबेस पृष्ठों का अत्यधिक पढ़ना और लिखना
लक्षण: लंबे समय तक प्रतिक्रिया समय, एप्लिकेशन धीमापन और कार्य समय-बाह्य
निगरानी के लिए मीट्रिक: औसत डिस्क कतार लंबाई, औसत डिस्क सेकंड/पढ़ें, औसत डिस्क सेकंड/लिखें,% डिस्क समय, औसत डिस्क रीड/सेकंड और औसत डिस्क लेखन/सेकंड
टिप #3:सुनिश्चित करें कि अनुक्रमणिका ठीक से डिज़ाइन की गई हैं
अनुक्रमणिका कुछ SQL सर्वर संचालनों को गति देने का एक शानदार तरीका है, लेकिन केवल तभी जब वे अच्छी तरह से डिज़ाइन किए गए हों। खराब डिज़ाइन किए गए इंडेक्स का विपरीत प्रभाव पड़ता है और यह आपके SQL सर्वर के प्रदर्शन को खत्म करने का एक निश्चित तरीका है।
इन चार क्षेत्रों को ठीक से सेट करने से यह सुनिश्चित करने में मदद मिल सकती है कि इंडेक्स ठीक से डिज़ाइन किए गए हैं और SQL सर्वर के प्रदर्शन को नुकसान पहुंचाने के बजाय मदद करते हैं।
टेबल का आकार
अनुक्रमण के लिए प्रत्येक तालिका एक अच्छा उम्मीदवार नहीं है। वास्तव में, यदि कोई तालिका बहुत छोटी है, तो SQL सर्वर के लिए यह अधिक कुशल है कि वह संपूर्ण तालिका को खोजे बनाम अनुक्रमणिका के माध्यम से खोजे। बेशक, बड़ी तालिकाओं के लिए विपरीत सच है, इसलिए आपको यह तय करते समय संभावित ओवरहेड को तौलना होगा कि कौन सी तालिकाएँ अनुक्रमणिका से लाभान्वित होंगी।
सूचकांक प्रकार
तकनीकी रूप से, प्रत्येक डेटाबेस तालिका में एक क्लस्टर इंडेक्स और अनंत संख्या में गैर-क्लस्टर इंडेक्स हो सकते हैं, लेकिन आप जानते हैं कि वे "सिर्फ इसलिए कि आप कुछ कर सकते हैं" के बारे में क्या कहते हैं…
बहुत सारे गैर-क्लस्टर इंडेक्स इंसर्ट और अपडेट ऑपरेशंस को काफी धीमा कर सकते हैं, इसलिए एक क्लस्टर इंडेक्स और बिल्कुल जरूरी नॉन-क्लस्टर इंडेक्स की न्यूनतम संख्या से चिपके रहना एक बेहतर डिजाइन विकल्प है।
सूचकांक संग्रहण
डिज़ाइन चरण के दौरान, अनुक्रमणिका के लिए उचित संग्रहण मानदंड का चयन करना I/O प्रदर्शन के लिए महत्वपूर्ण है। विभाजित क्लस्टर इंडेक्स और गैर-क्लस्टर इंडेक्स को एक ही फाइलग्रुप पर मुख्य टेबल के रूप में संग्रहीत किया जा सकता है, या उन्हें एक अलग फाइलग्रुप पर संग्रहीत किया जा सकता है। किसी भिन्न डिस्क ड्राइव पर स्थित फ़ाइल समूह में गैर-संकुल अनुक्रमणिका को संग्रहीत करने से इसका उपयोग करने वाली क्वेरी के प्रदर्शन में सुधार हो सकता है, क्योंकि यह डेटा के समवर्ती पठन और विभिन्न डिस्क ड्राइव पर होने वाले SQL अनुक्रमणिका पृष्ठों से प्रभावित नहीं होता है।
फिलफैक्टर
FILLFACTOR उस स्थान का प्रतिशत निर्दिष्ट करता है जो अनुक्रमणिका बनाते समय प्रत्येक डेटा पृष्ठ पर भरा जाएगा। FILLFACTOR मान 0 प्रतिशत (कोई भी डेटा पृष्ठ नहीं भरा गया है) से लेकर 100 प्रतिशत (डेटा पृष्ठ पूरी तरह से भरा हुआ) तक हो सकता है। अपनी अनुक्रमणिका डिज़ाइन करते समय, एक FILLFACTOR मान चुनें जो अत्यधिक अनुक्रमणिका विखंडन के जोखिम को कम करते हुए पृष्ठ उपयोग को अनुकूलित करेगा।
SQL सर्वर के प्रदर्शन को अपनी मानक दिनचर्या का हिस्सा बनाना यह सुनिश्चित करने का एक शानदार तरीका है कि आपके डेटाबेस चरम प्रदर्शन पर चलते हैं। अपने नियमित SQL सर्वर रखरखाव योजनाओं में इन तीन सरल चरणों को शामिल करने से आपके उपयोगकर्ताओं के लिए गति और प्रदर्शन में उल्लेखनीय रूप से सुधार होगा।
