Длительная задача 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';

История показывает результат и время по каждому шагу, что полезнее одного флага успеха. Для задач, изменяющих данные, добавьте и собственную проверку приложения: число строк, контрольную сумму или строку состояния, записанную заданием. Именно два независимых источника делают повтор безопасным, и записанная история заданий — первый из них.

Сверьте состояние, прежде чем отправлять заново

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

Сохраняйте постоянного владельца и проверяемый результат, и короткий сбой доступа становится неудобством, а не догадкой. В этом и весь смысл дизайна: работа должна пережить соединение, которое её запросило.