Longa SQL-tasko: tenu ĝin funkcianta kiam la VPN falas

La VPN falas dudek minutojn post la komenco de indeksa rekonstruo, via SQL-kliento montras rompitan konekton, kaj la evidenta demando havas neniun respondon en tiu eraro. Ĉu la komando finiĝis, retroiĝis, aŭ daŭrigis sen vi? Rekonektiĝi kaj resendi estas la plej malbona el la tri ebloj, ĉar ĝi transformas unu necertan rezulton en du eblajn. Movu la laboron al io kun daŭra posedanto antaŭ la sekva fenestro.

Kion la konekta eraro ne diras al vi

Eraro ĉe la klienta flanko priskribas la klienton. Ĝi raportas, ke la ingo fermiĝis, ne kion la servilo faris kun la transakcio. La komando eble ankoraŭ plenumiĝas, eble estis fiksita ĝuste antaŭ ol la ligilo mortis, aŭ eble retroiĝis kiam ĝia seanco estis purigita. Ĉiuj tri kazoj produktas la saman mesaĝon sur via tekkomputilo.

Nur la stato de la servilo povas decidi tion. Rigardu tien antaŭ ol decidi ion ajn.

Donu la laboron al posedanto ĉe la servila flanko

Por laboro, kiu ne bezonas homon observantan, lasu la gastiganton de la datumbazo posedi la plenumadon. SQL Server Agent rulas taskojn laŭ peto aŭ laŭ horaro kaj registras ĉiun ruladon, do la vivociklo de la tasko sendependas de via VPN-seanco. La identeco de la tasko bezonas ĝuste la permesojn, kiujn la tasko postulas, ne la plenan interagan kuntekston de administranto. Poste la tekkomputilo komencas laboron kaj legas rezultojn anstataŭ esti la procezo, kiu tenas ĝin viva.

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

La disponebleco de Agent dependas de la eldono kaj servo, kiujn vi deplojis. Uzu la mekanismon, kiun via platformo efektive provizas, anstataŭ supozi, ke ĉi tiu ekzistas ĉie.

Saltgastiganto proksime al la datumbazo mallongigas la vojon kaj indas havi, sed ĝi ne ŝanĝas la demandon pri posedado. La seanco ankoraŭ finiĝas kiam la reto finiĝas. Uzu ĝin por observi, ne por esti tio, kio tenas la laboron viva.

Lasu rikordon, kiun la sekva seanco povas legi

Notu taskan nomon aŭ identigilon, la celan datumbazon kaj la rezulton, kiun vi atendas. Ĝuste tiu rikordo ebligas al alia seanco, aŭ al alia persono, respondi la demandon, kiun la eraro ne povis. Sen ĝi restas al vi nebula memoro pri ĝisdatigo kaj neniu maniero kontroli.

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

La historio montras rezulton kaj tempon laŭ paŝoj, kio pli utilas ol unu sukcesa flago. Por taskoj, kiuj ŝanĝas datumojn, aldonu ankaŭ la propran kontrolon de la aplikaĵo: nombron da vicoj, kontrolsumon aŭ statusan vicon skribitan de la tasko. Du sendependaj rikordoj estas tio, kio faras redisprobon sekura, kaj la registrita taskhistorio estas la unua el ili.

Kongruu antaŭ ol resendi

Kiam la observa konekto malaperas, trovu la ekzistantan ruladon antaŭ ol komenci alian. Legu ĝiajn paŝajn rezultojn kaj decidu, ĉu la laboro estis fiksita, parte finita aŭ neniam komencita. Nur tiam apliku la redisproban regulon, kiun difinas la laborfluo, ĉar blinda resendo povas duobligi ŝarĝon aŭ malsukcesi duone duan fojon.

Tenu la daŭran posedanton kaj la inspektan rezulton, kaj mallonga alirfiasko fariĝas ĝeno anstataŭ konjekto. Tio estas la tuta celo de la dezajno: la laboro devus supervivi la konekton, kiu petis ĝin.