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

Историјата го покажува резултатот и времето по чекор, што е покорисно од едно знаменце за успех. За задачи што менуваат податоци, додајте и сопствена проверка на апликацијата: број на редови, контролна сума или статусен ред што го запишува задачата. Два независни записи се она што го прави повторувањето безбедно, а запишаната историја на задачата е првиот од нив.

Усогласете пред повторно испраќање

Кога набљудувачката врска исчезнува, пронајдете го постојното извршување пред да започнете друго. Прочитајте ги резултатите од неговите чекори и одлучете дали работата е потврдена, делумно завршена или никогаш не започнала. Само тогаш применете го правилото за повторување што го дефинира работниот тек, бидејќи слепото повторно испраќање може да го дуплира вчитувањето или по втор пат да пропадне на половина пат.

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