നീണ്ട 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';

ചരിത്രം ഓരോ ഘട്ടത്തിന്റെയും ഫലവും സമയവും കാണിക്കുന്നു, ഇത് ഒരു വിജയ കൊടിയേക്കാൾ ഉപയോഗപ്രദമാണ്. ഡാറ്റ മാറ്റുന്ന ജോലികൾക്ക് ആപ്ലിക്കേഷന്റെ സ്വന്തം പരിശോധനയും ചേർക്കുക: വരികളുടെ എണ്ണം, ചെക്ക്സം അല്ലെങ്കിൽ ജോലി എഴുതുന്ന സ്റ്റാറ്റസ് വരി. രണ്ട് സ്വതന്ത്ര രേഖകളാണ് വീണ്ടും ശ്രമിക്കുന്നത് സുരക്ഷിതമാക്കുന്നത്, രേഖപ്പെടുത്തിയ ജോലി ചരിത്രം അവയിൽ ആദ്യത്തേതാണ്.

വീണ്ടും സമർപ്പിക്കുന്നതിന് മുമ്പ് ഒത്തുനോക്കുക

നിരീക്ഷണ കണക്ഷൻ അപ്രത്യക്ഷമാകുമ്പോൾ, മറ്റൊന്ന് തുടങ്ങുന്നതിന് മുമ്പ് നിലവിലുള്ള റൺ കണ്ടെത്തുക. അതിന്റെ ഘട്ടങ്ങളുടെ ഫലങ്ങൾ വായിച്ച് ജോലി കമ്മിറ്റ് ചെയ്തോ, ഭാഗികമായി പൂർത്തിയായോ, ഒരിക്കലും തുടങ്ങിയില്ലയോ എന്ന് തീരുമാനിക്കുക. അപ്പോൾ മാത്രം വർക്ക്ഫ്ലോ നിർവചിക്കുന്ന വീണ്ടും ശ്രമിക്കാനുള്ള നിയമം പ്രയോഗിക്കുക, കാരണം കണ്ണുമടച്ച് വീണ്ടും സമർപ്പിക്കുന്നത് ലോഡ് ഇരട്ടിയാക്കാം അല്ലെങ്കിൽ രണ്ടാം തവണ പകുതിയിൽ പരാജയപ്പെടാം.

സ്ഥിരമായ ഉടമയും പരിശോധിക്കാനാകുന്ന ഫലവും നിലനിർത്തുക, അപ്പോൾ ചെറിയ ആക്സസ് പരാജയം ഊഹമല്ലാതെ ബുദ്ധിമുട്ടായി മാറുന്നു. അതാണ് മുഴുവൻ ഡിസൈൻ ലക്ഷ്യം: ജോലി അത് ആവശ്യപ്പെട്ട കണക്ഷനെക്കാൾ കൂടുതൽ കാലം ജീവിക്കണം.