समान सर्वर के लिए विभिन्न योजनाएं

मेरी पिछली पोस्ट में, "एक 'समान' प्रश्न के लिए कई योजनाएं," मैंने उस मामले के बारे में बात की जहां आपको दो अलग-अलग योजनाएं मिल रही हैं जो आपको लगता है कि एक ही प्रश्न है, साथ ही उस मामले के बारे में जहां आपको दो प्रतियां मिल रही हैं समान योजना (और शायद यह भी नहीं पता)। जैसा कि हमने वहां जांच की, "समान" एक बहुत मजबूत शब्द हो सकता है।

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

क्या सर्वर वास्तव में "समान" हैं?

ये लोग समान दिख सकते हैं, लेकिन वे बिल्कुल समान नहीं हैं।

यदि आप इस परिदृश्य में आते हैं, तो सबसे पहले आपको खुद से पूछने की जरूरत है कि क्या ये दोनों सर्वर वास्तव में समान हैं। जाँच करने के लिए कुछ चीज़ें:

संस्करण - सर्विस पैक और संचयी अपडेट के माध्यम से कई अनुकूलक और क्वेरी व्यवहार परिवर्तन को आगे बढ़ाया जाता है। अक्सर मैंने लोगों को यह कहते हुए देखा है, "ठीक है, वे दोनों 2008 के हैं!" - जब, वास्तव में, एक 2008 था और दूसरा 2008 R2 था, या वे अलग-अलग सर्विस पैक या यहां तक कि संचयी अद्यतन स्तरों पर थे। चूंकि @@ संस्करण पढ़ने वाले बहुत से लोग SQL सर्वर सर्विस पैक जानकारी के लिए ऑपरेटिंग सिस्टम सर्विस पैक जानकारी की गलती करते हैं, मैं कहूंगा कि निम्नलिखित बेहतर है:
SELECT SERVERPROPERTY (N'ProductVersion' );

मैं सही, सेब-से-सेब परीक्षण करने के लिए ठीक उसी संस्करण का उपयोग करने के महत्व पर पर्याप्त जोर नहीं दे सकता। यदि आप SQL Server 2012 या बेहतर का उपयोग कर रहे हैं, तो आप हमारे बिल्ड पोस्ट (SQL Server 2012 | SQL Server 2014) की जांच कर सकते हैं ताकि यह सुनिश्चित किया जा सके कि संस्करण मेल खाते हैं।
संस्करण - जबकि उम्मीद है कि आप दोनों सर्वरों पर एक ही संस्करण का उपयोग कर रहे हैं (या समकक्ष, चूंकि लाइसेंसिंग के अलावा, डेवलपर और मूल्यांकन एंटरप्राइज़ के समान हैं), यहां बेमेल व्यवहार बहुत भिन्न व्यवहार का कारण बन सकता है। उदाहरण के लिए, विभिन्न संस्करणों में विभिन्न विशेषताओं के लिए अलग-अलग गणना क्षमता होती है, और फिर कुछ सूक्ष्म चीजें होती हैं जैसे NOEXPAND संकेत के बिना अनुक्रमित दृश्य का उपयोग करने की क्षमता या स्कीमा परिवर्तन या अनुक्रमणिका रखरखाव ऑनलाइन करने की क्षमता। आप इसका उपयोग करके संस्करणों की तुलना कर सकते हैं:

