आप कितनी बार एक भारी-उपयोग वाले Windows Server 2008R2 रिमोट डेस्कटॉप सर्वर (VM) को पुनः आरंभ करते हैं?


17

नोट: मैंने पढ़ा है कि विंडोज सर्वर को कितनी बार चालू करने की आवश्यकता है? लेकिन यह प्रश्न विशेष रूप से हमारे दूरस्थ डेस्कटॉप सर्वर से संबंधित है।

हमारे पास एक विंडोज़ सर्वर 2008 आर 2 सर्वर है - एक वीएमवेयर ईएसएक्स वीएम - रिमोट डेस्कटॉप सेवाओं के लिए लाइसेंस प्राप्त, 25 उपयोगकर्ता जो आरआरएएस (एसएसटीपी) भी करते हैं। काम के घंटे के दौरान, औसतन एक दिन में, अतिरिक्त 4-6 "डिस्कनेक्ट" उपयोगकर्ताओं के साथ 8 से 12 लॉग-इन, सक्रिय उपयोगकर्ता होते हैं। इसमें 12 गीगाहर्ट्ज का सीपीयू हार्ड रिजर्वेशन और 16 जीबी रैम है, जो पूरी तरह से आरक्षित है। जरूरत पड़ने पर सीपीयू आरक्षण 24 गीगाहर्ट्ज अधिकतम तक बढ़ सकता है।

हमारे कई उपयोगकर्ता काम करने के लिए सर्वर पर विशेष रूप से भरोसा करते हैं। वे इसके प्रदर्शन के बारे में कड़वे तरीके से शिकायत करते हैं लेकिन कई लोग अपने प्रदर्शन को सुधारने के लिए काम करने की आदतों या सॉफ़्टवेयर को बदलने के लिए तैयार नहीं हैं। विशेष रूप से:

  • उपयोगकर्ता डिस्कनेक्ट के बजाय लॉग ऑफ करने से इनकार करते हैं
  • उपयोगकर्ता Lync 2010 के बजाय Lync 2013 का उपयोग करने पर जोर देते हैं (Lync 2013 एक कुख्यात संसाधन हॉग है)

मैं लॉग ऑफ करने के लिए उनके इनकार के महत्व को कम नहीं कर सकता। डिस्कनेक्ट किए गए उपयोगकर्ता डिस्कनेक्ट करते समय रैम को जारी रखते हैं , जिसका अर्थ है कि किसी भी समय, हमारे पास चलने वाले कुछ कार्यक्रमों के 16 उदाहरण हैं।

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

इसलिए मैंने वीएम के नियमित रिबूट का प्रस्ताव दिया है - मैं इसे साप्ताहिक रूप से करना चाहूंगा, शनिवार शाम को कहूंगा - जैसा कि मुझे लगता है कि ये रिबूट समस्या का बहुत हल करेंगे।

मैं जानना चाहूंगा, यदि आप एक विंडोज एडमिन हैं,

  • क्या मैं इस तथ्य के बारे में सही हूं कि कचरा / लाश / लीक सत्र के समय के साथ जमा होते हैं, यहां तक ​​कि उपयोगकर्ता के डिस्कनेक्ट / पुनर्निर्माण के बाद भी?

  • कितनी बार आप दूरस्थ डेस्कटॉप सेवाओं के साथ समान रूप से उपयोग किए गए विंडोज सर्वर को पुनरारंभ करते हैं ?


10
निष्क्रिय सत्र के लिए लॉगऑफ़ को बाध्य करने की नीति का उपयोग क्यों नहीं किया जाता है?
मैसिमो

@ मास्सिमो क्योंकि वे इसे बहुत भारी-भरकम मानते हैं ... वे हर बार काम खो देते हैं, जब मैं बिना पर्याप्त नोटिस के रिबूट करता हूं, यानी उस दिन के "दोपहर" तक उन्हें जानने की जरूरत होती है, और तब भी कुछ के बाद ही ऐसा होता है बड़बड़ा और चर्चा, आदि
tacos_tacos_tacos

12
आपको अपने उपयोगकर्ताओं की अपेक्षाओं को समायोजित करने की आवश्यकता है। IMO यह उनके लिए अनुचित है कि वे किसी भी लम्बे समय तक बिना डेटा के सुरक्षित रूप से निष्क्रिय सत्र छोड़ सकते हैं। एक अप्रत्याशित दुर्घटना, उपकरण विफलता, बिजली आउटेज या कैओस के कुछ अन्य कार्य बस उनके बिना सहेजे गए कार्य को आसानी से नष्ट कर सकते हैं।
ज़ॉडेचेस

