VPN तुटल्यानंतर SQL Server वरून Oracle मध्ये लोड पुनर्प्राप्त करा
VPN तुटल्यावर Oracle मधील commit पूर्ण झाला का याची खात्री कॉलरला राहत नाही। टिकाऊ बॅच ID मुळे एक्सट्रॅक्शन, वापर आणि जुळणी या प्रश्नांची उत्तरे एकामागून एक देता येतात।
VPN तुटल्यावर डेटाबेस-ते-डेटाबेस हस्तांतरण मरते, आणि «पुन्हा चालव» ही पुनर्प्राप्ती योजना नाही। स्रोताचे एक्सट्रॅक्शन पूर्ण झालेले असू शकते, लक्ष्याने आधीच commit केलेले असू शकते, किंवा उत्तर परतीच्या वाटेवर नुसते हरवलेले असू शकते। या तीन अवस्थांसाठी वेगवेगळे उपाय लागतात, आणि फक्त «त्रुटी» माहीत असलेला क्लायंट त्यांना वेगळे ओळखू शकत नाही।
उपाय स्थापत्यविषयक आहे: प्रत्येक रनला टिकाऊ बॅच ओळख द्या, आणि क्लायंटला अंदाज करू देण्याऐवजी डेटाबेसना प्रश्नांची उत्तरे देऊ द्या।
डेटाबेस प्रत्यक्षात काय हमी देतो
SQL Server आणि Oracle दोन्ही व्यवहाराच्या आत अणुता देतात। दोघांमध्ये अणुता दोन्हीपैकी कोणीही देत नाही। गमावलेले कनेक्शन डेटाबेस खराब करत नाही, आणि हाताने रोलबॅकसाठी भाग पाडत नाही, कारण सर्व्हर तुमच्याशिवाय स्वतःचा व्यवहार सोडवतो। जे तुटते ते म्हणजे निकालाबद्दलचे कॉलरचे ज्ञान।
वेगळे commit म्हणजे वेगळे commit। दोन्ही कनेक्शन वाहून नेणारे VPN दोन commit एका कार्य एककात विलीन करत नाही।
जो commit तुम्ही कधी ऐकला नाही
एक अपयश पद्धत भाबड्या पुनर्प्रयत्न तर्काला शिक्षा करते: सर्व्हर commit करतो, आणि पोच कधीही कॉलरपर्यंत पोहोचत नाही। Oracle हे अज्ञात-निकाल समस्या म्हणून नोंदवतो आणि त्यासाठी व्यवहार दस्तऐवजीकरणात Transaction Guard पुरवतो। दळणवळण त्रुटी हा पाठवलेला commit अपयशी ठरल्याचा पुरावा नाही, आणि तिला पुरावा मानणे हाच एक बॅच दोनदा पोस्ट होण्याचा मार्ग। हा फरक पुनर्प्रयत्न मार्गावर सर्वात महत्त्वाचा आहे, जिथे ऑपरेटरकडे त्रुटी संदेश असतो आणि कृती करण्यासाठी दुसरा कोणताही संकेत नसतो।
म्हणून पुनर्प्राप्तीच्या पायरीने निकाल त्रुटीच्या मजकुरातून अनुमान काढण्याऐवजी लक्ष्यातून वाचला पाहिजे।
हस्तांतरणाला बॅच ओळख द्या
प्रत्येक रनला अपरिवर्तनीय बॅच ID मिळते, आणि लक्ष्य त्या ID ने काय केले याची नोंद करते। जीवनचक्र चार पायऱ्यांचे आहे, आणि विक्रेता कोणीही असो ते सारखेच दिसते:
- एक्सट्रॅक्ट नोंदवलेल्या स्कीमा आणि सीमेसह ओळखलेला, अपरिवर्तनीय स्रोत बॅच।
- हस्तांतरित करा तो लक्ष्याच्या स्टेजिंग भागात, आणि तयार घोषित करण्यापूर्वी अपूर्ण किंवा विरोधाभासी सामग्री शोधा।
- लागू करा लक्ष्याच्या स्वतःच्या विशिष्टता किंवा लॉकिंग नियमांनुसार, आणि त्याच स्थानिक व्यवहारात पूर्तता नोंदवा।
- जुळवा टिकाऊ निकालाला समर्थित प्रोटोकॉलद्वारे, पोच किंवा पुनर्प्रयत्नापूर्वी।
पुनर्प्रयत्न तीच ID पुन्हा वापरतात। प्रत्येक प्रयत्नाला नवीन ID तुम्ही नुकतीच बांधलेली डुप्लिकेट प्रतिबंध थोडक्यात मोडते, जे पुनर्प्रयत्न आवरण स्वयंचलितपणे एक तयार करेपर्यंत स्पष्ट वाटते।
ID तुम्हाला नंतर जुळवण्यासाठी काहीतरी देते, क्लायंट प्रक्रिया खूप आधीच गायब झाल्यानंतरही।
बॅचवर दावा करा, मग लागू करा
लागू करण्याच्या पायरीने बॅच ID वर दावा करावा, व्यवसाय बदल करावेत, आणि पूर्तता एका स्थानिक व्यवहारात नोंदवावी। तपासणी आणि इन्सर्ट वेगवेगळ्या विधानांमध्ये केल्यास तुम्ही काढून टाकू पाहत असलेली शर्यत परत येते। दोन कामगार स्पर्धा करत असतील, तर नेमका एक दावा जिंकतो आणि दुसऱ्याला ते सांगितले जाते।
पूर्ततेची नोंद नसणे हा प्रगतीपथावर असलेला व्यवहार कधीही commit करणार नाही याचा पुरावा नाही। दाव्याने स्पर्धक प्रयत्नांचे क्रमीकरण केले पाहिजे, किंवा प्रोटोकॉलने कोणताही निर्णय घेण्यापूर्वी टिकाऊ निकाल वाचला पाहिजे।
त्या क्रमीकरणासाठी अनुप्रयोग कोडमधील तपासा-मग-पुन्हा करा लूपऐवजी डेटाबेसची समर्थित यंत्रणा वापरा।
रचना अजून काय वचन देऊ शकत नाही
स्टेजिंग काम पुन्हा सुरू करण्यायोग्य बनवते आणि एका दीर्घ सत्रावरील अवलंबित्व कमी करते। ते SQL Server, Oracle आणि काम जे कोणताही बाह्य दुष्परिणाम करते यांच्या पलीकडे एकच अणु commit तयार करत नाही। व्यवसायाला खरोखर त्याची गरज असल्यास, समर्थित वितरित व्यवहार किंवा जुळणी प्रक्रिया रचा आणि पात्र ठरवा, अनिश्चित निकालाचे काम कोणाचे आहे हेही समाविष्ट करून। यापेक्षा कमकुवत काहीही हस्तांतरण कोडमध्ये नाही, जुळणी रनबुकमध्ये येते।
तीन ठिकाणी व्यत्यय स्वीकारा: हस्तांतरणादरम्यान, लागू करताना, आणि commit नंतर पण पोचीपूर्वी। मग क्लायंटच्या संदेशाऐवजी व्यवसाय निकाल तपासा, आणि बॅच लेजरला काम अपूर्ण आहे, commit झाले आहे, की अजून न सुटलेले आहे हे सांगू द्या।