Довга задача 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';

Історія показує результат і час за кожним кроком, що корисніше за єдиний прапорець успіху. Для завдань, що змінюють дані, додайте й власну перевірку застосунку: кількість рядків, контрольну суму або рядок стану, записаний завданням. Два незалежні записи роблять повтор безпечним, і записана історія завдань — перший із них.

Звірте стан, перш ніж надсилати знову

Коли спостережне з'єднання зникає, знайдіть наявний запуск, перш ніж починати інший. Прочитайте результати його кроків і вирішіть, чи роботу зафіксовано, частково завершено чи взагалі не розпочато. Лише тоді застосуйте правило повтору, визначене процесом, бо сліпе повторне надсилання може продублювати завантаження або вдруге зірватися на півдорозі.

Зберігайте постійного власника й перевірюваний результат, і короткий збій доступу стає незручністю, а не здогадом. У цьому й весь сенс дизайну: робота має пережити з'єднання, яке її запросило.