VPN വഴി വലിയ SQL ഫലം: വരികൾ എവിടെ കാത്തിരിക്കുന്നു

ക്വറികൾ മില്ലിസെക്കൻഡുകളിൽ പൂർത്തിയാകാം, എന്നിട്ടും VPN വഴി ലാപ്ടോപ്പിലെത്താൻ മിനിറ്റുകൾ എടുത്തേക്കാം. സർവർ വരികൾ ബഫറുകളിലേക്ക് എഴുതുന്നു, കണക്ഷൻ അവ കൊണ്ടുപോകുന്നു, ക്ലയന്റ് അവ ഉപയോഗിക്കുന്നു, ഈ ഘട്ടങ്ങൾ ക്രമമായി പോകുന്നതിനുപകരം ഒന്നിനുമേൽ ഒന്നായി വരുന്നു. അവയിൽ ഏതും പരിധിയാകാം. ബാൻഡ്വിഡ്ത്ത് മാറ്റുന്നതിനോ കംപ്രഷൻ പ്രവർത്തനക്ഷമമാക്കുന്നതിനോ മുമ്പ് യഥാർത്ഥത്തിൽ കാത്തിരിക്കുന്ന ഘട്ടം കണ്ടെത്തുക.

മൂന്ന് ഘട്ടങ്ങൾ, ഒരു സ്റ്റോപ്പ്വാച്ച്

ടൈമറിനെ വ്യത്യസ്ത അർത്ഥമുള്ള രണ്ട് സംഖ്യകളായി വിഭജിക്കുക: ആദ്യ വരി ലഭ്യമാകുന്ന നിമിഷവും അവസാന വരി ഉപയോഗിച്ചു തീരുന്ന നിമിഷവും. ആദ്യ പേജ് വരയ്ക്കുന്ന ഗ്രിഡ് ക്വറി ആരംഭിച്ചു എന്ന് മാത്രം തെളിയിക്കുന്നു. പൂർണ്ണ ഫലത്തിന്റെ സമയമാണ് ഉപയോക്താവ് എക്സ്പോർട്ട് ചെയ്യുമ്പോഴോ അവസാനം വരെ സ്ക്രോൾ ചെയ്യുമ്പോഴോ അനുഭവിക്കുന്നത്.

ക്വറി ടെക്സ്റ്റ്, പാരാമീറ്ററുകൾ, കണക്ഷൻ ക്രമീകരണങ്ങൾ എന്നിവയ്ക്കൊപ്പം രണ്ട് സംഖ്യകളും രേഖപ്പെടുത്തുക. ആ പശ്ചാത്തലമില്ലാതെ താരതമ്യം രണ്ട് വ്യത്യസ്ത ജോലികൾ തമ്മിലാണ്, രണ്ട് സ്ഥലങ്ങൾ തമ്മിലല്ല.

നെറ്റ്വർക്കിന് മുമ്പ് കാത്തിരിപ്പ് വായിക്കുക

SQL Server ഫലത്തിന്റെ വരികൾ ഔട്ട്പുട്ട് ബഫറുകളിലേക്ക് എഴുതുന്നു, ക്ലയന്റ് അവ എടുക്കുന്നു, പതിയെ ഉപയോഗിക്കുന്ന ക്ലയന്റ് ആ അയയ്ക്കലിൽ സർവറിനെ കാത്തിരിക്കാൻ പ്രേരിപ്പിച്ചേക്കാം. കാത്തിരിപ്പിന്റെ തരം ASYNC_NETWORK_IO ആണ്, കൂടാതെ Microsoftന്റെ പ്രശ്നപരിഹാര കുറിപ്പ് വലിയ ഫലങ്ങളും ക്ലയന്റ് വശത്തെ പ്രോസസ്സിംഗും കാരണങ്ങളിൽ ഉൾപ്പെടുത്തുന്നു. അയയ്ക്കൽ പാത തടഞ്ഞിരിക്കുന്നു എന്ന് കാത്തിരിപ്പ് പറയുന്നു, എന്തുകൊണ്ട് എന്നല്ല.

പതിയെയുള്ള VPN സംഭാവന ചെയ്തേക്കാം, എന്നാൽ ഓരോ വരിയും ഫോർമാറ്റ് ചെയ്യുന്ന, ഫയലിലേക്ക് എഴുതുന്ന, അല്ലെങ്കിൽ ബാച്ചുകൾക്കിടയിൽ നിർത്തുന്ന ക്ലയന്റും സംഭാവന ചെയ്തേക്കാം. കാത്തിരിപ്പിന്റെ പേര് അടുത്ത അളവിലേക്കുള്ള സൂചകമാണ്, ലിങ്കിനെക്കുറിച്ചുള്ള വിധിയല്ല.

SELECT wait_type, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type = 'ASYNC_NETWORK_IO';

