प्रोएक्टिव SQL सर्वर स्वास्थ्य जाँच, भाग 4 :ERRORLOG

इतिहास और महत्व के बारे में आप बहुत कुछ कह सकते हैं। एक देश का इतिहास, सभ्यता का, हम में से प्रत्येक का। मुझे टेडी रूजवेल्ट (अच्छे आदमी) के उद्धरण पसंद हैं और इसे पसंद करते हैं:

मैं SQL सर्वर के बारे में ब्लॉग में इतिहास के बारे में काव्यात्मक (या कोशिश) क्यों कर रहा हूं? क्योंकि SQL सर्वर में इतिहास भी महत्वपूर्ण है। जब SQL सर्वर में कोई प्रदर्शन समस्या मौजूद होती है, तो समस्या का लाइव निवारण करना आदर्श होता है, लेकिन कुछ मामलों में, ऐतिहासिक जानकारी धूम्रपान बंदूक, या कम से कम एक प्रारंभिक बिंदु प्रदान कर सकती है। SQL सर्वर में ऐतिहासिक जानकारी का एक बड़ा स्रोत ERRORLOG है। मैंने अपनी मूल पोस्ट, परफॉर्मेंस इश्यूज:द फर्स्ट एनकाउंटर में उल्लेख किया है कि ERRORLOG मेरे लिए एक विचार हुआ करता था। अब और नहीं। क्लाइंट ऑडिट के दौरान हम हमेशा ERRORLOG को कैप्चर करते हैं, और जब हमें किसी भी उच्च-गंभीर अलर्ट (जो लॉग पर लिखा जाता है) के लिए अधिसूचित किया जाता है, लॉग में अन्य रोचक जानकारी ढूंढना अनसुना नहीं है। हम लॉग में ऐतिहासिक जानकारी का उपयोग करके भविष्य की तैयारी करते हैं; जानकारी किसी समस्या, या संभावित समस्या के विनाशकारी होने से पहले उसे ठीक करने में हमारी मदद कर सकती है।

ERRORLOG देखना

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

अगर मैं अपने स्वास्थ्य ऑडिट में से किसी एक में कैप्चर किए गए डेटा को देख रहा हूं, तो मैं सिर्फ एक टेक्स्ट एडिटर में लॉग फाइल खोलूंगा और उनकी समीक्षा करूंगा (मेरे पास व्यूअर में जाने और उन्हें लोड करने का विकल्प भी है)। लॉग फ़ाइलें लॉग फ़ोल्डर में मौजूद होती हैं (डिफ़ॉल्ट स्थान:C:\Program Files\Microsoft SQL Server\MSSQL12.SQL2014\MSSQL\Log) अगर मैं कभी उन्हें सर्वर पर देखना चाहता हूं। आप में से कई लोग गैर-दस्तावेज प्रक्रिया sp_readerrorlog या विस्तारित संग्रहीत कार्यविधि xp_readerrorlog का उपयोग करके लॉग को देखना और/या खोजना पसंद कर सकते हैं।

और अंत में, यदि आप सभी PowerShell में हैं, तो उस तरह से लॉग पढ़ने का एक विकल्प भी है (इस पोस्ट को देखें:SQL Server 2012 त्रुटि लॉग को पार्स करने के लिए PowerShell का उपयोग करें)। विधि आप पर निर्भर है - जो आप जानते हैं उसका उपयोग करें और आपके लिए क्या काम करता है - यह वह सामग्री है जो वास्तव में मायने रखती है। और याद रखें कि ऐसे समय होते हैं जब आपको घटनाओं के क्रम को समझने के लिए केवल लॉग के माध्यम से पढ़ने की आवश्यकता होती है, और कई बार आप किसी विशिष्ट त्रुटि या जानकारी को खोजने के लिए खोज कर सकते हैं।

ERRORLOG में क्या है?

तो त्रुटियों के अलावा, हम ERRORLOG में क्या जानकारी प्राप्त कर सकते हैं? मैंने नीचे उन कई वस्तुओं को सूचीबद्ध किया है जो मुझे सबसे उपयोगी लगी हैं। ध्यान दें कि यह एक विस्तृत सूची नहीं है (और मुझे यकीन है कि आप में से कई के पास सुझाव होंगे कि क्या जोड़ा जा सकता है - एक टिप्पणी पोस्ट करने के लिए स्वतंत्र महसूस करें और मैं इसे अपडेट कर सकता हूं!), लेकिन फिर से, मैं यही हूं पहले ढूंढ रहे हैं जब मैं लगातार किसी उदाहरण को देख रहा होता हूं।