SELECT SERVERPROPERTY (N'Edition' );
सीपीयू गणना - SQL सर्वर निश्चित रूप से निष्पादन योजना बनाने की प्रक्रिया के दौरान उपलब्ध अनुसूचकों की संख्या का उपयोग करता है, और इस बात से इनकार नहीं किया जा सकता है कि कोर की संख्या वास्तविक रनटाइम प्रदर्शन को प्रभावित कर सकती है (चलो घड़ी की गति को छोड़ दें, क्योंकि यह शायद ही कभी क्वेरी में एक महत्वपूर्ण कारक है। प्रदर्शन)। न केवल अंतर्निहित सर्वर में भौतिक रूप से स्थापित कोर की संख्या को सत्यापित करें, बल्कि सीपीयू की संख्या के लिए SQL सर्वर के त्रुटि लॉग की भी जांच करें SQL सर्वर वास्तव में लाइसेंसिंग के कारण उपयोग कर सकता है। यहां तक कि NUMA सिस्टम पर कच्चे कोर गिनती को भूलकर, यहां कृत्रिम प्रतिबंध बहुत अलग प्रदर्शन प्रोफाइल का कारण बन सकते हैं। अधिक जानकारी के लिए, ब्रेंट ओज़र की हालिया पोस्ट देखें, "प्रदर्शन ट्यूनिंग के लिए कोर-आधारित लाइसेंसिंग मामले क्यों।" संस्करण यहां भी जुड़ा हुआ है, क्योंकि SQL सर्वर 2012 और 2014 में, मानक संस्करण केवल 16 कोर का उपयोग कर सकता है, चाहे आपकी सेटिंग्स या भौतिक हार्डवेयर आपको विश्वास करने के लिए प्रेरित करें। अन्य सेटिंग्स जो सीपीयू-आधारित योजना पसंद और प्रदर्शन को अलग तरह से प्रभावित कर सकती हैं, उनमें रिसोर्स गवर्नर, सर्वर-वाइड MAXDOP, सीपीयू एफ़िनिटी, और समानांतरवाद के लिए लागत सीमा शामिल हैं।
स्मृति की मात्रा - सीपीयू की तरह, ऑप्टिमाइज़र उपलब्ध मेमोरी की मात्रा के आधार पर योजना विकल्प बनाता है। और सीपीयू की तरह, मैं केवल सिस्टम में स्थापित रैम की मात्रा के बारे में बात नहीं कर रहा हूं, बल्कि SQL सर्वर को दी गई मेमोरी की मात्रा और यह वास्तव में कितना उपयोग कर रहा है। अधिकतम सर्वर मेमोरी सेटिंग्स की जाँच करें, लेकिन कुल और लक्ष्य मेमोरी के लिए प्रदर्शन काउंटर और यहाँ तक कि DBCC MEMORYSTATUS भी। जिन अन्य चीजों की आप समीक्षा करना चाहते हैं उनमें रिसोर्स गवर्नर सेटिंग्स और मेमोरी में लॉक पेज शामिल हैं। एक सेटिंग यह भी है कि, यदि दो सर्वरों के बीच भिन्न होता है, तो इस पर महत्वपूर्ण प्रभाव पड़ सकता है कि समान प्रश्नों के सेट के लिए कितना प्लान कैश उपयोग में है:तदर्थ कार्यभार के लिए अनुकूलित करें। किम्बर्ली ट्रिप के पास इस पर एक बेहतरीन पोस्ट है:कैश की योजना बनाएं और एडहॉक वर्कलोड के लिए अनुकूलन करें। अंत में, यदि सर्वर वर्चुअल है, तो जागरूक रहें कि पर्यावरण यहां एक भूमिका निभा सकता है - खासकर जब वीएम मेमोरी सेटिंग्स उत्पादन से मेल नहीं खाती हैं या गतिशील हैं।
बफर पूल / प्लान कैशे - जब आप परीक्षण सर्वर पर डेटाबेस को पुनर्स्थापित करते हैं, तो ऐसी कई चीजें होती हैं जो आपके लिए तुरंत तैयार नहीं होती हैं। बफर पूल में कोई भी डेटा नहीं होता है जो स्रोत सर्वर में मौजूद हो सकता है - इसलिए डेटा को पहली बार पूछे जाने पर मेमोरी में प्राइम करने के लिए अतिरिक्त I/O की आवश्यकता होगी। और यदि उपरोक्त कुछ कारकों के कारण बफर पूल उत्पादन की तुलना में अलग-अलग प्रतिबंधित है, तो क्वेरी को कई बार चलाने के बाद भी समान प्रदर्शन पैटर्न प्राप्त करना संभव नहीं हो सकता है - पॉल व्हाइट (@SQL_Kiwi) अपने उत्तर में इस बारे में बात करता है डेटाबेस प्रशासक। साथ ही, प्लान कैश में उत्पादन में मौजूद कोई भी योजना शामिल नहीं होगी, इसलिए कम से कम - भले ही वही योजना अंततः संकलित हो जाए (जो मूल पर योजना संकलित किए जाने की तुलना में विभिन्न मानकों के कारण नहीं हो सकती है) सर्वर) - आपके पास अतिरिक्त संकलन लागतें होंगी। और यदि आपके पास कोई योजना-प्रभावित ट्रेस फ़्लैग है, तो वे भी बदल सकते हैं।
डिस्क सबसिस्टम - जबकि उपयोग की जा रही डिस्क की गति और आकार सीधे योजना की पसंद को प्रभावित नहीं करेगा, वे निश्चित रूप से देखे गए प्रदर्शन को प्रभावित कर सकते हैं, जो आपको आश्चर्यचकित कर सकता है कि एक ही क्वेरी, एक ही योजना के साथ, एक पर इतनी तेजी से क्यों चलती है दूसरे की तुलना में प्रणाली। I/O आमतौर पर SQL सर्वर की सबसे बड़ी अड़चन है, और यह काफी दुर्लभ है कि एक परीक्षण सर्वर में वास्तव में ठीक उसी अंतर्निहित सबसिस्टम का उत्पादन समकक्ष होता है। इसलिए, यदि आप दो प्रणालियों के बीच प्रदर्शन अंतर देख रहे हैं, और योजनाएं और अन्य हार्डवेयर तत्व समान हैं, तो यह जांचने के लिए अगली सबसे अच्छी जगह हो सकती है। और यह न भूलें कि, SQL सर्वर 2014 के अनुसार, संसाधन गवर्नर आपके I/O प्रदर्शन पर बाधा डाल सकता है।

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

