Երկար SQL աշխատանք. պահեք այն ընթացքի մեջ, երբ VPN-ը կտրվում է

VPN-ը կտրվում է ինդեքսի վերակառուցման մեկնարկից քսան րոպե անց, ձեր SQL հաճախորդը ցույց է տալիս կոտրված միացում, և ակնհայտ հարցն այդ սխալի մեջ պատասխան չունի։ Ավարտվե՞ց հայտարարությունը, հետ գլորվե՞ց, թե՞ շարունակեց աշխատել առանց ձեզ։ Կրկին միանալը և կրկին ուղարկելը երեք տարբերակներից ամենավատն է, որովհետև այն մեկ անորոշ արդյունքը դարձնում է երկու հնարավոր արդյունք։ Հաջորդ պատուհանից առաջ աշխատանքը տեղափոխեք մի բանի, որն ունի կայուն սեփականատեր։

Ինչ չի ասում ձեզ միացման սխալը

Հաճախորդի կողմի սխալը նկարագրում է հաճախորդին։ Այն հաղորդում է, որ սոքեթը փակվել է, ոչ թե ինչ է արել սերվերը գործարքի հետ։ Հայտարարությունը կարող է դեռ կատարվել, կարող է հաստատվել հենց կապի մահից առաջ, կամ հետ գլորվել, երբ նրա սեսիան մաքրվել է։ Բոլոր երեքը ձեր նոութբուքում նույն հաղորդագրությունն են տալիս։

Միայն սերվերի վիճակը կարող է դա լուծել։ Նայեք այնտեղ, նախքան որևէ բան որոշելը։

Հանձնեք աշխատանքը սերվերի կողմի սեփականատիրոջը

Աշխատանքի համար, որը մարդու հսկողություն չի պահանջում, թող տվյալների բազայի հոսթը տիրապետի կատարմանը։ SQL Server Agent-ը առաջադրանքները գործարկում է ըստ պահանջի կամ ըստ ժամանակացույցի և գրանցում է յուրաքանչյուր գործարկում, ուստի առաջադրանքի կյանքի ցիկլը անկախ է ձեր VPN սեսիայից։ Առաջադրանքի ինքնությունը պահանջում է հենց այն թույլտվությունները, որոնք պահանջում է աշխատանքը, ոչ թե ադմինիստրատորի ամբողջական ինտերակտիվ համատեքստը։ Այնուհետև նոութբուքը սկսում է աշխատանքը և կարդում արդյունքները՝ փոխարենը լինելու այն գործընթացը, որը կենդանի է պահում այն։

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

Agent-ի հասանելիությունը կախված է ձեր տեղակայած թողարկումից և ծառայությունից։ Օգտագործեք այն մեխանիզմը, որը ձեր հարթակը իրականում տրամադրում է, փոխարենը ենթադրելու, որ այս մեկը կա ամենուր։

Տվյալների բազայի մոտ ցատկող հոսթը կարճացնում է ուղին և արժե ունենալ, բայց այն չի փոխում սեփականության հարցը։ Սեսիան այնուամենայնիվ ավարտվում է, երբ ավարտվում է ցանցը։ Օգտագործեք այն դիտելու համար, ոչ թե որպես այն բանը, որն աշխատանքը կենդանի է պահում։

Թողեք գրառում, որը հաջորդ սեսիան կկարողանա կարդալ

Գրանցեք առաջադրանքի անունը կամ նույնացուցիչը, նպատակային տվյալների բազան և այն արդյունքը, որը սպասում եք։ Հենց այդ գրառումն է, որ թույլ է տալիս մեկ այլ սեսիայի կամ մեկ այլ մարդու պատասխանել այն հարցին, որին սխալը չկարողացավ։ Առանց դրա մնում է թարմացման աղոտ հիշողություն և ստուգելու ոչ մի եղանակ։

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

Պատմությունը ցույց է տալիս արդյունքը և ժամանակը յուրաքանչյուր քայլի համար, ինչը ավելի օգտակար է, քան մեկ հաջողության դրոշը։ Տվյալները փոխող առաջադրանքների համար ավելացրեք նաև հավելվածի սեփական ստուգումը՝ տողերի քանակ, ստուգիչ գումար կամ առաջադրանքի գրած կարգավիճակի տող։ Երկու անկախ գրառումներն են, որ անվտանգ են դարձնում կրկնափորձը, և գրանցված աշխատանքի պատմությունը դրանցից առաջինն է։

Համաձայնեցրեք նախքան կրկին ուղարկելը

Երբ դիտող միացումը անհետանում է, գտեք գոյություն ունեցող գործարկումը նախքան մյուսը սկսելը։ Կարդացեք դրա քայլերի արդյունքները և որոշեք՝ աշխատանքը հաստատվել է, մասամբ ավարտվել, թե երբեք չի սկսվել։ Միայն այդ ժամանակ կիրառեք աշխատընթացի սահմանած կրկնափորձի կանոնը, որովհետև կույր կրկնուղարկումը կարող է կրկնապատկել բեռնումը կամ երկրորդ անգամ ձախողվել կիսաճանապարհին։

Պահեք կայուն սեփականատերը և ստուգելի արդյունքը, և համառոտ հասանելիության ձախողումը դառնում է անհարմարություն, այլ ոչ թե գուշակություն։ Դա է ամբողջ նախագծման նպատակը՝ աշխատանքը պետք է ապրի ավելի երկար, քան այն միացումը, որը պահանջել է այն։