Hosszú SQL-feladat: tartsa futva, amikor a VPN megszakad

A VPN húsz perccel egy indexújraépítés kezdete után megszakad, az SQL-ügyfél megszakadt kapcsolatot mutat, és a kézenfekvő kérdésre nincs válasz abban a hibában. Befejeződött az utasítás, visszagurult, vagy ön nélkül tovább futott? Az újracsatlakozás és az újraküldés a három lehetőség közül a legrosszabb, mert egy bizonytalan eredményt két lehetségessé alakít. A következő ablak előtt vigye át a munkát valamire, aminek tartós tulajdonosa van.

Amit a kapcsolathiba nem mond el

Az ügyféloldali hiba az ügyfelet írja le. Azt jelenti, hogy a socket bezárult, nem azt, hogy a kiszolgáló mit tett a tranzakcióval. Az utasítás még futhat, jóváhagyást kaphatott közvetlenül a kapcsolat megszakadása előtt, vagy visszagurulhatott, amikor a munkamenetét kitakarították. Mindhárom ugyanazt az üzenetet adja a laptopján.

Csak a kiszolgáló állapota döntheti el. Nézzen oda, mielőtt bármit eldönt.

Adja a munkát kiszolgálóoldali tulajdonosnak

Az olyan munkához, amelyhez nem kell ember, aki figyelje, hagyja, hogy az adatbázis-gazda birtokolja a végrehajtást. Az SQL Server Agent igény szerint vagy ütemezés szerint futtat feladatokat, és minden futást rögzít, így a feladat életciklusa független a VPN-munkamenetétől. A feladat identitásának pontosan azokra az engedélyekre van szüksége, amelyeket a feladat megkövetel, nem egy rendszergazda teljes interaktív környezetére. Ezután a laptop elindítja a munkát és olvassa az eredményeket, ahelyett hogy az a folyamat lenne, amely életben tartja.

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

Az Agent elérhetősége a telepített kiadástól és szolgáltatástól függ. Használja azt a mechanizmust, amelyet a platformja valóban kínál, ahelyett hogy feltételezné, hogy ez mindenhol létezik.

Az adatbázis közelében lévő ugrógép lerövidíti az utat és érdemes fenntartani, de nem változtat a tulajdonjog kérdésén. A munkamenet akkor is véget ér, amikor a hálózat véget ér. Megfigyelésre használja, ne arra, hogy az legyen, ami életben tartja a munkát.

Hagyjon olyan rekordot, amelyet a következő munkamenet olvashat

Jegyezze fel a feladat nevét vagy azonosítóját, a cél adatbázist és a várt eredményt. Ez a rekord teszi lehetővé, hogy egy másik munkamenet vagy egy másik személy megválaszolja a kérdést, amelyet a hiba nem tudott. Nélküle csak egy homályos emléke marad a frissítésről, és semmi módja az ellenőrzésre.

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

Az előzmények lépésenként mutatják az eredményt és az időzítést, ami hasznosabb egyetlen sikerjelzőnél. Az adatokat módosító feladatokhoz adja hozzá az alkalmazás saját ellenőrzését is: sorszám, ellenőrző összeg vagy a feladat által írt állapotsor. Két független rekord teszi biztonságossá az ismétlést, és a rögzített feladat-előzmények az első közülük.

Egyeztessen, mielőtt újraküldi

Amikor a megfigyelő kapcsolat eltűnik, keresse meg a meglévő futást, mielőtt másikat indítana. Olvassa el a lépéseinek eredményeit, és döntse el, hogy a munka jóváhagyást kapott, részben befejeződött vagy soha nem indult el. Csak ezután alkalmazza a munkafolyamat által meghatározott ismétlési szabályt, mert a vak újraküldés megkettőzhet egy betöltést, vagy másodszor is félúton elbukhat.

Tartsa meg a tartós tulajdonost és az ellenőrizhető eredményt, és egy rövid hozzáférési hiba kellemetlenséggé válik találgatás helyett. Ez a teljes tervezési cél: a munkának túl kell élnie a kapcsolatot, amely kérte.