• सर्वर भौतिक है या आभासी (सिस्टम निर्माता प्रविष्टि देखें)
• स्टार्टअप पर ट्रेस फ़्लैग सक्षम किए गए
  • रजिस्ट्री स्टार्टअप पैरामीटर के लिए प्रविष्टि के भीतर, यदि आप पूरी तरह से दाईं ओर स्क्रॉल करते हैं, तो आप देखेंगे कि क्या कोई ट्रेस फ़्लैग सक्षम है:
    
    स्टार्टअप पर ट्रेस फ्लैग सक्षम किए गए हैं
• इंस्टेंस शुरू होने के बाद ट्रेस फ़्लैग सक्षम या अक्षम किए गए
  • यदि उपयोगकर्ता (या कोई एप्लिकेशन) DBCC TRACEON या DBCC TRACEOFF का उपयोग करके ट्रेस फ़्लैग को सक्षम या अक्षम करते हैं, तो लॉग में एक प्रविष्टि दिखाई देती है
• एसक्यूएल सर्वर द्वारा पता लगाए गए कोर और सॉकेट की संख्या
  • मैं हमेशा यह सत्यापित करना चाहता हूं कि SQL सर्वर उपलब्ध सभी हार्डवेयर को देखता है - और यदि नहीं, तो आगे की जांच के लिए यह एक लाल झंडा है। एक अच्छे उदाहरण के लिए, जोनाथन की पोस्ट देखें, सीएएल लाइसेंसिंग के तहत SQL सर्वर 0212 एंटरप्राइज़ संस्करण के साथ प्रदर्शन समस्याएं, और ग्लेन की पोस्ट, आपके उपलब्ध SQL सर्वर कोर लाइसेंस को समान रूप से NUMA नोड्स में संतुलित करना, जिसमें लॉग को क्वेरी करने के लिए कुछ आसान TSQL भी शामिल हैं।
  • ध्यान दें कि इस प्रविष्टि का पाठ SQL सर्वर संस्करणों के बीच भिन्न होता है।
• एसक्यूएल सर्वर द्वारा पता की गई मेमोरी की मात्रा
  • फिर से, मैं यह सत्यापित करना चाहता हूं कि SQL सर्वर उसके लिए उपलब्ध सभी मेमोरी को देखता है।
• पुष्टिकरण कि लॉक्ड पेज इन मेमोरी (LPIM) सक्षम है
  • जबकि यह विकल्प Windows सुरक्षा नीति के माध्यम से सक्षम किया गया है, आप लॉग में "मेमोरी मैनेजर में लॉक किए गए पृष्ठों का उपयोग करना" संदेश ढूंढकर पुष्टि कर सकते हैं कि यह सक्षम है।
  • ध्यान दें कि यदि आपके पास ट्रेस फ्लैग 834 उपयोग में है, तो संदेश लॉक किए गए पृष्ठ नहीं कहेगा, यह कहेगा कि बफर पूल के लिए बड़े पृष्ठों का उपयोग किया जा रहा है।
• सीएलआर का संस्करण प्रयोग में है
• सेवा प्रधान नाम (एसपीएन) पंजीकरण की सफलता या विफलता
• डेटाबेस को ऑनलाइन आने में कितना समय लगता है
  • लॉग रिकॉर्ड जब डेटाबेस शुरू होता है, और जब यह ऑनलाइन होता है - मैं यह देखने के लिए जांच करता हूं कि कोई डेटाबेस आने में अत्यधिक समय लेता है या नहीं।
• सेवा ब्रोकर की स्थिति और डेटाबेस मिररिंग एंडपॉइंट - महत्वपूर्ण यदि आप किसी भी सुविधा का उपयोग कर रहे हैं
• पुष्टिकरण कि तत्काल फ़ाइल आरंभीकरण (IFI) सक्षम है*
  • डिफ़ॉल्ट रूप से यह जानकारी लॉग नहीं होती है, लेकिन यदि आप ट्रेस फ्लैग 3004 (और 3605 को लॉग में आउटपुट को बाध्य करने के लिए) सक्षम करते हैं, तो जब आप डेटा फ़ाइल बनाते या बढ़ाते हैं, तो आप लॉग में संदेश देखेंगे कि क्या IFI उपयोग में है या नहीं।
