प्रदर्शन के मुद्दे:पहला मुठभेड़

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

इस कारण से, मेरे पास पाँच वस्तुओं का एक सेट है जिसे मैं नए परिवेश का सामना करने पर तुरंत जाँचता हूँ। मेरे द्वारा एकत्रित की जाने वाली जानकारी आगे चलकर समस्या निवारण के लिए मेरे दृष्टिकोण के लिए चरण निर्धारित करती है, और जबकि यह शायद ही कभी द को इंगित करता है विशिष्ट समस्या, इससे मुझे यह पता लगाने में मदद मिलती है कि नहीं . क्या है समस्या, जो कभी-कभी उतनी ही महत्वपूर्ण होती है।

डेटा संग्रह के तरीके

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

सर्वर गुण

जब मैं किसी उदाहरण को देखता हूं तो सबसे पहली चीज जो मैं जानना चाहता हूं वह है SQL सर्वर संस्करण और संस्करण। इस जानकारी को प्राप्त करने का सबसे तेज़ तरीका निष्पादित करना है:

SELECT @@VERSION;

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

SELECT SERVERPROPERTY('IsClustered');

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

sys.configurations

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

SELECT [name], [value], [value_in_use], [description]
  FROM [sys].[configurations]
  ORDER BY [name];

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

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

sys.डेटाबेस

यह समझने के बाद कि इंस्टेंस कैसे कॉन्फ़िगर किया गया है, मैं अगली बार देखता हूं कि डेटाबेस स्तर पर क्या मौजूद है।

SELECT *
  FROM [sys].[databases]
  ORDER BY [database_id];

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

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

त्रुटि लॉग

मैं मानता हूँ, मैं SQL सर्वर ERRORLOG की उपेक्षा करता था; जब मैंने SQL सर्वर समस्या की जांच की तो यह एक विचार के बाद था। तब मुझे अपने तरीकों की त्रुटि का एहसास हुआ, और तब से मैंने इसे हल्के में नहीं लिया। मैं लॉग (प्रबंधन | SQL सर्वर लॉग के भीतर) तक पहुंचने के लिए प्रबंधन स्टूडियो के माध्यम से नेविगेट करता हूं, हालांकि आप sp_readerrorlog संग्रहीत प्रक्रिया का उपयोग कर सकते हैं या फ़ाइल को ब्राउज़ कर सकते हैं और इसे अपना पसंदीदा टेक्स्ट एडिटर खोल सकते हैं।

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

प्रतीक्षा आंकड़े

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

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

अगले चरण

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