Dugotrajni SQL posao: nastavite ga kad VPN padne

VPN padne dvadeset minuta nakon početka ponovne izgradnje indeksa, vaš SQL klijent pokazuje prekinutu vezu, a očito pitanje nema odgovora u toj grešci. Je li naredba završila, poništena, ili se nastavila izvršavati bez vas? Ponovno spajanje i ponovno slanje najgore je od triju rješenja jer jedan neizvjestan ishod pretvara u dva moguća. Premjestite posao na nešto s trajnim vlasnikom prije sljedećeg prozora.

Što vam greška veze ne govori

Greška na strani klijenta opisuje klijent. Javlja da je utičnica zatvorena, ne što je poslužitelj učinio s transakcijom. Naredba se možda još izvršava, možda je potvrđena točno prije nego što je veza pala, ili je poništena kad je njezina sesija očišćena. Sva tri slučaja daju istu poruku na vašem prijenosniku.

Samo stanje poslužitelja može to razriješiti. Pogledajte tamo prije nego što bilo što odlučite.

Dodijelite posao vlasniku na strani poslužitelja

Za poslove koji ne trebaju ljudsko motrenje, neka domaćin baze podataka posjeduje izvršavanje. SQL Server Agent pokreće zadatke na zahtjev ili prema rasporedu i bilježi svako pokretanje, pa je životni ciklus zadatka neovisan o vašoj VPN sesiji. Identitet zadatka treba točno one ovlasti koje zahtijeva posao, a ne potpuni interaktivni kontekst administratora. Prijenosnik tada pokreće posao i čita rezultate umjesto da bude proces koji ga održava na životu.

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

Dostupnost Agenta ovisi o izdanju i usluzi koju ste postavili. Upotrijebite mehanizam koji vaša platforma doista nudi umjesto da pretpostavljate da ovaj postoji svugdje.

Skokoviti host blizu baze podataka skraćuje put i vrijedi ga imati, ali ne mijenja pitanje vlasništva. Sesija ipak završava kad završi mreža. Koristite ga za promatranje, a ne kao stvar koja posao održava na životu.

Ostavite zapis koji sljedeća sesija može pročitati

Zabilježite naziv zadatka ili identifikator, ciljnu bazu podataka i rezultat koji očekujete. Upravo taj zapis omogućuje drugoj sesiji ili drugoj osobi da odgovori na pitanje na koje greška nije mogla. Bez njega ostaje vam nejasno sjećanje na ažuriranje i nikakav način da provjerite.

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

Povijest pokazuje ishod i vrijeme po koraku, što je korisnije od jedne zastavice uspjeha. Za zadatke koji mijenjaju podatke dodajte i vlastitu provjeru aplikacije: broj redaka, kontrolni zbroj ili redak stanja koji je napisao zadatak. Dva neovisna zapisa čine ponovni pokušaj sigurnim, a zabilježena povijest zadatka prvi je od njih.

Usporedite stanje prije ponovnog slanja

Kad promatračka veza nestane, pronađite postojeće pokretanje prije nego što započnete novo. Pročitajte ishode njegovih koraka i odlučite je li posao potvrđen, djelomično dovršen ili nikad nije započeo. Tek tada primijenite pravilo ponavljanja koje propisuje tijek rada, jer slijepo ponovno slanje može udvostručiti učitavanje ili drugi put pasti na pola puta.

Zadržite trajnog vlasnika i provjerljiv ishod, i kratki prekid pristupa postaje neugodnost, a ne nagađanje. To je cijeli cilj dizajna: posao treba nadživjeti vezu koja ga je zatražila.