നിഷ്ക്രിയ മണിക്കൂറിന് ശേഷമല്ല, പരിമിതമായ വർക്ക്ലോഡ് പ്രവർത്തിക്കുമ്പോൾ കൗണ്ടർ വായിക്കുക, കാരണം സഞ്ചിത കൗണ്ടറുകൾ ഇൻസ്റ്റൻസ് ആരംഭിച്ചതിനുശേഷമുള്ള എല്ലാ സെഷനുകളും കലർത്തുന്നു. ആയുസ്സിലെ ആകെത്തുകയ്ക്കുപകരം ഓട്ടത്തിലുടനീളമുള്ള ഡെൽറ്റ താരതമ്യം ചെയ്യുക. കൈമാറ്റത്തിനിടയിൽ വളരുന്ന ഡെൽറ്റ ചോദ്യത്തെ ഉപഭോഗത്തിലേക്കോ വിതരണത്തിലേക്കോ ചുരുക്കുന്നു.

രണ്ട് ക്ലയന്റുകളെയും ഒരേ ക്ലോക്കിൽ ഇരുത്തുക

ഡാറ്റാബേസിന് അടുത്തുള്ള ക്ലയന്റിൽ നിന്നും ദൂരെയുള്ള ക്ലയന്റിൽ നിന്നും പരിമിതമായ വർക്ക്ലോഡ് പ്രവർത്തിപ്പിക്കുക. ക്വറി, പാരാമീറ്ററുകൾ, ഫലത്തിന്റെ വലിപ്പം, കണക്ഷൻ ക്രമീകരണങ്ങൾ എന്നിവ സമാനമായി നിലനിർത്തുക. ഇരുവശത്തും ഒരേ അളവ് ഉപയോഗിക്കുക, കാരണം സർവർ എക്സിക്യൂഷൻ സമയം, ഗ്രിഡ് പ്രദർശന സമയം, എക്സ്പോർട്ട് സമയം എന്നിവ മൂന്ന് വ്യത്യസ്ത ക്ലോക്കുകളാണ്. സർവർ വശത്തെ സംഖ്യയെ ക്ലയന്റ് വശത്തെ എക്സ്പോർട്ട് ടൈമറുമായി താരതമ്യം ചെയ്യുന്നത് പരിശോധിക്കാനാകാത്ത ഒരു നിഗമനം നൽകുന്നു.

പാത ഉത്തരവാദിയാണെന്ന് തോന്നുമ്പോൾ, കൈമാറ്റം നടക്കുമ്പോൾ ആ നിർദ്ദിഷ്ട ഫ്ലോയ്ക്കുള്ള നഷ്ടം, പുനഃപ്രേഷണം, നേടിയ ത്രൂപുട്ട് എന്നിവ നിരീക്ഷിക്കാൻ നെറ്റ്വർക്ക് ഉടമയോട് ആവശ്യപ്പെടുക. സാധാരണ വേഗതാ പരിശോധന മറ്റൊരു റൂട്ട്, എൻഡ്പോയിന്റ് അല്ലെങ്കിൽ സമാന്തരതാ മാതൃക ഉപയോഗിച്ചേക്കാം. ചെറിയ വിജയകരമായ അഭ്യർത്ഥന തുടർച്ചയായ ഫല കൈമാറ്റത്തെക്കുറിച്ച് കുറച്ച് മാത്രം പറയുന്നു.

പാതയെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ബൈറ്റുകൾ കുറയ്ക്കുക

ഫിൽട്ടറിംഗ്, അഗ്രിഗേഷൻ, ആവശ്യമായ കോളങ്ങൾ മാത്രം തിരഞ്ഞെടുക്കൽ എന്നിവ കൈമാറ്റത്തിന്റെ അളവും ഓരോ വരിയിലും ക്ലയന്റ് ചെയ്യുന്ന ജോലിയും കുറയ്ക്കുന്നു. ഉദ്ദേശിച്ച ഫലം സംരക്ഷിക്കുക, കാരണം സ്ക്രീനിലെ സംഗ്രഹത്തിൽ ഇല്ലാത്ത വിശദാംശം റിപ്പോർട്ടിന് ആവശ്യമായി വന്നേക്കാം.

ആവർത്തിക്കാവുന്ന എക്സ്പോർട്ടുകൾക്ക്, ഡാറ്റാബേസിന് അടുത്തുള്ള അംഗീകൃത എക്സിക്യൂഷൻ സ്ഥലം നിർവചിച്ച ഔട്ട്പുട്ട് എഴുതാം, അത് പിന്നീട് ഒരിക്കൽ എത്തിക്കുന്നു. അത് വർക്ക്ഫ്ലോയും അതിന്റെ ആക്സസ് നിയന്ത്രണങ്ങളും മാറ്റുന്നു, പങ്കിട്ട ഹോസ്റ്റിൽ പരിധിയില്ലാത്ത ഡംപ് വിടാൻ ഇത് അനുമതിയല്ല.

കംപ്രഷൻ സ്വതവേയുള്ള പരിഹാരമല്ല. പിന്തുണയും സുരക്ഷയും യഥാർത്ഥ പ്രോട്ടോക്കോളിനെയും വിന്യാസത്തെയും ആശ്രയിച്ചിരിക്കുന്നു, ക്ലയന്റ് പതിയെ തുറക്കുന്ന കംപ്രസ് ചെയ്ത സ്ട്രീം അനുഭവം കൂടുതൽ മോശമാക്കാം. ആദ്യം ഘട്ടം അളക്കുക, തുടർന്ന് ആ ഘട്ടത്തിന് പിന്തുണയുള്ള മാറ്റം തിരഞ്ഞെടുക്കുക.