• एसक्यूएल ट्रेस की स्थिति
  • जब आप SQL ट्रेस को प्रारंभ या बंद करते हैं, तो यह लॉग हो जाता है, और मैं यह देखने के लिए देखता हूं कि क्या डिफ़ॉल्ट ट्रेस से परे कोई ट्रेस मौजूद है (या तो अस्थायी या दीर्घकालिक)। यदि आप एक तृतीय-पक्ष निगरानी उपकरण चला रहे हैं, जैसे कि SQL संतरी का प्रदर्शन सलाहकार, तो आप एक सक्रिय ट्रेस देख सकते हैं जो हमेशा चल रहा है, लेकिन केवल विशिष्ट घटनाओं को कैप्चर कर रहा है, या आप एक ट्रेस प्रारंभ देख सकते हैं, छोटी अवधि के लिए चला सकते हैं, फिर रुकना। मैं एक या दो अतिरिक्त ट्रेस के बारे में चिंतित नहीं हूं, जब तक कि वे बहुत सारी घटनाओं को कैप्चर नहीं कर रहे हों, लेकिन जब कई ट्रेस चल रहे हों तो मैं निश्चित रूप से ध्यान देता हूं।
• पिछली बार CHECKDB पूरा हुआ था
  • यह संदेश अक्सर लोगों द्वारा गलत समझा जाता है - जब इंस्टेंस शुरू होता है, तो यह प्रत्येक डेटाबेस के लिए बूट पेज पढ़ता है और नोट करता है कि CHECKDB पिछली बार सफलतापूर्वक कब चला था। अधिकांश लोग पूरा संदेश नहीं पढ़ते:
    
    वह दिनांक जब DBCC CHECKDB अंतिम बार सफलतापूर्वक पूरा हुआ

    CHECKDB के पूरा होने की तारीख 11 नवंबर, 2012 है, लेकिन ERRORLOG की तारीख 7 जुलाई, 2015 है। यह समझना महत्वपूर्ण है कि SQL सर्वर नहीं करता है। स्टार्टअप पर डेटाबेस के खिलाफ CHECKDB चलाएँ, यह बूट पेज पर dbcclastknowngood मान की जाँच करता है (यह देखने के लिए कि यह कब अपडेट हो जाता है, मेरी पोस्ट देखें, What Checks Update dbcclastknowngood। इसके अलावा, यदि DBCC CHECKDB किसी डेटाबेस के विरुद्ध कभी नहीं चलाया गया है, तो कोई प्रविष्टि नहीं डेटाबेस के लिए यहां दिखाई देगा।

• CHECKDB पूर्णता
  • जब CHECKDB किसी डेटाबेस के विरुद्ध चलाया जाता है, तो आउटपुट लॉग में रिकॉर्ड किया जाता है।
• इंस्टेंस सेटिंग में बदलाव
  • यदि आप sp_configure का उपयोग करके या UI के माध्यम से इंस्टेंस-स्तरीय सेटिंग (उदा. अधिकतम सर्वर मेमोरी, समांतरता के लिए लागत सीमा) बदलते हैं (ध्यान दें कि यह लॉग नहीं करता है कौन इसे बदल दिया)।

• डेटाबेस सेटिंग्स में परिवर्तन
  • क्या किसी ने AUTO_SHRINK को सक्षम किया है? RECOVERY विकल्प को SIMPLE में बदलें और फिर वापस FULL में बदलें? आप इसे यहां पाएंगे।
• डेटाबेस स्थिति में परिवर्तन
  • यदि कोई डेटाबेस ऑफ़लाइन लेता है (या इसे ऑनलाइन लाता है), तो यह लॉग हो जाता है।
• गतिरोध की जानकारी*
  • यदि आपको गतिरोध की जानकारी प्राप्त करने की आवश्यकता है, तो कोई ट्रेस नहीं चलाना चाहते, और आप 2008R2 के माध्यम से SQL Server 2005 चला रहे हैं, XML स्वरूप में लॉग में गतिरोध जानकारी लिखने के लिए ट्रेस फ़्लैग 1222 का उपयोग करें। आप में से जो SQL Server 2000 और उससे नीचे का उपयोग कर रहे हैं, आप फ़्लैग 1204 को ट्रेस कर सकते हैं (यह ट्रेस फ़्लैग SQL Server 2005+ में भी उपलब्ध है, लेकिन यह न्यूनतम जानकारी आउटपुट करता है)। यदि आप SQL Server 2012 या उच्चतर चला रहे हैं, तो इसकी आवश्यकता नहीं है, क्योंकि system_health ईवेंट सत्र इस जानकारी को कैप्चर करता है (और यह 2008 और 20082 में भी है, लेकिन आपको इसे ring_buffer बनाम event_file लक्ष्य से खींचना होगा)।
• फ्लश कैश संदेश
  • यदि कैश को SQL सर्वर द्वारा फ़्लश किया जा रहा है क्योंकि चेकपॉइंट प्रक्रिया डेटाबेस के लिए पुनर्प्राप्ति अंतराल से अधिक है, तो आपको लॉग में FlushCache संदेशों का एक सेट दिखाई देगा (अधिक जानकारी के लिए बॉब डोर द्वारा यह पोस्ट देखें)। जब आप DBCC FREEPROCCACHE या DBCC FREESYSTEMCACHE चलाते हैं तो इन संदेशों को उन संदेशों के साथ भ्रमित न करें जो दिखाई देते हैं:
    
    DBCC FREEPROCCACHE या DBCC FREESYSTEMCACHE चलाने के बाद संदेश

• AppDomain संदेशों को अनलोड करें
  • लॉग यह भी नोट करता है कि AppDomains कब बनाया जाता है, और आप केवल तभी देखेंगे जब आप CLR का उपयोग कर रहे हों। अगर मुझे स्मृति दबाव के कारण ऐपडोमेन अनलोड संदेश दिखाई देता है, तो यह आगे की जांच करने के लिए कुछ है।

लॉग में अन्य जानकारी है जो उपयोगी है, जैसे प्रमाणीकरण मोड उपयोग में, समर्पित व्यवस्थापक कनेक्शन (डीएसी) सक्षम है या नहीं, आदि। लेकिन मैं इसे sys.configurations से भी प्राप्त कर सकता हूं और मैं उन्हें इंस्टेंस बेसलाइन के साथ जांचता हूं मैंने पहले चर्चा की (प्रोएक्टिव SQL सर्वर स्वास्थ्य जांच, भाग 3:उदाहरण और डेटाबेस सेटिंग्स)।

ERROLOG में ऐसा क्या नहीं है, जिसकी आप अपेक्षा कर सकते हैं?

यह एक छोटी सूची है, अभी के लिए, जैसा कि मैं अनुमान लगा रहा हूं कि आप में से कुछ को अन्य चीजें मिल सकती हैं जो आपने सोचा था कि लॉग में होंगी, लेकिन नहीं थीं…

• डेटाबेस फ़ाइलें या फ़ाइल समूह जोड़ना या हटाना
• विस्तारित ईवेंट सत्र प्रारंभ करना या रोकना
  • हालांकि, यदि आप सर्वर स्तर का DDL ट्रिगर या ईवेंट नोटिफिकेशन परिनियोजित करते हैं, तो आप इस जानकारी को लॉग कर सकते हैं। अधिक विवरण के लिए, जोनाथन की पोस्ट देखें, विस्तारित ईवेंट लॉगिंग को ERRORLOG में बदलें।
• DBCC DROPCLEANBUFFERS चलाना ERRORLOG में दिखाई देता है

लॉग को प्रबंधित करना

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

फ़ाइलों को प्रबंधित करने के अलावा, आप लॉग में लिखी जाने वाली जानकारी को प्रभावित कर सकते हैं। ERRORLOG में अव्यवस्था पैदा करने वाली सबसे आम प्रविष्टियों में से एक सफल बैकअप प्रविष्टि है:

बैकअप सफलतापूर्वक पूरा हुआ

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

संदेशों का एक और सेट जो लॉग को अव्यवस्थित करता है, सफल लॉगिन संदेश हैं। यह एक विकल्प है जिसे आप सुरक्षा टैब पर उदाहरण के लिए कॉन्फ़िगर करते हैं:

सफल और/या असफल लॉगिन लॉग करने के लिए सुरक्षा विकल्प

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

ERRORLOG को कम मत समझो

जैसा कि आप देख सकते हैं, ERRORLOG में कुछ बेहतरीन जानकारी है जिसका उपयोग आप न केवल प्रदर्शन के समस्या निवारण या त्रुटियों की जांच करते समय कर सकते हैं, बल्कि तब भी जब आप किसी आवृत्ति की लगातार निगरानी कर रहे हों। आप लॉग में जानकारी पा सकते हैं जो कहीं और नहीं मिलती है; सुनिश्चित करें कि आप इसे नियमित रूप से जांच रहे हैं और इसे बाद के विचार के रूप में नहीं छोड़ रहे हैं।

इस श्रृंखला के अन्य भाग देखें:

• भाग 1 :डिस्क स्थान
• भाग 2 :रखरखाव
• भाग 3 :उदाहरण और डेटाबेस सेटिंग