দীর্ঘ SQL কাজ: VPN বিচ্ছিন্ন হলেও এটি চালু রাখুন

ইনডেক্স পুনর্নির্মাণের বিশ মিনিট পরেই VPN বিচ্ছিন্ন হয়, আপনার SQL ক্লায়েন্ট ভাঙা সংযোগ দেখায়, আর সুস্পষ্ট প্রশ্নটির সেই ত্রুটিতে কোনো উত্তর নেই। স্টেটমেন্টটি শেষ হয়েছে, রোলব্যাক হয়েছে, নাকি আপনাকে ছাড়াই চলতে থেকেছে? আবার সংযোগ করে আবার জমা দেওয়া তিনটি বিকল্পের মধ্যে সবচেয়ে খারাপ, কারণ এটি একটি অনিশ্চিত ফলাফলকে দুটি সম্ভাব্য ফলাফলে পরিণত করে। পরবর্তী উইন্ডোর আগে কাজটি একটি টেকসই মালিকের কাছে সরিয়ে দিন।

সংযোগ ত্রুটি আপনাকে যা বলে না

ক্লায়েন্ট-সাইড ত্রুটি ক্লায়েন্টের বর্ণনা দেয়। এটি জানায় সকেট বন্ধ হয়েছে, কিন্তু সার্ভার লেনদেনের সঙ্গে কী করেছে তা নয়। স্টেটমেন্টটি এখনও চলতে পারে, লিঙ্কটি মারা যাওয়ার ঠিক আগে কমিট হয়ে থাকতে পারে, অথবা তার সেশন পরিষ্কার করার সময় রোলব্যাক হয়ে থাকতে পারে। তিনটিই আপনার ল্যাপটপে একই বার্তা তৈরি করে।

শুধু সার্ভারের অবস্থাই এটি নিষ্পত্তি করতে পারে। কিছু সিদ্ধান্ত নেওয়ার আগে সেখানে দেখুন।

কাজটি সার্ভার-সাইড মালিকের হাতে দিন

যে কাজে মানুষের নজরদারি লাগে না, সেখানে ডেটাবেস হোস্টকে নির্বাহের মালিক হতে দিন। SQL Server Agent চাহিদা অনুযায়ী বা সময়সূচি অনুযায়ী কাজ চালায় এবং প্রতিটি রান রেকর্ড করে, তাই কাজের জীবনচক্র আপনার VPN সেশনের থেকে স্বাধীন। কাজের পরিচয়ের জন্য ঠিক সেই অনুমতিগুলোই দরকার যা কাজটি চায়, অ্যাডমিনিস্ট্রেটরের সম্পূর্ণ ইন্টারঅ্যাকটিভ প্রেক্ষাপট নয়। তখন ল্যাপটপ কাজ শুরু করে ও ফলাফল পড়ে, কাজটি বাঁচিয়ে রাখা প্রক্রিয়া হওয়ার বদলে।

EXEC msdb.dbo.sp_start_job @job_name = N'nightly-customer-reindex';

Agent-এর প্রাপ্যতা নির্ভর করে আপনি যে সংস্করণ ও পরিষেবা স্থাপন করেছেন তার উপর। এই প্রক্রিয়াটি সব জায়গায় আছে ধরে নেওয়ার বদলে আপনার প্ল্যাটফর্ম আসলে যে প্রক্রিয়া দেয় সেটি ব্যবহার করুন।

ডেটাবেসের কাছাকাছি একটি জাম্প হোস্ট পথ ছোট করে এবং থাকা ভালো, কিন্তু এটি মালিকানার প্রশ্ন বদলায় না। নেটওয়ার্ক শেষ হলে সেশনও শেষ হয়। এটি ব্যবহার করুন পর্যবেক্ষণের জন্য, কাজটি বাঁচিয়ে রাখার জিনিস হিসেবে নয়।

এমন একটি রেকর্ড রেখে যান যা পরের সেশন পড়তে পারে

একটি কাজের নাম বা শনাক্তকারী, লক্ষ্য ডেটাবেস এবং আপনি যে ফলাফল আশা করেন তা লিখে রাখুন। সেই রেকর্ডই অন্য একটি সেশন বা অন্য একজন মানুষকে সেই প্রশ্নের উত্তর দিতে দেয় যা ত্রুটিটি দিতে পারেনি। এটি ছাড়া একটি আপডেটের অস্পষ্ট স্মৃতি থাকে, যাচাইয়ের কোনো উপায় থাকে না।

EXEC msdb.dbo.sp_help_jobhistory @job_name = N'nightly-customer-reindex';

ইতিহাস প্রতিটি ধাপের ফলাফল ও সময় দেখায়, যা একটি একক সফলতার পতাকার চেয়ে বেশি কাজে লাগে। ডেটা বদলায় এমন কাজের জন্য অ্যাপ্লিকেশনের নিজস্ব যাচাইও যোগ করুন: সারির সংখ্যা, একটি চেকসাম বা কাজটি লেখা একটি অবস্থা সারি। দুটি স্বাধীন রেকর্ডই পুনরায় চেষ্টাকে নিরাপদ করে, আর রেকর্ড করা কাজের ইতিহাস তাদের প্রথমটি।

আবার জমা দেওয়ার আগে মিলিয়ে নিন

পর্যবেক্ষণকারী সংযোগটি হারিয়ে গেলে, নতুন একটি শুরু করার আগে বিদ্যমান রানটি খুঁজে নিন। এর ধাপগুলোর ফলাফল পড়ুন এবং ঠিক করুন কাজটি কমিট হয়েছে, আংশিক সম্পন্ন হয়েছে, নাকি কখনও শুরুই হয়নি। তারপরেই ওয়ার্কফ্লো যে পুনরায় চেষ্টার নিয়ম দেয় তা প্রয়োগ করুন, কারণ অন্ধভাবে আবার জমা দিলে একটি লোড দ্বিগুণ হতে পারে বা দ্বিতীয়বার মাঝপথে ব্যর্থ হতে পারে।

টেকসই মালিক ও যাচাইযোগ্য ফলাফল ধরে রাখুন, তাহলে সংক্ষিপ্ত অ্যাক্সেস ব্যর্থতা অনুমানের বদলে অসুবিধা হয়ে ওঠে। এটাই পুরো ডিজাইনের লক্ষ্য: কাজটি তার অনুরোধকারী সংযোগের চেয়ে বেশি দিন বাঁচুক।