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 हो चुका है, या अभी भी अनसुलझा है।