طویل 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';

تاریخ ہر مرحلے کا نتیجہ اور وقت دکھاتی ہے، جو ایک کامیابی کے جھنڈے سے زیادہ مفید ہے۔ ڈیٹا بدلنے والے کاموں کے لیے ایپلیکیشن کی اپنی تصدیق بھی شامل کریں: قطاروں کی گنتی، چیک سم یا کام کی لکھی ہوئی اسٹیٹس قطار۔ دو خودمختار ریکارڈ ہی دوبارہ کوشش کو محفوظ بناتے ہیں، اور درج شدہ کام کی تاریخ ان میں پہلی ہے۔

دوبارہ بھیجنے سے پہلے موازنہ کریں

جب مشاہداتی کنکشن غائب ہو جائے، تو دوسرا شروع کرنے سے پہلے موجودہ رن تلاش کریں۔ اس کے مراحل کے نتائج پڑھیں اور فیصلہ کریں کہ کام کمٹ ہوا، جزوی طور پر مکمل ہوا، یا کبھی شروع ہی نہیں ہوا۔ تبھی ورک فلو کا متعین کردہ دوبارہ کوشش کا قاعدہ لاگو کریں، کیونکہ آنکھ بند کر کے دوبارہ بھیجنا لوڈ کو دگنا کر سکتا ہے یا دوسری بار آدھے راستے میں ناکام ہو سکتا ہے۔

مستقل مالک اور قابل جانچ نتیجہ برقرار رکھیں، پھر ایک مختصر رسائی کی ناکامی اندازے کے بجائے تکلیف بن جاتی ہے۔ یہی پوری ڈیزائن کا مقصد ہے: کام کو اس کنکشن سے زیادہ زندہ رہنا چاہیے جس نے اس کی درخواست کی۔