Lang SQL-werk: hou dit aan die gang wanneer die VPN val

Die VPN val twintig minute in ’n indeksherbou, jou SQL-kliënt wys ’n gebreekte verbinding, en die ooglopende vraag het geen antwoord in daardie fout nie. Het die stelling klaargemaak, teruggerol, of aangehou hardloop sonder jou? Om weer te koppel en weer in te dien is die slegste van die drie opsies, want dit verander een onsekere uitkoms in twee moontlike. Skuif die werk na iets met ’n duursame eienaar voor die volgende venster.

Wat die verbindingsfout jou nie vertel nie

’n Fout aan die kliëntkant beskryf die kliënt. Dit rapporteer dat die sok gesluit is, nie wat die bediener met die transaksie gedoen het nie. Die stelling voer moontlik nog uit, het dalk net voor die skakel dood is vasgelê, of het teruggerol toe sy sessie opgeruim is. Al drie lewer dieselfde boodskap op jou skootrekenaar.

Die bediener se toestand is die enigste bron wat dit kan besleg. Kyk daar voordat jy enigiets besluit.

Gee die werk aan ’n eienaar aan die bedienerkant

Vir werk wat nie ’n mens hoef dop te hou nie, laat die databasis-gasheer die uitvoering besit. SQL Server Agent hardloop take op aanvraag of volgens ’n skedule en teken elke loop aan, so die taak se lewensiklus is onafhanklik van jou VPN-sessie. Die taak se identiteit het presies die toestemmings nodig wat die werk vereis, nie ’n administrateur se volle interaktiewe konteks nie. Die skootrekenaar begin dan werk en lees resultate in plaas daarvan om die proses te wees wat dit aan die lewe hou.

EXEC msdb.dbo.sp_start_job @job_name = N'nightly-customer-reindex';

Die beskikbaarheid van Agent hang af van die uitgawe en diens wat jy ontplooi het. Gebruik die meganisme wat jou platform werklik bied eerder as om te aanvaar hierdie een bestaan oral.

’n Springgas naby die databasis verkort die pad en is die moeite werd, maar dit verander nie die eienaarskapvraag nie. Die sessie eindig steeds wanneer die netwerk eindig. Gebruik dit om waar te neem, nie om die ding te wees wat die werk aan die lewe hou nie.

Los ’n rekord wat die volgende sessie kan lees

Teken ’n taaknaam of identifiseerder, die teikendatabasis en die resultaat wat jy verwag aan. Daardie rekord is wat ’n ander sessie, of ’n ander persoon, die vraag laat beantwoord wat die fout nie kon nie. Sonder dit het jy ’n vae herinnering aan ’n opdatering en geen manier om dit na te gaan nie.

EXEC msdb.dbo.sp_help_jobhistory @job_name = N'nightly-customer-reindex';

Die geskiedenis wys uitkoms en tydsberekening per stap, wat nuttiger is as ’n enkele suksesvlag. Voeg vir take wat data verander ook die toepassing se eie verifikasie by: ’n rytelling, ’n kontrolesom of ’n statusry wat deur die taak geskryf is. Twee onafhanklike rekords is wat ’n herhaling veilig maak, en die aangetekende taakgeskiedenis is die eerste daarvan.

Versoen voordat jy weer indien

Wanneer die waarnemende verbinding verdwyn, vind die bestaande loop voordat jy ’n ander begin. Lees sy stapuitkomste en besluit of die werk vasgelê, gedeeltelik voltooi of nooit begin het nie. Pas eers dan die herhalingsreël toe wat die werkvloei definieer, want ’n blinde herindiening kan ’n lading dupliseer of ’n tweede keer halfpad misluk.

Hou die duursame eienaar en die inspekteerbare uitkoms, en ’n kort toegangsversaking word ’n ongerief eerder as ’n raaiskoot. Dit is die hele ontwerpdoel: die werk behoort die verbinding te oorleef wat dit aangevra het.