VPN वरून मोठा SQL निकाल: पंक्ती कुठे वाट पाहतात
मोठा SQL निकाल तीन ठिकाणी वाट पाहतो: सर्व्हर बफर, VPN मार्ग आणि क्लायंट. बँडविड्थ बदलण्यापूर्वी किंवा कम्प्रेशन सुरू करण्यापूर्वी प्रत्येक टप्पा मोजा.
क्वेरी मिलिसेकंदांत पूर्ण होऊ शकतात आणि तरीही 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';
मर्यादित कार्यभार चालू असताना काउंटर वाचा, रिकाम्या तासानंतर नाही, कारण एकत्रित काउंटर इन्स्टन्स सुरू झाल्यापासूनचे प्रत्येक सत्र मिसळतात. आयुष्यभराच्या एकूणाऐवजी धावेमधील फरकाची तुलना करा. हस्तांतरणादरम्यान वाढणारा फरक प्रश्न वापर किंवा वितरणापर्यंत आकुंचित करतो.
दोन्ही क्लायंट एकाच घड्याळावर ठेवा
डेटाबेसजवळच्या क्लायंटमधून आणि दूरच्या क्लायंटमधून मर्यादित कार्यभार चालवा. क्वेरी, पॅरामीटर्स, निकालाचा आकार आणि कनेक्शन सेटिंग्ज समान ठेवा. दोन्ही बाजूंनी समान मोजमाप वापरा, कारण सर्व्हर अंमलबजावणीची वेळ, ग्रिड दर्शवण्याची वेळ आणि निर्यातीची वेळ या तीन वेगळी घड्याळे आहेत. सर्व्हर-बाजूच्या संख्येची क्लायंट-बाजूच्या निर्यात टाइमरशी तुलना केल्यास अशी निष्कर्ष मिळतो ज्याची चाचणी करता येत नाही.
मार्ग जबाबदार वाटल्यास, हस्तांतरण चालू असताना त्या विशिष्ट प्रवाहासाठी हानी, पुनर्प्रसारण आणि मिळवलेला थ्रूपुट पाहण्यास नेटवर्क मालकाला सांगा. सामान्य वेग चाचणी दुसरा मार्ग, एंडपॉइंट किंवा समवर्ती नमुना वापरू शकते. लहान यशस्वी विनंती टिकाऊ निकाल हस्तांतरणाबद्दल फार कमी सांगते.
मार्गाला दोष देण्यापूर्वी बाइट कमी करा
फिल्टरिंग, एकत्रीकरण आणि फक्त आवश्यक स्तंभांची निवड हस्तांतरणाचे प्रमाण आणि प्रत्येक पंक्तीसह क्लायंटचे काम दोन्ही कमी करते. इच्छित निकाल जपून ठेवा, कारण अहवालाला स्क्रीनवरील सारांशात नसलेला तपशील लागू शकतो.
पुनरावृत्ती करण्यायोग्य निर्यातीसाठी, डेटाबेसजवळचे मंजूर अंमलबजावणी स्थान परिभाषित आउटपुट लिहू शकते, जे नंतर एकदा वितरित केले जाते. यामुळे कार्यप्रवाह आणि त्याचे प्रवेश नियंत्रण बदलते, आणि सामायिक होस्टवर अमर्यादित डंप सोडण्याची परवानगी नाही.
कम्प्रेशन हा डीफॉल्ट उपाय नाही. समर्थन आणि सुरक्षा प्रत्यक्ष प्रोटोकॉल आणि तैनातीवर अवलंबून असतात, आणि क्लायंट हळू उघडणारा संकुचित प्रवाह अनुभव अधिक बिघडवू शकतो. आधी टप्पा मोजा, नंतर त्या टप्प्यासाठी समर्थित बदल निवडा.