Дуготрајни 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';

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

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

Када посматрачка веза нестане, пронађите постојеће покретање пре него што започнете ново. Прочитајте исходе његових корака и одлучите да ли је посао потврђен, делимично завршен или никада није почео. Тек тада примените правило понављања које прописује ток посла, јер слепо поновно слање може удвостручити учитавање или други пут пасти на пола пута.

Задржите трајног власника и проверљиви исход, и кратак прекид приступа постаје непријатност, а не нагађање. То је цео циљ дизајна: посао треба да надживи везу која га је затражила.