सुरक्षित रूप से उत्पादन डेटाबेस डेटा फिक्सिंग


23

कीड़े होते हैं और कभी-कभी डेटा को उत्पादन में तय करना पड़ता है। एक बड़ी कंपनी के दृष्टिकोण से इस बारे में जाने का सबसे सुरक्षित तरीका क्या है? क्या ऐसे उपकरण हैं जो मदद कर सकते हैं? यहाँ कुछ विचार इस आवश्यकता को चला रहे हैं ...

  1. हमें लॉग इन करने की जरूरत है कि क्वेरी कौन चलाता है और वे क्या चलाते हैं
  2. आदर्श रूप से हमें व्यक्ति को केवल रुचियों की मेजों के विरुद्ध प्रश्नों को चलाने और थोड़े समय के लिए पहुँच प्रदान करने की आवश्यकता है
  3. जो कुछ भी चल रहा है क्वेरी को स्पष्ट अनुमति के बिना लंबे समय तक चलने और लॉकिंग एसक्यूएल की अनुमति नहीं देने के लिए इसके बारे में कुछ स्मार्ट होने की आवश्यकता है
  4. इस प्रक्रिया के लिए डीबी अज्ञेयवादी होना चाहिए या कम से कम डीबी 2, ओरेकल और एसक्यूएल सर्वर को समझना चाहिए।

हम "गलत काम" करने से तदर्थ ठिकाने ठीक करने वाले प्रश्नों के जोखिम को कम करने की कोशिश कर रहे हैं और साथ ही प्रक्रिया में कुछ सुरक्षा / ऑडिट भी जोड़ रहे हैं। विचार या विचार?


26
प्रबंधन को कभी यह मत सोचने दो कि यह मानक संचालन प्रक्रिया है। यह मास्क या दस्ताने के बिना आपातकालीन ओपन हार्ट सर्जरी है, न कि बग से निपटने का एक सामान्य तरीका जो परीक्षण में पकड़ा जाना चाहिए था।
दान Pichelman

2
यह इसलिए है क्योंकि आप इस तरह से काम करना चाहते हैं कि कीड़े पहले स्थान पर हुए।
रिएक्टगुलर

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

1
@AndrewWhite मेरी माफी एंड्रयू कोई अपराध का इरादा था।
रिएक्टगुलर

जवाबों:


52

कभी भी उत्पादन डेटाबेस को मैन्युअल रूप से अपडेट न करें।

स्क्रिप्ट लिखो।

ट्रिपल उन्हें चेक करते हैं, और कई लोग ऐसा करते हैं, न कि केवल एक व्यक्ति इसे तीन बार कर रहा है।

उन लिपियों में परिवर्तन के बाद के प्रश्नों को शामिल करें।

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

उन स्क्रिप्टों का परीक्षण करें जो एक परीक्षण डेटाबेस के विरुद्ध है।

उत्पादन डेटाबेस के खिलाफ स्क्रिप्ट चलाने से पहले एक बैकअप बनाएं।

स्क्रिप्ट चलाते हैं।

पोस्ट-चेंज-वेलिडेशन स्क्रिप्ट्स का उपयोग करके परिवर्तित डेटा की जांच, सत्यापन और ट्रिपल चेक करें।

फिर भी एक दृश्य की जाँच करें।

यदि कुछ भी बंद लगता है, तो बैकअप बंद करें और पुनर्स्थापित करें।

परिवर्तित डेटा के साथ उत्पादन डेटा के रूप में तब तक आगे न बढ़ें जब तक कि आप पूरी तरह से सुनिश्चित न हों कि सब कुछ ठीक है और आप इसमें शामिल हैं (व्यवसाय) प्रबंधकों से साइन इन करें।


21
@ और कहा कि कोई बहाना नहीं है: एक को भूल जाओ WHEREऔर आपका डेटाबेस शेष दिन के लिए नीचे रहेगा। या सप्ताह।
कोडकेस्टर

9
@AndrewWhite आपने डेटा को ठीक करने का सबसे सुरक्षित तरीका पूछा, सबसे तेज़ नहीं । :-)
एरिक किंग

9
@AndrewWhite - आपको पहले से ही एक समस्या है। यदि आप ठीक करते हैं, तो आपको दो समस्याएँ होने वाली हैं, यदि अधिक नहीं, और / या आप समस्याओं को बेहतर बनाने के बजाय काम कर सकते हैं।
माइकल कोहेन

6
@AndrewWhite - स्पष्ट रूप से, यह एक गैर तुच्छ प्रक्रिया होने के नाते मेरे लिए एक प्लस होगा। हर कोई लागत और जोखिम से अवगत होगा, "ठीक है, हमने समस्याओं के बिना 23 बार पहले किया है" ब्लेज़-नेस मैंने कई स्थानों पर देखा है।
डेवई


