क्या MS SQL Server में नेटवर्क लेटेंसी के कारण टेबल लॉक बढ़ेंगे?

यदि मैं एक उच्च-विलंबता नेटवर्क पर SQL सर्वर डेटाबेस के लिए एकल कॉल कर रहा हूं, तो क्या उस विलंबता के कारण टेबल लॉक हो सकते हैं? कुछ रिकॉर्ड्स के लिए I तालिका तालिका A कहो, और SQL सर्वर को एक धीमे नेटवर्क पर डेटा वापस करना होगा - क्या तालिका A पर रीड लॉक होगा जब सर्वर नेटवर्क पर प्रतिक्रिया भेजता है, या SQL सर्वर भेजने से पहले लॉक जारी करता है प्रतिक्रिया?

इसके अलावा, क्या उत्तर प्रतिक्रिया के आकार के आधार पर भिन्न होगा? अगर यह सिर्फ कुछ केबी बनाम कई सौ एमबी वापस करना है, तो क्या इससे कोई फर्क पड़ेगा?

एक स्पष्ट लेन-देन बनाना, प्रश्नों को चलाना, और लेन-देन को बंद करना स्पष्ट रूप से तालिकाओं को लॉक करने का कारण होगा, क्योंकि लेन-देन की अवधि मेरे विलंबता के साथ सहसंबद्ध है।

sql-server locking network

— इवान एम
स्रोत

जब तक आप एक nolockसंकेत निर्दिष्ट नहीं करते, तब तक हमेशा एक ताला रहेगा । विलंबता केवल यह निर्धारित करती है कि ताला कितने समय तक आयोजित किया जाएगा।

— ब्रैंडन

और यहां तक कि nolock, आपको अभी भी ताले

— मिलेंगे

क्या @ Microsoft कहीं भी Microsoft द्वारा प्रलेखित है? मेरी खोज खाली हो गई है।

— इवान एम।

@ ब्रैंडन नोलक का मतलब यह नहीं है कि आप क्या सोचते हैं।

— हारून बर्ट्रेंड

@ ब्रेंडन Unless you specify a nolock hint, there will always be a lock.<- इसका मतलब है कि यदि आप नोलॉक का उपयोग करते हैं तो ताले नहीं हो सकते हैं। मैं केवल स्पष्ट कर रहा था।

— हारून बर्ट्रेंड

जवाबों:

यदि क्लाइंट को डेटा प्राप्त करने में लंबा समय लगता है और बदले में SQL सर्वर को पावती भेजती है कि उसे डेटा प्राप्त होता है तो SQL सर्वर को इंतजार करना पड़ता है, इस प्रतीक्षा के कारण SQL सर्वर क्वेरी द्वारा रखे गए लॉक को तब तक जारी नहीं करेगा जब तक क्लाइंट से पावती प्राप्त नहीं हो जाती।

यह सटीक नहीं है, यह अलगाव स्तर पर निर्भर है।

डिफ़ॉल्ट READ COMMITTEDलॉक स्टेटमेंट निष्पादन की अवधि के लिए आयोजित नहीं किए जाते हैं। READ COMMITTEDस्टेटमेंट लेवल रीड सुसंगतता प्रदान नहीं करता है, केवल ग्वारेंटी यह है कि आप बिना पढ़े डेटा नहीं पढ़ सकते हैं। साझा लॉक को पंक्ति पढ़ने के लिए अधिग्रहित किया जाता है और फिर जारी किया जाता है।

जब तक आपके पास LOB प्रकार न हों।

LOB प्रकार, संभावित रूप से बहुत बड़े होने के कारण बफ़र नहीं किया जा सकता है। एक साझा ताला प्राप्त किया जाना चाहिए और तब तक आयोजित किया जाना चाहिए जब तक कि बयान पूरा न हो जाए, अनिवार्य रूप से आपको REPEATABLE READव्यवहार दे रहा है READ COMMITTED।

यदि मैं एक उच्च-विलंबता नेटवर्क पर MSSQL डेटाबेस के लिए एक कॉल कर रहा हूं, तो क्या उस विलंबता के कारण टेबल लॉक हो सकते हैं?

विलंबता तालिका लॉक का कारण नहीं है, नहीं। हालाँकि, यदि एक टेबल लॉक को अधिग्रहित किया गया है, तो विलंबता इसे लम्बा करने जा रही है।

किसी को उद्धृत करने के लिए जो इससे बेहतर यांत्रिकी को जानता है I ( @RemusRusanu ):

