सामान्य SQL सर्वर दुर्घटनाएँ

मैं कई वर्षों से सामान्य SQL सर्वर गलतियों के बारे में पढ़ा और लिख रहा हूँ। मैंने इसके बारे में वर्षों पहले भी एक ब्लॉग लिखा था, लेकिन जैसे-जैसे समय बीतता गया, मार्गदर्शन थोड़ा बदल गया। यह लेख मेरे पिछले लेख का विस्तार करेगा और बताएगा कि ये SQL सर्वर, Azure SQL डेटाबेस और Azure SQL प्रबंधित इंस्टेंस पर कैसे लागू होते हैं।

कई सालों से मैंने उपयोगकर्ताओं को वही गलतियाँ करते हुए पाया है। मैं उन्हें गलतियाँ कहता हूँ, हालाँकि, ज्यादातर मामलों में, यह अधिक सही है कि चीजें ठीक से नहीं की जा रही हैं क्योंकि पर्यावरण का प्रबंधन करने वाले लोग इससे बेहतर नहीं जानते हैं। यहां कुछ अधिक महत्वपूर्ण आइटम दिए गए हैं जिनके बारे में SQL सर्वर को स्थापित और समर्थन करने वाले किसी को भी पता होना चाहिए:

• बैकअप
• DBCC CHECKDB
• मेमोरी सेटिंग
• सांख्यिकी
• अनुक्रमणिका रखरखाव
• MAXDOP और समानता के लिए लागत सीमा
• SQL सर्वर एजेंट अलर्ट

बैकअप

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

• कोई बैकअप बिल्कुल नहीं - डेटाबेस के लिए किसी भी बैकअप का कोई रिकॉर्ड नहीं
• अनुपलब्ध बैकअप - पूर्ण पुनर्प्राप्ति मॉडल का उपयोग करने वाले डेटाबेस के लिए कोई लॉग बैकअप नहीं
• कोई हालिया बैकअप नहीं - पिछला बैकअप सप्ताह/महीने/वर्ष पुराना था

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

यह स्थिति ऑन-प्रिमाइसेस SQL ​​सर्वर और IaaS पर लागू होती है। Azure SQL डेटाबेस और Azure प्रबंधित इंस्टेंस ने बैकअप प्रबंधित किए हैं।

DBCC CHECKDB

डेटाबेस भ्रष्टाचार दुर्भाग्य से होता है। भ्रष्टाचार के लिए नियमित रूप से जाँच किए बिना, जब ग्राहक उस भ्रष्टाचार से भौतिक डेटा को प्रभावित करता है, तो उसे पुनर्प्राप्त करने के लिए बैकअप न होने के कारण ग्राहक खुद को एक बुरी जगह पर पा सकते हैं। भ्रष्टाचार की जांच के लिए, प्रत्येक डेटाबेस के विरुद्ध नियमित आधार पर DBCC CHECKDB चलाया जाना चाहिए। मुझे जो मिल रहा है वह बैकअप के समान है:

• कोई DBCC CHECKDBs बिल्कुल भी निष्पादित नहीं किया गया
• DBCC CHECKDBs केवल चुनिंदा डेटाबेस पर निष्पादित किए जा रहे हैं
• DBCC CHECKDB अंतिम बार महीनों या वर्षों पहले निष्पादित किया गया

सबसे खराब स्थिति एक जॉब शेड्यूल्ड रिपोर्टिंग है जो विफल DBCC CHECKDBs

जब भ्रष्टाचार एक ढेर या क्लस्टर इंडेक्स हो और भ्रष्टाचार होने से पहले कोई बैकअप न हो, तो भ्रष्टाचार का पता लगाना या भ्रष्टाचार के मुद्दे पर ग्राहक तक पहुंचना कभी भी सुखद नहीं होता है। इन मामलों में, भ्रष्टाचार वास्तविक डेटा है और भ्रष्टाचार से पहले से बहाल करना ज्यादातर मामलों में एकमात्र विकल्प है। ऐसे मामलों में जहां भ्रष्टाचार एक गैर-संकुल अनुक्रमणिका है, अनुक्रमणिका का पुनर्निर्माण करना ठीक है।