20

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

निम्नलिखित मामले की कल्पना करें:

  1. सॉफ़्टवेयर उत्पाद में एक बग है, जिसके कारण यह काम करना बंद कर देता है जब यह पता लगाता है कि डेटाबेस में कुछ डेटा असंगति होने का क्या विचार है,

  2. सभी डेवलपर्स जो संभावित रूप से बग को ठीक कर सकते हैं, वे उपलब्ध नहीं हैं,

  3. कंपनी वर्तमान में प्रति घंटे हजारों डॉलर खो रही है (मान लें कि $ 6 000, जिसका अर्थ है $ 100 प्रति मिनट),

  4. बग कई तालिकाओं को प्रभावित कर रहा है, जिनमें से एक बहुत बड़ा है, और केवल डेटा को ही चिंतित करता है, स्कीमा को नहीं,

  5. बग को दरकिनार करने के लिए, आपको डेटा के साथ थोड़ा प्रयोग करना चाहिए, जिसमें इसे हटाने और बदलने दोनों शामिल हैं,

  6. डेटाबेस बड़ा है और बैकअप लेने या पुनर्स्थापित करने में तीन घंटे लगेंगे,

  7. अंतिम पूर्ण बैकअप तीन सप्ताह पहले लिया गया था; दैनिक वृद्धिशील बैकअप भी हैं, और अंतिम दैनिक वृद्धिशील बैकअप 14 घंटे पहले किया गया था,

  8. डेटाबेस बैकअप विश्वसनीय माना जाता है; इनका गंभीर परीक्षण किया गया, जिसमें हाल ही में,

  9. 14 घंटे का डेटा खोना स्वीकार्य नहीं है, लेकिन एक से दो घंटे के डेटा का नुकसान होता है,

  10. मंचन का वातावरण अंतिम रूप से छह महीने पहले इस्तेमाल किया गया था; ऐसा लगता है कि यह आज तक नहीं है, और इसे स्थापित करने में घंटों लग सकते हैं,

  11. डेटाबेस Microsoft SQL Server 2008 एंटरप्राइज़ है।

चीजों को करने का साफ तरीका है:

  1. मचान वातावरण में बैकअप पुनर्स्थापित करें,

  2. वहां प्रयोग करें,

  3. दो बार अंतिम स्क्रिप्ट की जाँच करें,

  4. उत्पादन सर्वर पर स्क्रिप्ट चलाएँ।

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

इसके बजाय, आप ऐसा कर सकते थे:

  1. एक स्नैपशॉट बनाएं (Microsoft SQL सर्वर उस का समर्थन करता है, और यह एक डेटाबेस का एक स्नैपशॉट जो कि बैकअप के लिए एक घंटे लेता है, वापस लौटने में (और कुछ भी नहीं बनाने के लिए) लेता है; मुझे लगता है कि अन्य डेटाबेस उत्पाद स्नैपशॉट का भी समर्थन करते हैं);

  2. उत्पादन डेटाबेस पर सीधे प्रयोग करें, अगर कुछ गलत हो जाता है, तो स्नैपशॉट पर वापस लौटना।

जबकि एक शुद्धतावादी डेटाबेस को साफ तरीके से तय करेगा और फिर भी उसकी कंपनी के $ 20 000 से अधिक को बर्बाद करते हुए समय का दबाव बढ़ाने के लिए चीजों को खराब करने का जोखिम होगा, एक डेटाबेस प्रशासक जो व्यवसाय की बाधाओं को लेता है, एक तरह से डेटाबेस को ठीक करेगा। जो जल्दी से करते हुए जोखिम (स्नैपशॉट के लिए धन्यवाद) को कम कर देगा।

निष्कर्ष

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

अगर कुछ आईटी आदमी सिर्फ साफ-सफाई के लिए चीजों को साफ- सुथरा करना चाहते हैं, जबकि इससे कंपनी को हजारों डॉलर का नुकसान होता है, तो इस आईटी आदमी को अपनी नौकरी की गहरी गलतफहमी होती है।


2
और यदि संभव हो तो अपने काम के घंटे बंद कर दें - जब वास्तविक ग्राहक गतिविधि कम से कम हो
Dan Pichelman

3
यहां तक ​​कि अगर आपका डेटाबेस बड़ा है और इसे बैकअप करने में बहुत समय लगता है, तो आप शायद उस डेटा का एक सबसेट ले सकते हैं और उस पर प्रयोग कर सकते हैं।
रादु मुराज़े

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