निष्पादन के परिणाम के रूप में परिणाम क्लाइंट प्रोग्राम में वापस आ जाते हैं। निष्पादन पेड़ पर पंक्तियों के रूप में 'बबल' के रूप में, शीर्ष ऑपरेटर को आमतौर पर नेटवर्क बफ़र्स में इन पंक्तियों को लिखने और उन्हें क्लाइंट को वापस भेजने का काम सौंपा जाता है। परिणाम पहले कुछ इंटरमीडिएट स्टोरेज (मेमोरी या डिस्क) में नहीं बनाया जाता है और फिर क्लाइंट को वापस भेज दिया जाता है, बजाय इसे वापस भेजा जाता है जैसा कि बनाया जा रहा है (जैसा कि क्वेरी निष्पादित होता है)। परिणाम को क्लाइंट को वापस भेजना, ज़ाहिर है, नेटवर्क प्रवाह नियंत्रण प्रोटोकॉल के अधीन है। यदि क्लाइंट सक्रिय रूप से परिणाम का उपभोग नहीं कर रहा है (उदाहरण के लिए SqlDataReader.Read। क्वेरी।[स्रोत]

जहां परिणाम SQL सर्वर के रूप में जल्दी से उपभोग नहीं किया जा सकता है, यह ग्राहक या नेटवर्क के कारण हो सकता है, हम ASYNC_NETWORK_IOइंतजार कर रहे हैं जमा हो रही है। दोहराने के लिए, यह उन तालों को प्रभावित नहीं करेगा जिन्हें अधिग्रहित किया गया है, बस वे जिस अवधि में हैं।

— मार्क स्टोरी-स्मिथ
स्रोत

मार्क के उत्तर ने मेरे भ्रम को काफी हद तक दूर कर दिया, लेकिन लेटलतीफी का अनुकरण करने के लिए नेटबालकैंसर का उपयोग करने के बाद मैंने अपने निष्कर्षों को पोस्ट करना चाहा।

मेरे पास मेरी स्थानीय मशीन एक दूरस्थ SQL सर्वर कॉल थी और एक छोटे से लेनदेन के भीतर एक मेज पर दोनों चयन और INSERTs निष्पादित करें। रिमोट मशीन पर, मैं स्थानीय एसक्यूएल उदाहरण से जुड़ा था और एक बार फिर से sysinos_tran_locks तालिका पर पुनरावृति करने के लिए एक WHILE लूप का उपयोग किया, जिस तालिका को मैं संशोधित और पढ़ रहा था, उस पर किसी भी ताले की तलाश थी। मैंने सर्वर पर NetBalancer स्थापित किया और सर्वर के नेटवर्क कनेक्शन पर नेटवर्क विलंबता का अनुकरण करने के लिए इसका उपयोग किया।

यहाँ मैं क्या पाया:

क्लाइंट के लिए बहुत अधिक डेटा वापस नहीं करने वाले बयानों के लिए, विलंबता को लॉक करने पर कोई प्रभाव नहीं पड़ता है। मैं केवल अधिकांश डेटा के कुछ सौ बाइट्स लौटा रहा था। मेरी मशीन पर लेनदेन में एक 250ms WAITFOR था, जिसमें ताले लगे रहते थे, और जब मैंने नेटवर्क विलंबता को 5000ms तक बढ़ाया तो लॉक अवधि 250ms के करीब रही।
बहुत सारे डेटा लौटाने वाले कथनों के लिए, विलंबता निश्चित रूप से लॉकिंग को प्रभावित करती है, मैंने क्लाइंट को दसियों हज़ार पंक्तियाँ वापस लौटा दीं और कोई विलंबता के साथ, लॉक की अवधि कम थी। जब मैंने विलंबता को बढ़ाया, तब तक ताले जारी रहे जब तक कि मुझे सभी डेटा प्राप्त नहीं हुआ।

इससे, मैं यह निष्कर्ष निकाल रहा हूं कि जब तक नेटवर्क बफ़र में डेटा फिट बैठता है तब तक विलंबता कोई मायने नहीं रखती। यदि SQL को नेटवर्क बफ़र में बहुत अधिक डेटा डालना है, तो विलंबता उस बफ़र को बैकअप देने का कारण बनेगी और SQL टेबल लॉक को तब तक दबाए रखेगा, जब तक कि वह क्वेरी परिणाम के सभी बफ़र को नहीं डाल सकता।

— इवान एम
स्रोत

दिलचस्प परिणाम। यह किस क्लाइंट प्रोग्राम / लाइब्रेरी के साथ है?

— जेम्स एल

अच्छी चीज़। कोई भी मौका आप इस पर थोड़ा और समय बिता सकते हैं और देख सकते हैं कि क्या आप परिणाम का आकार निर्धारित कर सकते हैं जिस पर यह होता है?

— मार्क स्टोरी-स्मिथ

@ MarkStorey-Smith मुझे नहीं लगता कि मुझे एक सटीक मूल्य मिल सकता है, और यह निस्संदेह मशीन द्वारा भिन्न होगा। से vircom.com/security/improve-sql-nic-performance , ऐसा लगता है कि यह अपने स्थानीय एनआईसी पर एक सेटिंग है, और मेरी डेटाबेस सर्वर पर एक 'ऑटो' के लिए स्थापित किया गया था की तरह

— इवान एम

@ जेम्स मैं सिर्फ दोनों मशीनों पर एसएसएमएस का उपयोग करता था

— इवान एम

यदि मैं एक उच्च-विलंबता नेटवर्क पर MSSQL डेटाबेस के लिए एक कॉल कर रहा हूं, तो क्या उस विलंबता के कारण टेबल लॉक हो सकते हैं?

जब SQL सर्वर द्वारा किसी क्वेरी को निकाल दिया और पूरा कर लिया जाता है, तो यह परिणाम उत्पन्न करता है, इसे आउटपुट बफर में रखें और इसे क्लाइंट को भेजें, जो तब आउटपुट बफर से परिणाम प्राप्त करता है। SQL सर्वर क्वेरी द्वारा रखे गए ताले को तब तक जारी नहीं करेगा जब तक कि क्लाइंट से पावती प्राप्त न हो। जिसके कारण अवरोध हो सकता है।

संपादित करें: इवान आप इस एमएस समर्थन लेख का उल्लेख कर सकते हैं

धारा 3 में

एक SPID जिसे ग्राहक अनुप्रयोग के द्वारा अवरुद्ध के कारण पूरा करने के लिए सभी परिणाम पंक्तियों को प्राप्त नहीं हुआ

सर्वर को एक प्रश्न भेजने के बाद, सभी अनुप्रयोगों को तुरंत सभी परिणामी पंक्तियों को पूरा करना होगा। यदि कोई एप्लिकेशन सभी परिणाम पंक्तियों को नहीं लाती है, तो अन्य उपयोगकर्ताओं को अवरुद्ध करते हुए, तालिकाओं पर ताले छोड़ दिए जा सकते हैं। यदि आप किसी ऐसे अनुप्रयोग का उपयोग कर रहे हैं जो पारदर्शी रूप से SQL कथनों को सर्वर में जमा करता है, तो अनुप्रयोग को सभी परिणामी पंक्तियों को लाना होगा। यदि ऐसा नहीं है (और यदि ऐसा करने के लिए इसे कॉन्फ़िगर नहीं किया जा सकता है), तो आप अवरुद्ध समस्या को हल करने में असमर्थ हो सकते हैं। समस्या से बचने के लिए, आप खराब व्यवहार वाले अनुप्रयोगों को रिपोर्टिंग या निर्णय-समर्थन डेटाबेस तक सीमित कर सकते हैं।

— Shanky
स्रोत

आपके जवाब के लिए धन्यवाद Shanky! क्या आपको पता है कि यह कहीं भी प्रलेखित है?

— इवान एम।

डेटाबेस इंजन में लॉक करना

यह सही नहीं है।

— मार्क स्टोरी-स्मिथ

यह सही है ऐसा लगता है कि 'आवेदन सभी परिणाम पंक्तियों को नहीं लाता है, तालिकाओं को अन्य उपयोगकर्ताओं को अवरुद्ध करते हुए, तालिकाओं पर छोड़ दिया जा सकता है। यदि आप किसी ऐसे अनुप्रयोग का उपयोग कर रहे हैं जो पारदर्शी रूप से SQL कथनों को सर्वर में जमा करता है, तो अनुप्रयोग को सभी परिणामी पंक्तियों को लाना होगा। यदि ऐसा नहीं है (और यदि ऐसा करने के लिए इसे कॉन्फ़िगर नहीं किया जा सकता है), तो आप अवरुद्ध समस्या को हल करने में असमर्थ हो सकते हैं। समस्या से बचने के लिए, आप खराब व्यवहार वाले अनुप्रयोगों को रिपोर्टिंग या निर्णय-समर्थन डेटाबेस तक सीमित कर सकते हैं। ' अधिक मैं सामान्य शब्दों में बात कर रहा था। आप यहाँ से पढ़ सकते हैं support2.microsoft.com/kb/224453

— Shanky

@ शैंकी एक बड़ी तालिका बनाएँ। SELECT *इसमें से READ COMMITTEDएक SSMS कनेक्शन में, दूसरे से ताले की निगरानी करें। किसी भी समय, आप कितने ताले आयोजित करते हैं?

— मार्क स्टोरी-स्मिथ