2
मुझे इस सवाल पर एतराज नहीं है, लेकिन सवाल जवाब के रूप में पूछे गए हैं विकल्प आधारित होने जा रहे हैं। अधिक तथ्य या (या कम से कम प्रदर्शन आधारित) उत्तरों के लिए पुनः प्रयास करने का प्रयास करें।
जिम बी

1
@tacos_tacos_tacos यह मेरा अनुभव है। क्या, वास्तव में, एक चलने वाले ओएस के बारे में सोचना है? यह एक अस्पष्ट धारणा है जो निराधार है। ओएस इतना नहीं करता है। उपयोगकर्ता प्रक्रियाएं सामान करती हैं। जब वे चले गए हैं तो स्लेट फिर से साफ है। ओएस आमतौर पर रास्ते से हट जाता है और उपयोगकर्ता प्रक्रियाओं से पूछता है। यह स्वयं के द्वारा संसाधन उपयोग की शुरुआत नहीं करता है।
usr

जवाबों:


23

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

ध्यान दें कि यह उत्तर केवल मेरी राय है। यहाँ तथ्य का कोई बयान नहीं है।


जहां मैंने काम किया हमने भी हर रात हमारी रिबूट की। कुछ बार सर्वर वापस नहीं आता है, लेकिन ऐसा बहुत कम ही होता है कि वह इसके लायक था।
फ्रेडरिक नीलसन

आपने इसे कितनी बार पुन: स्थापित किया?
कोनराड गजवेस्की

4
+1 Citrix, Microsoft और स्वयं सभी TS सर्वर के लिए नियमित रिबूट की सलाह देते हैं। ये अनिवार्य रूप से एंड यूज़र कंप्यूटिंग बॉक्स हैं और सामान्य रूप से ऐसे एप्लिकेशन चलेंगे जो सर्वर के लिए अनुकूलित नहीं हैं - इसका मतलब है कि मेमोरी लीक, संसाधनों को जारी नहीं करना आदि। एक न्यूनतम न्यूनतम पर साप्ताहिक, लेकिन दैनिक जहाँ भी आप कर सकते हैं - यह आपके जीवन को आसान बना देगा।
दान

@ आपके द्वारा बताई गई Microsoft अनुशंसा का कोई लिंक (नियमित रिबूट)?
tacos_tacos_tacos

17

उपयोगकर्ता डिस्कनेक्ट के बजाय लॉग ऑफ करने से इनकार करते हैं

उन्हें समुचित समूह नीतियों को ऑटो-लॉगऑफ़ पर सेट करें। आप एक निष्क्रिय टाइमआउट और लॉगऑफ़ को अलग से नियंत्रित कर सकते हैं। दिन के दौरान कुछ मुद्दों को कम करना चाहिए।

मैं अपने 3 सर्वर टीएस फार्म को रोजाना सुबह 3:00 बजे पुनः आरंभ करता हूं। क्योंकि, हां बकवास समय के साथ बन सकता है जब आपके पास एकल प्रणाली का उपयोग करने वाले बहुत सारे लोग होते हैं। हमारे पास वर्ष के समय, दिन के आधार पर 60-90 लोगों के बीच 3 सर्वर साझा हैं।

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


प्रिंटर ड्राइवरों के बारे में, आदि: मैंने या तो यहां पढ़ा था या कहीं और प्रतिष्ठित था कि एमएस ने इस विभाग में बहुत प्रगति की - और सामान्य रूप से विंडोज 2000 सर्वर और विंडोज सर्वर 20032 आर 2 एसपी 3 के बीच रिबूट की आवश्यकता को कम करने में। इसलिए मुझे यकीन नहीं है कि ड्राइवरों की समस्या प्रासंगिकता है। वास्तव में मैंने विंडोज के नए संस्करणों (सर्वर) पर ध्यान दिया है जो प्रिंट ड्राइवरों को संभालते हैं और आश्चर्यजनक रूप से अच्छी तरह से स्पूलिंग करते हैं।
tacos_tacos_tacos

मैं वास्तव में अक्सर अपने टीएस सर्वर को रिबूट नहीं करता हूं, लेकिन हर रात मैं प्रिंट स्पूलर को रोक देता हूं, किसी भी प्रिंट नौकरियों को हटा देता हूं, और इसे पुनरारंभ करता हूं। यह उन घटनाओं को भी ठीक करता है जब उपयोगकर्ता RDP का उपयोग करने में लॉग इन करने में असमर्थ होते हैं। (विंडोज सर्वर 2003)
रैंडी ऑरिसन

6

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

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

