Punë e gjatë SQL: mbajeni duke punuar kur VPN-ja bie

VPN-ja bie njëzet minuta pas fillimit të një rindërtimi indeksi, klienti juaj SQL shfaq një lidhje të prishur, dhe pyetja e dukshme nuk ka përgjigje në atë gabim. A përfundoi deklarata, u kthye mbrapsht, apo vazhdoi të ekzekutohej pa ju? Rilidhja dhe ridërgimi është më i keqi i tre opsioneve, sepse e kthen një rezultat të pasigurt në dy të mundshëm. Zhvendoseni punën te diçka me një pronar të qëndrueshëm përpara dritares tjetër.

Çfarë nuk ju thotë gabimi i lidhjes

Një gabim në anën e klientit përshkruan klientin. Ai raporton se socket-i u mbyll, jo çfarë bëri serveri me transaksionin. Deklarata mund të jetë ende në ekzekutim, mund të jetë konfirmuar pikërisht përpara se lidhja të vdiste, ose mund të jetë kthyer mbrapsht kur sesioni i saj u pastrua. Të tre prodhojnë të njëjtin mesazh në laptopin tuaj.

Vetëm gjendja e serverit mund ta zgjidhë atë. Shikoni atje përpara se të vendosni çdo gjë.

Jepni punën te një pronar në anën e serverit

Për punën që nuk kërkon një njeri që ta mbikëqyrë, lëreni hostin e bazës së të dhënave të zotërojë ekzekutimin. SQL Server Agent ekzekuton punë sipas kërkesës ose sipas një plani dhe regjistron çdo ekzekutim, kështu që cikli i jetës së punës është i pavarur nga sesioni juaj VPN. Identiteti i punës ka nevojë pikërisht për lejet që kërkon detyra, jo për kontekstin e plotë interaktiv të një administratori. Atëherë laptopi fillon punën dhe lexon rezultatet në vend që të jetë procesi që e mban gjallë.

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

Disponueshmëria e Agent varet nga botimi dhe shërbimi që keni vendosur. Përdorni mekanizmin që platforma juaj ofron vërtet, në vend që të supozoni se ky ekziston kudo.

Një host kërcimi pranë bazës së të dhënave shkurton rrugën dhe ia vlen ta kesh, por nuk e ndryshon çështjen e pronësisë. Sesioni përsëri përfundon kur përfundon rrjeti. Përdoreni për të vëzhguar, jo për të qenë gjëja që e mban punën gjallë.

Lini një regjistrim që sesioni i radhës mund ta lexojë

Shkruani një emër pune ose identifikues, bazën e të dhënave objektiv dhe rezultatin që prisni. Ky regjistrim është ai që lejon një sesion tjetër, ose një person tjetër, të përgjigjet pyetjes që gabimi nuk mundi. Pa të mbetet një kujtim i paqartë për një përditësim dhe asnjë mënyrë për ta kontrolluar.

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

Historiku tregon rezultatin dhe kohën për çdo hap, që është më i dobishëm se një flamur i vetëm suksesi. Për detyrat që ndryshojnë të dhëna, shtoni edhe verifikimin e vetë aplikacionit: një numërim rreshtash, një checksum ose një rresht statusi të shkruar nga puna. Dy regjistrime të pavarura janë ajo që e bën të sigurt një provë të dytë, dhe historiku i punës i regjistruar është i pari prej tyre.

Pajtohuni përpara se të ridërgoni

Kur lidhja vëzhguese zhduket, gjeni ekzekutimin ekzistues përpara se të nisni një tjetër. Lexoni rezultatet e hapave të tij dhe vendosni nëse puna u konfirmua, u përfundua pjesërisht apo nuk filloi kurrë. Vetëm atëherë zbatoni rregullin e provës së dytë që përcakton rrjedha e punës, sepse një ridërgim i verbër mund të dyfishojë një ngarkim ose të dështojë përsëri në gjysmë të rrugës.

Mbani pronarin e qëndrueshëm dhe rezultatin e inspektueshëm, dhe një dështim i shkurtër aksesi bëhet shqetësim në vend të një hamendjeje. Ky është i gjithë qëllimi i projektimit: puna duhet t'i mbijetojë lidhjes që e kërkoi.