VPN বিচ্ছিন্ন হওয়ার পরে SQL Server থেকে Oracle-এ লোড পুনরুদ্ধার করুন
VPN বিচ্ছিন্ন হলে কলকারী নিশ্চিত হতে পারে না Oracle-এর commit সম্পন্ন হয়েছে কি না। একটি টেকসই ব্যাচ আইডি এক্সট্র্যাক্ট, অ্যাপ্লাই ও রিকনসাইল প্রশ্নগুলোর উত্তর একে একে দিতে দেয়।
VPN বিচ্ছিন্ন হলে ডেটাবেস-থেকে-ডেটাবেস স্থানান্তর মরে যায়, আর «আবার চালাও» কোনো পুনরুদ্ধার পরিকল্পনা নয়। উৎসের এক্সট্র্যাকশন সম্পূর্ণ হতে পারে, লক্ষ্য ইতিমধ্যে commit করে থাকতে পারে, অথবা উত্তরটি ফেরার পথে সহজেই হারিয়ে যেতে পারে। এই তিনটি অবস্থার জন্য ভিন্ন ভিন্ন পদক্ষেপ দরকার, আর শুধু «ত্রুটি» জানে এমন একটি ক্লায়েন্ট তাদের আলাদা করতে পারে না।
সমাধানটি স্থাপত্যগত: প্রতিটি রানকে একটি টেকসই ব্যাচ পরিচয় দিন, আর ক্লায়েন্টকে অনুমান করতে দেওয়ার বদলে ডেটাবেসগুলোকে প্রশ্নের উত্তর দিতে দিন।
ডেটাবেস আসলে কী নিশ্চিত করে
SQL Server ও Oracle উভয়ই একটি লেনদেনের ভেতরে পারমাণবিকতা দেয়। কোনোটিই দুটির মধ্যে পারমাণবিকতা দেয় না। হারানো সংযোগ ডেটাবেস নষ্ট করে না, এবং জোর করে হাতে রোলব্যাকও করায় না, কারণ সার্ভার নিজের লেনদেন নিজেই নিষ্পত্তি করে। যেটি ভাঙে তা হলো ফলাফল সম্পর্কে কলকারীর জ্ঞান।
আলাদা করে commit করা মানে আলাদা করে commit করা। দুটি সংযোগ বহনকারী VPN দুটি commit-কে এক কাজের এককে মেলায় না।
যে commit আপনি কখনো শোনেননি
একটি ব্যর্থতার ধরন সহজ-সরল রিট্রাই লজিককে শাস্তি দেয়: সার্ভার commit করে, আর স্বীকৃতি কখনো কলকারীর কাছে পৌঁছায় না। Oracle এটিকে অজানা-ফলাফল সমস্যা হিসেবে নথিভুক্ত করে এবং এর জন্য লেনদেন ডকুমেন্টেশনে Transaction Guard দেয়। যোগাযোগের ত্রুটি প্রমাণ নয় যে জমা দেওয়া commit ব্যর্থ হয়েছে, আর এটিকে প্রমাণ হিসেবে ধরা হলো একটি ব্যাচ দুইবার পোস্ট হওয়ার উপায়। পার্থক্যটি সবচেয়ে বেশি গুরুত্বপূর্ণ রিট্রাই পথে, যেখানে অপারেটরের হাতে একটি ত্রুটি বার্তা থাকে এবং কাজ করার আর কোনো সংকেত থাকে না।
তাই পুনরুদ্ধারের ধাপটি ত্রুটির লেখা থেকে অনুমান না করে লক্ষ্য থেকে ফলাফল পড়তে হবে।
স্থানান্তরকে একটি ব্যাচ পরিচয় দিন
প্রতিটি রান একটি অপরিবর্তনীয় ব্যাচ আইডি পায়, আর লক্ষ্য সেই আইডি দিয়ে কী করেছে তা লিপিবদ্ধ করে। জীবনচক্র চারটি ধাপ, এবং বিক্রেতা যেই হোক তা একই রকম দেখায়:
- এক্সট্র্যাক্ট একটি চিহ্নিত, অপরিবর্তনীয় উৎস ব্যাচ, রেকর্ডকৃত স্কিমা ও সীমানাসহ।
- স্থানান্তর সেটি লক্ষ্যের স্টেজিং এলাকায়, এবং প্রস্তুত ঘোষণার আগে অসম্পূর্ণ বা বিরোধপূর্ণ বিষয়বস্তু শনাক্ত করুন।
- অ্যাপ্লাই লক্ষ্যের নিজস্ব অনন্যতা বা লকিং নিয়মের অধীনে, এবং একই স্থানীয় লেনদেনে সমাপ্তি লিপিবদ্ধ করুন।
- রিকনসাইল টেকসই ফলাফল সমর্থিত প্রোটোকলের মাধ্যমে, স্বীকৃতি বা পুনরায় চেষ্টার আগে।
রিট্রাই একই আইডি পুনর্ব্যবহার করে। প্রতি চেষ্টায় নতুন আইডি আপনি এইমাত্র যে ডুপ্লিকেট প্রতিরোধ তৈরি করেছেন তা ব্যর্থ করে, যা ততক্ষণ স্পষ্ট শোনায় যতক্ষণ না একটি রিট্রাই র্যাপার স্বয়ংক্রিয়ভাবে একটি তৈরি করে।
আইডিটি পরেও, ক্লায়েন্ট প্রক্রিয়া বহু আগে চলে যাওয়ার পরে, মিলিয়ে দেখার মতো কিছু দেয়।
ব্যাচটি দাবি করুন, তারপর প্রয়োগ করুন
অ্যাপ্লাই ধাপে ব্যাচ আইডি দাবি করতে হবে, ব্যবসায়িক পরিবর্তন করতে হবে, এবং একটি স্থানীয় লেনদেনে সমাপ্তি লিপিবদ্ধ করতে হবে। চেক ও ইনসার্ট আলাদা স্টেটমেন্ট হিসেবে করলে আপনি যে রেস দূর করতে চেয়েছিলেন তা ফিরে আসে। দুজন কর্মী প্রতিযোগিতা করলে ঠিক একটি দাবি জেতে এবং অন্যজনকে তা জানানো হয়।
সমাপ্তির রেকর্ড অনুপস্থিত থাকা প্রমাণ নয় যে চলমান একটি লেনদেন কখনো commit করবে না। দাবিটিকে প্রতিদ্বন্দ্বী প্রচেষ্টাগুলোকে ক্রমিক করতে হবে, অথবা প্রোটোকলকে যেকোনো সিদ্ধান্তের আগে টেকসই ফলাফল পড়তে হবে।
সেই ক্রমিকীকরণের জন্য অ্যাপ্লিকেশন কোডে চেক-তারপর-পুনরাবৃত্তি লুপের বদলে ডেটাবেসের সমর্থিত ব্যবস্থা ব্যবহার করুন।
নকশাটি এখনো যা প্রতিশ্রুতি দিতে পারে না
স্টেজিং কাজটিকে পুনরারম্ভযোগ্য করে এবং একটি দীর্ঘস্থায়ী সেশনের উপর নির্ভরতা কমায়। এটি SQL Server, Oracle এবং কাজটি যে বাহ্যিক পার্শ্বপ্রতিক্রিয়া করে তার ওপর একটি একক পারমাণবিক commit তৈরি করে না। ব্যবসার সত্যিই এটি দরকার হলে, একটি সমর্থিত বিতরণকৃত লেনদেন বা রিকনসিলিয়েশন প্রক্রিয়া নকশা করুন ও যাচাই করুন, যার মধ্যে কে অনিশ্চিত কাজের মালিক তা অন্তর্ভুক্ত। এর চেয়ে দুর্বল যেকোনো কিছু স্থানান্তর কোডে নয়, রিকনসিলিয়েশন রানবুকে থাকা উচিত।
তিন জায়গায় বাধা মেনে নিন: স্থানান্তরের সময়, প্রয়োগের সময়, এবং commit-এর পরে কিন্তু স্বীকৃতির আগে। তারপর ক্লায়েন্টের বার্তা নয়, ব্যবসায়িক ফলাফল যাচাই করুন, আর ব্যাচ লেজারকে বলতে দিন কাজটি অসম্পূর্ণ, commit করা, নাকি এখনো অমীমাংসিত।