sqlserver और मेमोरी उपयोग के अधिक उदाहरण

एक बेहतर समाधान परीक्षण उदाहरण को एक अलग सर्वर पर ले जाना है: इस तरह “इंटरैक्शन” की संभावना कम होती है जहां परीक्षण किया जा रहा सॉफ़्टवेयर उत्पादन डीबी को प्रभावित करता है। याद रखें, यदि उत्पादन सर्वर इतनी अधिक मेमोरी का उपयोग कर रहा है, तो यह एक कारण से है – इसलिए आप उस सर्वर पर जो भी अन्य लोड जोड़ते हैं, उसका संभवतः उत्पादन प्रतिक्रिया समय पर प्रभाव पड़ेगा।
भौतिक पृथक्करण आपके द्वारा की गई किसी भी गलती को उत्पादन को प्रभावित करने से रोकता है (और इसमें एक “अतिरिक्त मशीन” का लाभ होता है जिसे आप उत्पादन सर्वर के साथ कोई हार्डवेयर समस्या होने पर वापस ले सकते हैं)।

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

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