डेटा माइग्रेशन की योजना के लिए आपका वर्कफ़्लो क्या है?


23

इसलिए कई बार मुझे एक सॉफ्टवेयर डेवलपमेंट के प्रयास के अंत में लाया गया है और "ठीक है, जैसा कुछ बताया गया है , हमें यह सब नया कोड मिल गया है और इसे बदलने के लिए टेबल और माइग्रेट होने के लिए डेटा की आवश्यकता है"।

ऐसा लगता है कि हर बार यह एक बारगी, शूट-ऑफ-द-हिप, बेस्ट-अंदाज परिदृश्य है। मुझे ऐसा लगता है कि यह डीबीए के रूप में मेरा सबसे कमजोर कौशल सेट है।

मैं डेटा माइग्रेशन के करीब पहुंचने, प्रबंधन और परीक्षण के लिए कुछ पैटर्न में आना चाहता हूं ।

कृपया मुझे कुछ सर्वोत्तम प्रथाओं और / या जहां मुझे इस क्षेत्र में बेहतर बनाने में मदद करने के लिए सीखने की सामग्री मिल सकती है, का सुराग दें।

जवाबों:


14

हर बार जब मैंने इसे किया है, हम दो पास के लिए गए हैं ...

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

फिर, सप्ताहांत में, आपके पास एक शेड्यूल आउटेज है:

  1. शुक्रवार की रात, डेटाबेस का उपयोग करने वाली प्रणालियों को नीचे लाया जाता है, एक पूर्ण कोल्ड बैकअप बनाया जाता है, और डेटा को माइग्रेट / संशोधित / जो कुछ भी करने के लिए स्क्रिप्ट चलाए जाते हैं
  2. सिस्टम को कुछ निजी पते के तहत वापस लाया जाता है या किसी तरह सेट किया जाता है ताकि यह किसी के लिए भी नहीं खुले लेकिन स्वीकृति परीक्षण के लिए हितधारक हों
  3. यदि हितधारक अनुमोदन करते हैं, तो सिस्टम ऑनलाइन डाल दिया जाता है और सार्वजनिक हो जाता है; यदि नहीं, तो डेटाबेस को शुक्रवार की रात बैकअप से बहाल किया जाता है, और आप फिर से प्रक्रिया शुरू करते हैं।

हमारे शेड्यूल के साथ, डेटाबेस लोगों को बैकअप और माइग्रेशन स्क्रिप्ट्स को चलाने के लिए आम तौर पर शुक्रवार को शाम 6 बजे से शनिवार सुबह 10 बजे तक होता था, इसलिए हमारा लक्ष्य था कि वे 8 घंटे (~ 6 बैकअप था) के तहत चलेंगे, इसलिए हम ' d हमारे हितधारकों के लिए जारी होने से पहले हमारे परीक्षण और सुधार के लिए कुछ समय है।

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

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

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


6

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

यह एक दिलचस्प विषय है, रोनाल्ड।


5

अब तक के अच्छे जवाब। मैं विचार के लिए कुछ और बिंदु जोड़ूंगा।

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

  • संसाधित किए गए बनाम रिकॉर्ड में रिकॉर्ड की गणना करें।
  • परिवर्तन के दौरान त्रुटियों का पता लगाएं और एक तरह से उनके साथ व्यवहार करें जो परिवर्तन को जारी रखने की अनुमति देता है और एक बार ठीक किए जाने के बाद "खराब" रिकॉर्ड को फिर से संसाधित करने की अनुमति देता है।
  • रिकॉर्ड काउंट में "खराब" रिकॉर्ड शामिल होना चाहिए - यानी, रिकॉर्ड-इन = रिकॉर्ड-आउट-अच्छा + बुरा-रिकॉर्ड
  • यदि आपका परिवर्तन रिकॉर्ड गणना को बदलता है (उदाहरण के लिए एक इनपुट रिकॉर्ड एक से अधिक आउटपुट रिकॉर्ड बन जाता है, तो आपके द्वारा समाप्त होने वाले आउटपुट रिकॉर्ड की संख्या का अनुमान लगाने का एक तरीका है, और फिर उस गणना के खिलाफ अपने परिणामों का परीक्षण करें।

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


4

यह कैसे करना है का अवलोकन

साथ शुरू करने के लिए

  • आपके पास "के बाद" डेटाबेस में परीक्षण / यूएटी / जो भी "काम कर रहे डीबी"
  • आपके पास उत्पादन में "पहले" डेटाबेस है। तो इसका उपयोग कहीं न कहीं उत्पादन की प्रति बनाने के लिए करें = "संदर्भ DB"। और दूसरा "स्क्रिप्ट टेस्ट DB"
  • मुझे यह भी उम्मीद है कि आपके पास अपनी ALTERs आदि के साथ विकास लिपियों का एक समूह होगा। यदि हां, तो आपके विकास स्क्रिप्ट के साथ उत्पादन की एक और प्रति, साफ़ और क्रम में उपयोगी है = "DB बदलें"

अगला, Redoad Red Gate Embarcadero SQL Change Manager जैसे टूल या किसी चीज़ की तुलना करता है । आप इसके बिना आसानी से प्रवास नहीं कर सकते। लागत बची हुई समय की मात्रा के लिए तुच्छ है। और सबसे महत्वपूर्ण बात यह है कि उत्पन्न स्क्रिप्ट एक एकल लेनदेन में बदलाव करती है जिसका अर्थ है एक साफ तैनाती

अभी व,

  • "संदर्भ" और "परिवर्तन" के बीच तुलना करने वाले टूल का उपयोग करके परिवर्तन और रोलबैक स्क्रिप्ट उत्पन्न करें
  • परिवर्तन स्क्रिप्ट को "स्क्रिप्ट परीक्षण" पर लागू करें और "वर्किंग डीबी" पर वापस तुलना करें
  • रोलबैक स्क्रिप्ट को "स्क्रिप्ट परीक्षण" पर लागू करें और वापस "की तुलना करें" और "वर्किंग डीबी" की तुलना करें।

अब, आपके पास जब भी आवेदन करने के लिए सुरक्षित + परीक्षण परिवर्तन और रोलबैक स्क्रिप्ट है।

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

रेड गेट टूल एक फ़ोल्डर के खिलाफ तुलना कर सकते हैं जो स्रोत नियंत्रण में है। फिर हम वास्तविक परिवर्तन लिपियों के लिए अलग से अपने स्रोत नियंत्रण में ALTERs आदि को कैप्चर करते हैं।

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