Дълга 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';

Историята показва резултат и време за всяка стъпка, което е по-полезно от един флаг за успех. За задачи, които променят данни, добавете и собствената проверка на приложението: брой редове, контролна сума или ред за състояние, записан от задачата. Два независими записа правят повторението безопасно, а записаната история на задачата е първият от тях.

Сверявайте състоянието, преди да изпратите отново

Когато наблюдаващата връзка изчезне, намерете съществуващото изпълнение, преди да започнете друго. Прочетете резултатите на стъпките му и решете дали работата е фиксирана, частично завършена или никога не е започвала. Едва тогава приложете правилото за повторение, което работният процес определя, защото сляпото повторно изпращане може да дублира зареждане или да се провали отново по средата.

Запазете трайния собственик и проверимия резултат и кратък отказ на достъпа става неудобство, а не догадка. Това е цялата цел на дизайна: работата трябва да надживее връзката, която я е поискала.