3
@ कोडकोड: यह दुख की बात है, लेकिन मैं अक्सर बड़ी कंपनियों सहित व्यवहार में इसे देखता हूं।
आर्सेनी मौरज़ेंको

3
सबसे अधिक संभावना है, व्यवसाय इस भविष्यवाणी में सटीक रूप से शामिल हो गया क्योंकि उन्होंने मार्जन के पद में सलाह का पालन नहीं किया जब उनके पास मौका था।
एरिक किंग

4

सुरक्षित रूप से उत्पादन डेटाबेस डेटा फिक्सिंग। एक बड़ी कंपनी के दृष्टिकोण से इस बारे में जाने का सबसे सुरक्षित तरीका क्या है? क्या ऐसे उपकरण हैं जो मदद कर सकते हैं?

यह एक खराब अभ्यास और अधिक डेटा समस्याओं और मुद्दों के लिए एक निमंत्रण द्वार है। यहां तक ​​कि एक वाक्यांश भी है जो इस दृष्टिकोण को " त्वरित और गंदा " के रूप में वर्णित करता है ।

उत्पादन सर्वर पर सीधे फिक्सेस / अपडेट जारी रखना बहुत खतरनाक है , क्योंकि इससे आपको / आपकी कंपनी को एक भाग्य ( लॉ सूट, खराब / गंदा डेटा, खोए हुए व्यवसाय इत्यादि ) मिलेंगे

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

इस संबंधित पोस्ट में कई अच्छी प्रथाओं का उल्लेख किया गया है - डेटाबेस के अच्छे अभ्यासों का मंचन

देखने के लिए संदर्भों का अच्छा समूह हैं:


2

अधिकांश संगठन में मैंने लाइव वातावरण में डेटा को अपडेट करने का काम किया है, हमेशा ऐसा करने के लिए एक्सेस राइट्स वाले लोगों के एक छोटे समूह द्वारा किया गया था, आमतौर पर डीबीए जैसे नौकरी शीर्षक के साथ। जैसा कि अपडेट केवल कम संख्या में लोगों द्वारा किया जा सकता है, कम से कम एक मौका है कि वे डेटा के साथ परिचित हो और इसलिए समस्याओं के जोखिम को कम करता है (लेकिन समाप्त नहीं करता है)।

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

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

प्रत्येक व्यवसाय अद्वितीय है, और कुछ डेटा को अपडेट करने का जोखिम दूसरों की तुलना में स्पष्ट रूप से अधिक है।

एक प्रक्रिया होने से जो लोगों को इन अपडेट को करने के लिए हुप्स से कूदना पड़ता है, उम्मीद है कि आप एक ऐसी संस्कृति को बढ़ावा देते हैं जो लोगों को एक अंतिम उपाय के रूप में इसका इलाज करना चाहता है, और इस सामान के चारों ओर एक स्वस्थ "डबल चेक, ट्रिपल चेक" रवैया बनाता है।


ओह और बेशक जहां भी संभव हो तर्क में छिपे किसी भी निर्भर अपडेट को सुनिश्चित करने के लिए एप्लिकेशन में कोड का विश्लेषण करें ... के लिए पूरा किया जाता है ... और अगर कोई मौका हो तो उन तालिकाओं पर ट्रिगर करें जिन्हें आप उनके लिए चेक अपडेट कर रहे हैं और जिनके बारे में एक सोच है उन्हें अक्षम करने की आवश्यकता है या नहीं।
वेन एम

2

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

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

उत्पादन पर डेटा बदलने के लिए अगली सभी लिपियों में निम्नलिखित शामिल होना चाहिए:

उन्हें स्पष्ट लेनदेन में होना चाहिए और एक टीआरवाई कैच ब्लॉक होना चाहिए।

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

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

उत्पादन पर कुछ भी बदलने के लिए सभी स्क्रिप्ट्स कोड की समीक्षा की जाती हैं और स्रोत नियंत्रण में डाल दी जाती हैं। उन सभी को - बिना किसी अपवाद के।

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


0

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

यह भी महंगा होगा (हम प्रत्येक माता के कंधों को देखेंगे और 2 या 3 पर चर्चा करेंगे)

और सुनहरा नियम: हमेशा अपडेट / डिलीट / इन्सर्ट स्टेटमेंट करने से पहले यह दर्शाने के लिए कि उसे क्या करना है, एक सलेक्ट स्टेटमेंट बनाते हैं

टीम में अन्य दो लोगों द्वारा लागू किया जा रहा सुनहरा नियम!


0

पुन: मेनमा का जवाब ...

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

  • आप कैसे जानते हैं कि यह एक "बग" है? सॉफ्टवेयर उत्पाद डेवलपर द्वारा बताए गए नियमों के अनुसार डेटा असंगत है।

