مهمة SQL طويلة: أبقوها تعمل عندما ينقطع VPN
انقطاع VPN يترك سؤالاً واحداً لا يستطيع خطأ العميل الإجابة عنه: هل تم تثبيت العمل؟ سلّموا المهام الطويلة إلى مالك دائم وقارنوا النتائج قبل إعادة المحاولة.
ينقطع VPN بعد عشرين دقيقة من بدء إعادة بناء فهرس، ويعرض عميل SQL اتصالاً مكسوراً، والسؤال البديهي لا يجد إجابة في ذلك الخطأ. هل انتهت العبارة، أم تراجعت، أم استمرت في العمل من دونكم؟ إعادة الاتصال وإعادة الإرسال هي الأسوأ بين الخيارات الثلاثة، لأنها تحوّل نتيجة واحدة غير مؤكدة إلى نتيجتين محتملتين. انقلوا العمل إلى شيء له مالك دائم قبل النافذة التالية.
ما لا يخبركم به خطأ الاتصال
الخطأ على جانب العميل يصف العميل. يبلّغ بأن المقبس أُغلق، لا بما فعله الخادم بالمعاملة. قد تكون العبارة ما زالت تُنفَّذ، أو ربما ثُبِّتت قبل موت الرابط بلحظات، أو تراجعت عندما نُظّفت جلستها. الحالات الثلاث تنتج الرسالة نفسها على حاسوبكم المحمول.
حالة الخادم هي المصدر الوحيد القادر على حسم الأمر. انظروا هناك قبل أن تقرروا أي شيء.
سلّموا العمل إلى مالك على جانب الخادم
للعمل الذي لا يحتاج إلى إنسان يراقبه، دعوا مضيف قاعدة البيانات يملك التنفيذ. يشغّل SQL Server Agent المهام عند الطلب أو وفق جدول ويسجّل كل تنفيذ، فتكون دورة حياة المهمة مستقلة عن جلسة VPN الخاصة بكم. تحتاج هوية المهمة إلى الأذونات التي تتطلبها المهمة بالضبط، لا إلى السياق التفاعلي الكامل لمسؤول. عندها يبدأ الحاسوب المحمول العمل ويقرأ النتائج بدلاً من أن يكون العملية التي تُبقيه حياً.
EXEC msdb.dbo.sp_start_job @job_name = N'nightly-customer-reindex';يعتمد توفر الوكيل على الإصدار والخدمة التي نشرتموها. استخدموا الآلية التي توفرها منصتكم فعلاً بدلاً من افتراض أن هذه الآلية موجودة في كل مكان.
خادم قفز قريب من قاعدة البيانات يقصّر المسار ويستحق أن يكون موجوداً، لكنه لا يغيّر مسألة الملكية. الجلسة تنتهي مع انتهاء الشبكة. استخدموه للمراقبة، لا لتكونوا الشيء الذي يُبقي العمل حياً.
اتركوا سجلاً تستطيع الجلسة التالية قراءته
سجّلوا اسم المهمة أو معرّفها، وقاعدة البيانات الهدف، والنتيجة التي تتوقعونها. ذلك السجل هو ما يتيح لجلسة أخرى، أو لشخص آخر، الإجابة عن السؤال الذي عجز الخطأ عنه. من دونه تبقى لديكم ذكرى غامضة عن تحديث ولا سبيل للتحقق.
EXEC msdb.dbo.sp_help_jobhistory @job_name = N'nightly-customer-reindex';يُظهر السجل النتيجة والتوقيت لكل خطوة، وهو أنفع من راية نجاح واحدة. وبالنسبة إلى المهام التي تغيّر البيانات، أضيفوا تحقق التطبيق نفسه أيضاً: عدد صفوف أو مجموع تحقق أو صف حالة تكتبه المهمة. سجلان مستقلان هما ما يجعل إعادة المحاولة آمنة، وأول هذين السجلين هو سجل المهمة المسجَّل.
طابِقوا قبل أن تعيدوا الإرسال
عندما يختفي الاتصال المراقب، اعثروا على التشغيل القائم قبل بدء آخر. اقرأوا نتائج خطواته وقرروا ما إذا كان العمل قد ثُبِّت أو اكتمل جزئياً أو لم يبدأ قط. عندئذ فقط طبّقوا قاعدة إعادة المحاولة التي يعرّفها سير العمل، لأن إعادة إرسال عمياء قد تكرر تحميلاً أو تفشل في منتصف الطريق مرة ثانية.
احتفظوا بالمالك الدائم والنتيجة القابلة للفحص، فيصبح فشل وصول قصير إزعاجاً لا تخميناً. هذا هو هدف التصميم كله: يجب أن يعيش العمل أطول من الاتصال الذي طلبه.