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 भइसकेको छ, वा अझै नसुल्झिएको छ भनी बताउन दिनुहोस्।