सभी डेवलपर्स जो संभावित रूप से बग को ठीक कर सकते हैं, वे उपलब्ध नहीं हैं,

कंपनी वर्तमान में प्रति घंटे हजारों डॉलर खो रही है (मान लें कि $ 6 000, जिसका अर्थ है $ 100 प्रति मिनट),

  • जाहिरा तौर पर $ 100 / मिनट का नुकसान कंपनी प्रबंधन के लिए उनके लिए पर्याप्त नहीं है कि वे यह पता लगा सकें और सक्षम हों कि सक्षम डेवलपर्स अपनी गलती को ठीक करने के लिए लौटते हैं और डेटाबेस को पुनर्स्थापित करने में आपकी सहायता करते हैं।

बग कई तालिकाओं को प्रभावित कर रहा है, जिनमें से एक बहुत बड़ा है, और केवल डेटा को ही चिंतित करता है, स्कीमा को नहीं,

  • सभी डेटाबेस समस्याओं स्कीमा "चिंता"। स्कीमा कैसे बनाया गया है, यह निर्धारित करने के लिए कि आप इस समस्या को कैसे हल करते हैं।

बग को दरकिनार करने के लिए, आपको डेटा के साथ थोड़ा प्रयोग करना चाहिए, जिसमें इसे हटाने और बदलने दोनों शामिल हैं,

  • यह आपके स्टेजिंग डेटाबेस के लिए है। उत्पादन के पूर्ण ऑनलाइन बैकअप लेने के ठीक बाद आपको उत्पादन डेटाबेस से "दूषित" डेटा के साथ इसे फिर से खोलना पड़ सकता है।

डेटाबेस बड़ा है और बैकअप लेने या पुनर्स्थापित करने में तीन घंटे लगेंगे,

  • फिर आप बेहतर तरीके से उस शुरुआत को शुरू कर सकते हैं ताकि आप समस्या का विश्लेषण कर सकें, अपनी सुधार लिपियों को विकसित कर सकें, डेवलपर्स और अन्य डीबीए आपकी मदद करने के साथ उनका परीक्षण कर सकें और उन्हें निखार सकें।

अंतिम पूर्ण बैकअप तीन सप्ताह पहले लिया गया था; दैनिक वृद्धिशील बैकअप भी हैं, और अंतिम दैनिक वृद्धिशील बैकअप 14 घंटे पहले किया गया था,

  • आपके पास कम से कम दैनिक पूर्ण ऑनलाइन बैकअप नहीं है? तुम तो बर्बाद हो गए। लेकिन आप शायद उसी के अभ्यस्त हैं। अच्छी बात यह है कि आपके द्वारा शुरू किया गया पूर्ण बैकअप चल रहा है। सुनिश्चित करें कि प्रबंधन लागतों के हर मिनट को दैनिक ऑनलाइन बैकअप के साथ टाला जा सकता है।

डेटाबेस बैकअप विश्वसनीय माना जाता है; इनका गंभीर परीक्षण किया गया, जिसमें हाल ही में,

  • अति उत्कृष्ट! तब आपको डेटाबेस को एक से अधिक बार पुनर्स्थापित नहीं करना पड़ सकता है।

14 घंटे का डेटा खोना स्वीकार्य नहीं है, लेकिन एक से दो घंटे के डेटा का नुकसान होता है,

  • आपके द्वारा वर्णित परिदृश्य के तहत, सभी दांव बंद हैं। यह एक "सूचना आपदा प्रबंधन" स्थिति है। इस पूरे क्षेत्र में प्रबंधन के लिए एक अच्छी बात यह है कि लागतों का दस्तावेजीकरण किया जा रहा है जो भविष्य में प्रॉपर बैकअप और रिकवरी प्रक्रियाओं और संसाधनों से बचा जा सकता है।

मंचन का वातावरण अंतिम रूप से छह महीने पहले इस्तेमाल किया गया था; ऐसा लगता है कि यह आज तक नहीं है, और इसे स्थापित करने में घंटों लग सकते हैं,

  • यदि आपका बैकअप सिस्टम ऑनलाइन बैकअप (यानी बैकअप के दौरान डेटाबेस पूरी तरह से चालू) का समर्थन करता है, तो आप बैकअप के धीमा होने से बचने के लिए पर्याप्त हार्डवेयर संसाधन होने पर उसी समय स्टेजिंग डेटाबेस को फिर से खोलने के लिए एक्सट्रैक्ट कर सकते हैं।

डेटाबेस Microsoft SQL Server 2008 एंटरप्राइज़ है।

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