کار طولانی 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';

تاریخچه نتیجه و زمان هر گام را نشان می‌دهد، که از یک پرچم موفقیت تنها سودمندتر است. برای کارهایی که داده را تغییر می‌دهند، بررسی خود برنامه را هم بیفزایید: تعداد سطر، یک چک‌سام یا سطر وضعیتی که کار می‌نویسد. دو رکورد مستقل است که تلاش دوباره را ایمن می‌کند، و تاریخچهٔ ثبت‌شدهٔ کار اولین آن‌هاست.

پیش از ارسال دوباره تطبیق دهید

وقتی اتصال ناظر ناپدید می‌شود، پیش از شروع اجرای دیگر، اجرای موجود را پیدا کنید. نتایج گام‌هایش را بخوانید و تصمیم بگیرید که کار ثبت شد، به‌طور جزئی کامل شد یا هرگز شروع نشد. تنها آن‌گاه قاعدهٔ تلاش دوباره را که گردش کار تعریف می‌کند اعمال کنید، چون ارسال دوبارهٔ کورکورانه می‌تواند یک بارگذاری را تکراری کند یا بار دوم در میانه شکست بخورد.

مالک ماندگار و نتیجهٔ قابل بازرسی را نگه دارید، و یک شکست دسترسی کوتاه به ناراحتی تبدیل می‌شود نه به حدس. این تمام هدف طراحی است: کار باید بیشتر از اتصالی که آن را خواست عمر کند.