कुछ स्थितियों में, मुझे उन ग्राहकों के साथ काम करना पड़ता है जिनके पास उचित बैकअप के बिना खराब भ्रष्टाचार है, जहां मैं डेटाबेस को स्क्रिप्ट करने में सक्षम हूं और सभी उपयोग योग्य डेटा को नए बनाए गए डेटाबेस में मैन्युअल रूप से कॉपी कर सकता हूं। DBCC CHECKDB चलाकर और उचित बैकअप प्रतिधारण करके इन महंगी स्थितियों से आसानी से बचा जा सकता है।

मैं ग्राहकों को DBCC CHECKDB ऑन-प्रिमाइसेस, IaaS, Azure SQL डेटाबेस और Azure SQL प्रबंधित इंस्टेंस चलाने की सलाह देता हूँ। Azure शारीरिक भ्रष्टाचार की जाँच के लिए बहुत अच्छा काम करता है; हालांकि, मुझे लगता है कि उपभोक्ताओं को तार्किक भ्रष्टाचार के लिए जाँच करने की आवश्यकता है।

मेमोरी सेटिंग

Microsoft SQL सर्वर की एक डिफ़ॉल्ट स्थापना में न्यूनतम मेमोरी मान 0 पर सेट होता है और अधिकतम सर्वर मेमोरी मान 2147483647 MB ​​पर सेट होता है, जो कि 2 पेटाबाइट है। SQL सर्वर 2012 से पहले, अधिकतम सर्वर मेमोरी मान केवल बफ़रपूल पर लागू होता था, इसलिए ग्राहकों को ऑपरेटिंग सिस्टम और अन्य प्रक्रियाओं के लिए मेमोरी को बचाने के लिए बफरपूल द्वारा उपयोग की जाने वाली मेमोरी की मात्रा को सीमित करने की आवश्यकता होती है। SQL सर्वर 2012 ने एक मेमोरी मैनेजर को फिर से लिखना शुरू किया ताकि अधिकतम सर्वर मेमोरी मान सभी SQL सर्वर मेमोरी आवंटन पर लागू हो।

अपने SQL सर्वर इंस्टेंस के लिए अधिकतम मान सेट करना अत्यधिक उचित है। जोनाथन केहैयस ने एक ब्लॉग पोस्ट लिखा है कि मेरे SQL सर्वर को वास्तव में कितनी मेमोरी की आवश्यकता है, एक सूत्र के साथ जो अधिकतम मेमोरी मान के लिए आधार रेखा स्थापित करने में मदद करता है। साझा SQL सर्वर के मामलों में, मैं अपने क्लाइंट को सर्वर पर न्यूनतम मान को 30% मेमोरी पर सेट करने की सलाह देता हूं।

कई उदाहरणों वाली स्थितियों में या जहां सर्वर का उपयोग SQL सर्वर, SSIS, SSAS, या SSRS के लिए किया जाता है, आपको यह मूल्यांकन करने की आवश्यकता है कि उन अन्य सिस्टमों को कितनी मेमोरी की आवश्यकता है और OS और अन्य के लिए पर्याप्त मेमोरी की अनुमति देने के लिए अधिकतम सर्वर मेमोरी मान को कम करें। सेवाएं।

यह समस्या ऑन-प्रिमाइसेस, IaaS और आंशिक रूप से Azure SQL प्रबंधित इंस्टेंस के लिए मान्य है। प्रबंधित इंस्टेंस तैनात स्तर के आधार पर अधिकतम सर्वर मेमोरी मान सेट करता है, हालांकि जब मैंने पर्यावरण का आकार बदलने का परीक्षण किया, तो अधिकतम मेमोरी मान गतिशील रूप से नहीं बदला गया था। उस स्थिति में, आपको मान को मैन्युअल रूप से अपडेट करना होगा। यह समस्या Azure SQL डेटाबेस पर लागू नहीं होती है।

आंकड़े

क्वेरी ऑप्टिमाइज़र निष्पादन योजनाएँ बनाने के लिए आँकड़ों का उपयोग करता है। इसका मतलब है कि SQL सर्वर को अद्यतित होने के लिए आंकड़ों की आवश्यकता है ताकि क्वेरी ऑप्टिमाइज़र के पास एक अच्छी निष्पादन योजना बनाने का बेहतर मौका हो। डिफ़ॉल्ट रूप से, डेटा की 20% +500 पंक्तियों को संशोधित करने के बाद आंकड़े अपडेट किए जाते हैं। इसमें बड़ी टेबल पर लंबा समय लग सकता है। संगतता स्तर 130 से शुरू होकर, बड़ी तालिकाओं के लिए सांख्यिकी अद्यतन की सीमा कम कर दी गई है। SQL सर्वर 2008R - 2014 के लिए, आप ट्रेस फ़्लैग 2371 का उपयोग करके इस सीमा को कम कर सकते हैं।