ध्वज	स्पष्टीकरण
2301	एक इष्टतम योजना खोजने के प्रयास में अनुकूलक को अधिक समय बिताने के लिए बाध्य करता है।
2312	एसक्यूएल सर्वर 2014 के नए कार्डिनैलिटी अनुमानक को बाध्य करता है।
2335	अधिक रूढ़िवादी स्मृति अनुदान का कारण बनता है।
2453	बल विकल्प (RECOMPILE) तालिका चर को संदर्भित करने वाले प्रश्नों के लिए।
2861	SQL सर्वर को तुच्छ / शून्य-लागत वाली योजनाओं को कैश करने की अनुमति देता है।
4136	प्रभावी रूप से, सभी प्रश्नों में अज्ञात के लिए ऑप्टिमाइज़ करें (पैरामीटर सूँघने को विफल करने के लिए) जोड़ता है।
4199	एक छतरी जिसमें ऑप्टिमाइज़र की पूरी श्रृंखला होती है।
8744	नेस्टेड लूप के लिए प्री-फ़ेचिंग अक्षम करता है।
9481	SQL Server 2014 के नए कार्डिनैलिटी अनुमानक को बंद कर देता है।

ट्रेस फ़्लैग की सूची किसी भी तरह से संपूर्ण नहीं है; कई अन्य हैं, जिनमें गैर-दस्तावेज भी शामिल हैं जिनका मुझे उल्लेख नहीं करने के लिए कहा गया है। यदि आप ऊपर सूचीबद्ध नहीं किए गए अन्य लोगों का उपयोग कर रहे हैं (और इसकी व्याख्या नहीं कर सकते हैं), तो आपको KB #920093, KB #2964518, ट्रेस फ़्लैग्स (MSDN) या SQL सर्वर (TechNet) में ट्रेस फ़्लैग्स में सुराग मिल सकते हैं। आपको पॉल व्हाइट की विभिन्न पोस्टों में कुछ मूल्यवान अंतर्दृष्टि भी मिलेगी, या तो यहाँ, या sql.kiwi पर।

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

क्या डेटाबेस अभी भी "समान" हैं?

यह मानते हुए कि सभी हार्डवेयर और वर्कलोड चर पर्याप्त रूप से मेल खाते हैं, यह सुनिश्चित करना अभी भी चुनौतीपूर्ण हो सकता है कि डेटाबेस समान रहें। यदि आप परीक्षण प्रणाली पर बैकअप/पुनर्स्थापना कर रहे हैं, तो नया डेटाबेस स्रोत के समान शुरू होता है (भौतिक स्थान और सुरक्षा को छोड़कर)। लेकिन जैसे ही आप इसे किसी भी तरह से छूना शुरू करते हैं, यह बहुत जल्दी प्रोडक्शन कॉपी से हट जाता है, क्योंकि आप निम्न में से कोई एक या सभी कर सकते हैं:

डेटा, स्कीमा या दोनों बदलें।
असावधानी से आंकड़ों का स्वत:अद्यतन प्रारंभ हो जाता है।
इंडेक्स को मैन्युअल रूप से जोड़ें, डीफ़्रैग्मेन्ट करें या पुनर्निर्माण करें, या आंकड़े बनाएं या अपडेट करें।
डेटाबेस सेटिंग्स बदलें जैसे संगतता स्तर, अलगाव स्तर, मजबूर पैरामीटरकरण, चुनिंदा एक्सएमएल इंडेक्स, या "ऑटो" नामक किसी भी विकल्प - <कुछ भी>। (बिल्कुल, यहां तक कि डेटा और लॉग फ़ाइल स्थान और विकास सेटिंग्स क्वेरी प्रदर्शन को प्रभावित कर सकती हैं, और इसमें tempdb भी शामिल है।)
प्लान कैश, बफर पूल, या दोनों को सीधे या अन्य घटनाओं के साइड इफेक्ट के रूप में खाली करें (जैसे RECONFIGURE या सर्विस रीस्टार्ट)।

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

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

क्या वास्तव में क्वेरी "समान" हैं?

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

निष्कर्ष

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

क्या आपके पास कोई विशेष तरकीब है? क्या आपके पास उपरोक्त विचारों (या अन्य जिन्हें मैंने उल्लेख करने की उपेक्षा की) के साथ कोई कष्टदायी दर्द बिंदु है? कृपया नीचे टिप्पणी में साझा करें!