Ilgs SQL darbs: turiet to darbībā, kad VPN atkrīt

VPN atkrīt divdesmit minūtes pēc indeksa pārbūves sākuma, jūsu SQL klients rāda pārtrauktu savienojumu, un acīmredzamajam jautājumam šajā kļūdā nav atbildes. Vai priekšraksts beidzās, tika atritināts, vai turpināja darboties bez jums? Atkārtota pievienošanās un atkārtota nosūtīšana ir sliktākā no trim iespējām, jo tā vienu nenoteiktu iznākumu pārvērš divos iespējamos. Pirms nākamā loga pārvietojiet darbu uz kaut ko ar noturīgu īpašnieku.

Ko savienojuma kļūda jums nepasaka

Klienta puses kļūda raksturo klientu. Tā ziņo, ka ligzda tika aizvērta, nevis ko serveris izdarīja ar darījumu. Priekšraksts var vēl izpildīties, var būt apstiprināts tieši pirms saites bojāejas vai atritināts, kad tā sesija tika notīrīta. Visi trīs jūsu klēpjdatorā rada to pašu ziņojumu.

Tikai servera stāvoklis var to izšķirt. Paskatieties tur, pirms kaut ko izlemjat.

Nododiet darbu servera puses īpašniekam

Darbam, kam nav vajadzīgs cilvēks, kas to uzrauga, ļaujiet datubāzes resursdatoram piederēt izpildei. SQL Server Agent izpilda darbus pēc pieprasījuma vai pēc grafika un reģistrē katru izpildi, tāpēc darba dzīves cikls nav atkarīgs no jūsu VPN sesijas. Darba identitātei ir vajadzīgas tieši tās atļaujas, ko prasa uzdevums, nevis pilns administratora interaktīvais konteksts. Tad klēpjdators sāk darbu un nolasa rezultātus, nevis ir process, kas to uztur dzīvu.

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

Agent pieejamība ir atkarīga no izdevuma un pakalpojuma, ko esat izvietojis. Izmantojiet mehānismu, ko jūsu platforma patiešām nodrošina, nevis pieņemiet, ka šis ir visur.

Lēciena resursdators datubāzes tuvumā saīsina ceļu un ir tā vērts, bet tas nemaina īpašumtiesību jautājumu. Sesija tomēr beidzas, kad beidzas tīkls. Izmantojiet to novērošanai, nevis kā to, kas uztur darbu dzīvu.

Atstājiet ierakstu, ko nākamā sesija varēs nolasīt

Pierakstiet darba nosaukumu vai identifikatoru, mērķa datubāzi un rezultātu, ko gaidāt. Tieši šis ieraksts ļauj citai sesijai vai citam cilvēkam atbildēt uz jautājumu, uz ko kļūda nevarēja atbildēt. Bez tā paliek neskaidra atmiņa par atjauninājumu un nav veida, kā pārbaudīt.

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

Vēsture rāda rezultātu un laiku katram solim, kas ir noderīgāk par vienu veiksmes karodziņu. Darbiem, kas maina datus, pievienojiet arī pašas lietojumprogrammas pārbaudi: rindu skaitu, kontrolsummu vai darba rakstītu statusa rindu. Divi neatkarīgi ieraksti ir tas, kas padara atkārtošanu drošu, un reģistrētā darba vēsture ir pirmais no tiem.

Saskaņojiet pirms atkārtotas nosūtīšanas

Kad novērojošais savienojums pazūd, atrodiet esošo izpildi, pirms sākat citu. Izlasiet tā soļu rezultātus un izlemiet, vai darbs tika apstiprināts, daļēji pabeigts vai nekad netika sākts. Tikai tad piemērojiet atkārtošanas noteikumu, ko definē darbplūsma, jo akla atkārtota nosūtīšana var dublēt ielādi vai otrreiz neizdoties pusceļā.

Saglabājiet noturīgo īpašnieku un pārbaudāmo rezultātu, un īslaicīga piekļuves kļūme kļūst par neērtību, nevis minējumu. Tas ir viss dizaina mērķis: darbam jāpārdzīvo savienojums, kas to pieprasīja.