मैं नियमित रूप से पाता हूं कि ग्राहक मैन्युअल रूप से आंकड़े अपडेट नहीं कर रहे हैं और यहां तक ​​​​कि निचली सीमा के साथ, मैंने पाया है कि मैन्युअल रूप से अपडेट करने से वातावरण अधिक स्थिर हो जाता है।

मेरा सुझाव है कि ग्राहक आंकड़े अपडेट करने के लिए किसी तृतीय-पक्ष स्क्रिप्ट का उपयोग करें। Ola Hallengren ने SQL सर्वर के लिए व्यापक रूप से उपयोग किया जाने वाला रखरखाव समाधान प्रकाशित किया है। उस प्रक्रिया का एक हिस्सा उसकी इंडेक्स ऑप्टिमाइज़ प्रक्रिया है, जो आंकड़ों को अपडेट करने के लिए अतिरिक्त पैरामीटर ले सकती है।

@UpdateStatistics 
    ALL     = update index and column statistics
    INDEX   = update index statistics
    COLUMNS = update column statistics
    NULL    = Do not perform statistics maintenance (this is the default)

@OnlyModifiedStatistics
    Y = Update statistics only if rows have been modified since most recent stats update
    N = Update statistics regardless of whether any rows have been modified

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

अद्यतन आँकड़े ऑन-प्रिमाइसेस, IaaS, Azure SQL डेटाबेस और Azure SQL प्रबंधित इंस्टेंस पर लागू होते हैं।

इंडेक्स रखरखाव

अपनी अनुक्रमणिका से विखंडन को हटाकर अनुक्रमणिका रखरखाव करना अभी भी महत्वपूर्ण है। माइक्रोसॉफ्ट के कुछ सेवानिवृत्त दस्तावेज़ों में कहा गया है कि पर्यावरण के आकार और विखंडन के स्तर के आधार पर सूचकांक विखंडन का नकारात्मक प्रभाव 13-460% हो सकता है। जबकि इंटेलिजेंट SAN, सॉलिड स्टेट डिस्क, और अन्य प्रगति जैसे हार्डवेयर ने चीजों को गति देने में मदद की है, इंडेक्स में व्यर्थ स्थान बफर पूल में व्यर्थ स्थान के साथ-साथ अधिक I/O को बर्बाद कर सकता है।

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

मुझे ओला की स्क्रिप्ट और टेबल पर लॉग इन करने वाले थर्ड पार्टी टूल्स पसंद हैं। मैं तब तालिका को क्वेरी कर सकता हूं यह देखने के लिए कि क्या मेरे पास कोई इंडेक्स हॉट स्पॉट है जहां विखंडन लगातार उच्च स्तर पर हो रहा है और समस्या निवारण क्यों विखंडन इतना प्रचलित है और कुछ भी किया जा सकता है।

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

यह ऑन-प्रिमाइसेस, IaaS, Azure SQL डेटाबेस और Azure SQL प्रबंधित इंस्टेंस पर लागू होता है।

MAXDOP

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

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

यदि आप SQL Server 2008 - SQL Server 2014 पर हैं, तो 8 से कम लॉजिकल प्रोसेसर वाले एकल NUMA नोड के लिए, MAXDOP को लॉजिकल प्रोसेसर की संख्या पर या उससे कम रखें। यदि आपके पास 8 से अधिक तार्किक प्रोसेसर हैं, तो MAXDOP को 8 पर रखें। यदि आपके पास प्रति NUMA नोड में 8 से कम तार्किक प्रोसेसर वाले एकाधिक NUMA नोड हैं, तो MAXDOP को प्रति NUMA नोड पर तार्किक प्रोसेसर की संख्या पर या उससे कम रखें। 8 से बड़ा, MAXDOP को 8 पर रखें।