अतिरिक्त VM संसाधनों के बिना भी और अतिरिक्त OS ओवरहेड के साथ, आप सिस्टम को दो अलग-अलग 6 GHZ CPU और 8GiB मेमोरी VM के रूप में बेहतर तरीके से संभाल सकते हैं, यह मानते हुए कि आप लोड को समान रूप से विभाजित कर सकते हैं। तीन संभावित तरीके हैं:

  1. सबसे साफ तरीका यह है कि उचित नेटवर्क-आधारित लोड बैलेंसिंग समाधान का उपयोग किया जाए, जैसे कि एफ 5 नेटवर्क, सिस्को सिस्टम्स और इसी तरह की कंपनियों द्वारा प्रदान किया जाता है। यदि आप पहले से ही इस तरह का एक समाधान खरीद चुके हैं, तो यहां इसका उपयोग करना सार्थक होगा। फिर आप शेष उत्तर को अनदेखा कर सकते हैं क्योंकि f5 तब उचित रूप से आपके वर्तमान RD सर्वर तक पहुँचने के लिए उपयोग किए जाने वाले FQDN के लिए सभी प्रश्नों को पार्स करने में सक्षम होगा और आपके सर्वर के कम से कम उपयोग के आधार पर एक उपयुक्त IP लौटाएगा।
  2. राउंड-रॉबिन डीएनएस एक निष्क्रिय समाधान है। यह पूरी तरह से लोड की गारंटी नहीं देगा, लेकिन यदि आप अपने उपयोगकर्ताओं को शिक्षित करते हैं तो यह एक उपयोगी स्टॉपगैप हो सकता है (3 देखें) यदि आप नेटवर्क लोड बैलेंसर का उपयोग नहीं कर सकते हैं। वर्तमान DNS नाम क्लाइंट को दो होस्ट रिकॉर्ड के साथ उपयोग कर रहे हैं, जिनके नाम समान हैं लेकिन अलग-अलग आईपी (आपके दो सर्वर), आदर्श रूप से अलग होस्ट रिकॉर्ड (अधिमानतः सर्वर होस्टनाम पर आधारित) को कॉन्फ़िगर करते हैं जो प्रत्येक व्यक्तिगत सर्वर से जुड़ा हुआ है।

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

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

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


2
रचनात्मकता के लिए +1। मैं एक लोड बैलेंसर सेट कर सकता हूं और यह ईमानदारी से जाने का रास्ता है।
tacos_tacos_tacos

4

मैं "उपयोगकर्ता प्रकार" से परिचित हूं जो लॉगऑफ़ से इनकार करता है। हालांकि, उन्हें यह समझने में कोई समस्या नहीं थी कि सर्वर रात में रिबूट हो जाएगा ताकि कोई भी सहेजा गया कार्य खो जाए। यह एक मशीन पर लगभग 20 उपयोगकर्ताओं के सर्वर 2008 R2 टीएस पर है।


1

> उपयोगकर्ता डिस्कनेक्ट के बजाय लॉग ऑफ करने से इनकार करते हैं

आपके पास एक तकनीकी के बजाय यहां एक प्रबंधन / एचआर मुद्दा है। यदि लॉग ऑन रहने वाले लोग अन्य लोगों के काम को प्रभावित कर रहे हैं (अनावश्यक रूप से प्रदर्शन को कम करके) तो वास्तव में केवल दो समाधान हैं:

  1. इसे एक तकनीकी मुद्दा बनाएं और यदि संभव हो तो संसाधनों में वृद्धि (अधिक रैम, एसएसडी में कताई धातु, ...) के लिए व्यवस्था करें। बेशक एक मशीन पर नए संसाधनों को फेंकने से आप क्या हासिल कर सकते हैं, इसकी सीमाएं हैं लेकिन यह काम कर सकता है।

  2. इसे लोगों की प्रबंधन समस्या के रूप में स्वीकार करें और उचित अनुशासन को प्रोत्साहित करने (या उस लागू करने में विफल ) के कुछ तरीके खोजें । बेशक यह आपकी प्रत्यक्ष जिम्मेदारी से बाहर हो सकता है इसलिए यह आपके कार्यालय की राजनीति के आधार पर काफी मुश्किल हो सकता है ...

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

> उपयोगकर्ता Lync 2010 के बजाय Lync 2013 का उपयोग करने पर जोर देते हैं (Lync 2013 एक कुख्यात संसाधन हॉग है)

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

यदि एक चैट एप्लिकेशन मुख्य संसाधन समस्या है, तो मुझे आश्चर्य होता है कि क्या पूरे सत्र को मारने के बजाय निष्क्रिय सत्रों में उस कार्यक्रम के सिर्फ उदाहरणों को मारने का कोई तरीका है?

> वे हर बार काम खो देते हैं जब मैं पर्याप्त नोटिस के बिना रिबूट करता हूं, यानी उस दिन के "दोपहर" तक उन्हें जानने की जरूरत होती है

