લાંબી 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';

ઇતિહાસ દરેક પગલાનું પરિણામ અને સમય બતાવે છે, જે એક સફળતા-ધ્વજ કરતાં વધુ ઉપયોગી છે. ડેટા બદલતાં કાર્યો માટે એપ્લિકેશનની પોતાની ચકાસણી પણ ઉમેરો: પંક્તિ-ગણતરી, ચેકસમ અથવા કામ દ્વારા લખાયેલી સ્થિતિ-પંક્તિ. બે સ્વતંત્ર રેકોર્ડ જ ફરી પ્રયાસને સુરક્ષિત બનાવે છે, અને નોંધાયેલ કામનો ઇતિહાસ તેમાંનો પહેલો છે.

ફરી મોકલતા પહેલાં મેળ કરો

જ્યારે નિરીક્ષણનું જોડાણ અદૃશ્ય થાય, ત્યારે બીજું શરૂ કરતા પહેલાં હાલનું રન શોધો. તેના પગલાંનાં પરિણામો વાંચો અને નક્કી કરો કે કામ કમિટ થયું, આંશિક રીતે પૂરું થયું, કે ક્યારેય શરૂ જ નહોતું થયું. પછી જ વર્કફ્લો જે ફરી પ્રયાસનો નિયમ વ્યાખ્યાયિત કરે છે તે લાગુ કરો, કારણ કે આંધળું ફરી મોકલવું લોડને બમણું કરી શકે અથવા બીજી વાર અડધે રસ્તે નિષ્ફળ જઈ શકે.

કાયમી માલિક અને ચકાસી શકાય તેવું પરિણામ જાળવો, પછી ટૂંકી ઍક્સેસ નિષ્ફળતા અનુમાનને બદલે અગવડ બની જાય છે. આખું ડિઝાઇન લક્ષ્ય એ જ છે: કામ તેને માંગનારા જોડાણ કરતાં વધુ જીવવું જોઈએ.