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';

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

બંને ક્લાયંટને એક જ ઘડિયાળ પર મૂકો

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

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

માર્ગને દોષ આપતા પહેલાં બાઇટ ઘટાડો

ફિલ્ટરિંગ, એગ્રિગેશન અને ફક્ત જરૂરી કૉલમ પસંદ કરવાથી ટ્રાન્સફરનું પ્રમાણ અને દરેક પંક્તિ સાથે ક્લાયંટનું કામ બંને ઘટે છે. ઇચ્છિત પરિણામ જાળવો, કારણ કે રિપોર્ટને એવી વિગતની જરૂર પડી શકે જે સ્ક્રીન પરના સારાંશમાં નથી.

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

કમ્પ્રેશન ડિફોલ્ટ ઉપાય નથી. સપોર્ટ અને સુરક્ષા વાસ્તવિક પ્રોટોકોલ અને ડિપ્લોયમેન્ટ પર આધાર રાખે છે, અને ક્લાયંટ ધીમે ખોલતો સંકોચાયેલો પ્રવાહ અનુભવને વધુ ખરાબ કરી શકે છે. પહેલાં તબક્કો માપો, પછી તે તબક્કા માટે સમર્થિત ફેરફાર પસંદ કરો.