SQL सर्वर 2016 ने सॉफ्ट-NUMA नोड्स पेश किए। सेवा स्टार्टअप के दौरान, यदि डेटाबेस इंजन प्रति NUMA नोड या सॉकेट में 8 से अधिक भौतिक कोर का पता लगाता है, तो सॉफ्ट-NUMA नोड्स स्वचालित रूप से बनाए जाते हैं। इंजन तार्किक प्रोसेसर को एक ही भौतिक कोर से अलग-अलग सॉफ्ट-NUMA नोड्स में रखने का ख्याल रखता है। इस कारण से, SQL सर्वर 2016 के लिए MAXDOP के लिए हमारे पास थोड़ा अलग मार्गदर्शन है।

यदि आप SQL सर्वर 2016 और उसके बाद के संस्करण पर हैं, तो 16 से कम तार्किक प्रोसेसर वाले एकल NUMA नोड के लिए, MAXDOP को तार्किक प्रोसेसर की संख्या पर या उससे कम रखें। यदि आपके पास 16 से अधिक तार्किक प्रोसेसर हैं, तो MAXDOP को 16 पर रखें। यदि आपके पास प्रति NUMA नोड में 16 से कम तार्किक प्रोसेसर वाले एकाधिक NUMA नोड हैं, तो MAXDOP को प्रति NUMA नोड पर तार्किक प्रोसेसर की संख्या पर या उससे कम रखें। 16 से अधिक, MAXDOP को 16 के MAX मान के साथ प्रति NUMA नोड पर तार्किक प्रोसेसर की आधी संख्या पर रखें।

यदि आप डिफ़ॉल्ट MAXDOP वाले 8 या उससे कम तार्किक प्रोसेसर वाली मशीनों पर अधिकतर वर्चुअलाइज्ड हैं, तो आप शायद ठीक हैं। यदि आपके पास डिफ़ॉल्ट के साथ बड़ा भौतिक हार्डवेयर है, तो आपको MAXDOP को अनुकूलित करने पर विचार करना चाहिए।

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

MAXDOP को कॉन्फ़िगर करना ऑन-प्रिमाइसेस, IaaS और Azure SQL प्रबंधित इंस्टेंस पर लागू होता है। हालाँकि, एक डेटाबेस स्कोप्ड कॉन्फ़िगरेशन है जिसे SQL सर्वर 2016 से शुरू करके प्रति डेटाबेस लागू किया जा सकता है, और यह Azure SQL डेटाबेस पर लागू होता है।

समानांतरता के लिए लागत सीमा

समांतरता के लिए लागत सीमा का डिफ़ॉल्ट मान 5 है। इस संख्या का इतिहास SQL ​​सर्वर के शुरुआती दिनों में वापस जाता है और कार्यभार परीक्षण जिस कार्य केंद्र पर किया गया था। आधुनिक हार्डवेयर के साथ, लागत अनुमान 5 पुराना है। परीक्षण से पता चला है कि संख्या को 5 से उच्च मान तक बढ़ाने से समानांतर योजना होने से कम-चलने वाली क्वेरीज़ बनी रहेंगी। मैं प्लान कैश की जांच करने के बाद इस मान को अधिक संख्या में बढ़ाने की अनुशंसा करता हूं। कई मामलों में मैं 25 के मान से शुरू करता हूं और फिर आगे की निगरानी करता हूं और जरूरत पड़ने पर वहां से समायोजित करता हूं। समांतरता के लिए लागत सीमा को समायोजित करने के बारे में अधिक जानकारी के लिए, जोनाथन केहैयस ने लिखा:योजना कैश से ट्यूनिंग 'समानांतरता के लिए लागत सीमा'।

यह ऑन-प्रिमाइसेस, IaaS, और Azure SQL प्रबंधित इंस्टेंस पर लागू होता है।

SQL सर्वर एजेंट अलर्ट

प्रत्येक व्यक्ति को SQL एजेंट अलर्ट का लाभ उठाना चाहिए जब तक कि उनके पास समान त्रुटि स्थितियों के लिए तृतीय-पक्ष एप्लिकेशन मॉनिटरिंग न हो। अलर्ट कॉन्फ़िगर करना आसान और मुफ़्त है, और उन्हें कॉन्फ़िगर करने से आपके सर्वर में समस्या होने पर आपको महत्वपूर्ण जानकारी मिलेगी।

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

यह ऑन-प्रिमाइसेस, IaaS, और Azure SQL प्रबंधित इंस्टेंस पर लागू होता है।

सारांश

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