आप काम की प्रकृति के बारे में नहीं बताते हैं, इसलिए यह इस बात पर बहुत निर्भर है कि क्या है, लेकिन वे उचित परिश्रम पर असफल हो सकते हैं (अर्थात अपना काम ठीक से नहीं करना )।

यदि वे नियमित रूप से दस्तावेजों को नहीं बचा रहे हैं, तो वे अपना काम जोखिम में डाल रहे हैं, आप नहीं। अगर सर्वर डाउन हो जाता है तो पावर आउट या अन्य गलती होती है तो क्या होगा? क्या वे आपको भी दोष देंगे?

बेशक, यदि वे रिबूट के समय सक्रिय रूप से काम कर रहे हैं या लंबे समय से चल रही प्रक्रियाओं को बिना रुके छोड़ने की आवश्यकता है तो एक वास्तविक समयबद्धता मुद्दा हो सकता है जिसे आपको अपने बीच काम करने की आवश्यकता है।


0

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

मैं इसे GPO के एक जोड़े के साथ उपयोग कर रहा हूं जो कुछ घंटों के बाद डिस्कनेक्ट किए गए उपयोगकर्ताओं को लॉग करता है। और निश्चित समय के बाद एक निश्चित समय के बाद सक्रिय सत्र काट देता है। यह एक सुंदर सुशोभित विधि है, एक ओर समुद्र-तट रगड़ कार्यक्रम से जो सत्र को बंद करने से दूर रखता है। हम उन लोगों के आसपास काम किया है, हालांकि। जिस तरह से हमने इसे सेटअप किया है अब हर सर्वर 22.00 से 7.00 तक हर घंटे रिबूट करने की कोशिश करता है, जब तक कि यह निश्चित रूप से सफल न हो जाए। प्रभावी रूप से, उपयोगकर्ता सप्ताह में कम से कम 2/3 बार रीबूट करते हैं, जो मेरे द्वारा ठीक है।

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


0

Microsoft सर्वर पर सीधे उत्तर YES / NO को रीबूट करता है। ओह अगर जीवन इतना आसान था! यह सर्वर पर चल रहे एप्लिकेशन पर निर्भर करता है। लेकिन यहाँ एक सरल मार्गदर्शक है लेकिन एक कठिन और तेज़ नियम नहीं है।

फिजिकल सर्वर रनिंग विंडोज सर्वर ** x वर्जन ** ( ऑटो रिबूट और शेड्यूल ) 95% बिना किसी वास्तविक चिंताओं के हर पखवाड़े एक बार रिबूट किया जा सकता है। (लागू किया जा रहा पैच की जाँच करें प्रासंगिक और आवश्यक है)। सुनिश्चित करें कि आप लाइव / प्रोडक्शन सिस्टम को जारी करने से पहले अपने टेस्ट सर्वर पर पूरी तरह से पैच टेस्ट कर लें।

VMWare वर्चुअल सर्वर Windows Server x संस्करण चला रहा है - एक पखवाड़े में एक बार रिबूट ( पैच लागू होने पर उपरोक्त टिप्पणी देखें )

शारीरिक VMWare सर्वर कभी नहीं / दुर्लभ और केवल अगर आवश्यक कभी नहीं अनुसूचित। (आम तौर पर बहुत स्थिर अगर तारीख तक रखा जाता है) VMWare पैच / अपडेट को रिबूट की आवश्यकता होगी।

VMWare चल रहा है Windows SQL (सीमा को रिबूट करें, विंडोज पैच को केवल लागू करें पुनरारंभ करें यदि IF को पैच की आवश्यकता होती है और उसके बाद ही जब आप सभी क्लाइंट कनेक्शन बंद कर देते हैं) एक बार सर्वर के वापस आने के बाद कनेक्शन को फिर से कनेक्ट करें। SQL सर्वर को रिबूट करने में काफी समय लग सकता है, इसलिए इसे घंटे के बाहर की योजना बनाएं।

अनुस्मारक: किसी भी VMWare (Windows सर्वर) में परिवर्तित करने से पहले इसे स्नैप करें! यदि सर्विस पैच के बाद सिस्टम क्रैश हो जाता है या अपडेट किए गए एप्लिकेशन या एप्लिकेशन शुरू होने में विफल हो जाते हैं तो आप जल्दी से सर्वर बैकअप प्राप्त कर सकते हैं और सीमित समय के साथ चल सकते हैं। त्रुटियों को नोट करना याद रखें ताकि आप पा सकते हैं कि फिक्स सिस्टम को अकेला नहीं छोड़ता क्योंकि यह भविष्य में विफल हो सकता है।

आशा है कि मदद करता है और चीजों को साफ करने के लिए एक छोटा सा रास्ता जाता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.