SQL सर्वर में "(nolock)" के साथ क्या है?

610

क्या कोई with (nolock)प्रश्नों पर उपयोग करने के निहितार्थ की व्याख्या कर सकता है , जब आपको इसका उपयोग करना चाहिए / नहीं करना चाहिए?

उदाहरण के लिए, यदि आपके पास उच्च लेनदेन दरों और कुछ निश्चित तालिकाओं में बहुत सारे डेटा के साथ एक बैंकिंग एप्लिकेशन है, तो किस प्रकार के प्रश्नों को ठीक किया जाएगा? क्या ऐसे मामले हैं जब आपको हमेशा इसका उपयोग करना चाहिए / कभी इसका उपयोग नहीं करना चाहिए?

sql-server nolock

— एंडी व्हाइट
स्रोत

मैं में subquestioned stackoverflow.com/questions/3836282/... और stackoverflow.com/questions/3836032/... ज्यादातर जोनाथन एलन की जवाब stackoverflow.com/questions/686724/...

— गेनाडी Vanin Геннадий Ванин

1

यहाँ एक लिंक - mssqltips.com/sqlservertip/2470/…

— स्टीम

1

यहाँ NOLOCK ब्लॉगs.msdn.com/b/davidlean/archive/2009/04/06/…

— ब्रायन

461

के साथ (NOLOCK) एक लेनदेन अलगाव स्तर के रूप में READ UNCOMMITED का उपयोग करने के बराबर है। इसलिए, आप एक अनकम्फर्टेड पंक्ति को पढ़ने का जोखिम उठाते हैं, जिसे बाद में वापस रोल किया जाता है, यानी डेटा जो इसे डेटाबेस में कभी नहीं बनाता है। इसलिए, जबकि यह रीड को अन्य ऑपरेशनों के गतिरोध से बचा सकता है, यह जोखिम के साथ आता है। उच्च लेन-देन दरों के साथ एक बैंकिंग एप्लिकेशन में, शायद यह जो भी समस्या है उसे आईएमएचओ के साथ हल करने का सही समाधान नहीं हो सकता है।

— डेविड एम
स्रोत

156

अधिकांश बैंकिंग एप्लिकेशन सुरक्षित रूप से नोलॉक का उपयोग कर सकते हैं क्योंकि वे व्यावसायिक अर्थों में लेन-देन कर रहे हैं। आप केवल नई पंक्तियाँ लिखते हैं, आप उन्हें कभी अपडेट नहीं करते हैं।

— जोनाथन एलन

49

@ ग्रुएनवॉल्फ- एक सम्मिलित लेकिन अप्रकाशित पंक्ति अभी भी गंदे रीड्स को जन्म दे सकती है।

— सासमान

16

@ सासमान- अगर आपने कभी लेन-देन नहीं किया है, तो कोई बात नहीं। और केवल-सम्मिलित तालिका के साथ, रोलबैक की संभावना किसी से भी पतली नहीं है। और अगर वे होते हैं, तो आप अभी भी दिन के विचरण की रिपोर्ट के अंत में इसे ठीक कर देंगे।

— जोनाथन एलन

1

मैं उलझ गया हूं। मुझे लगता है पर जोड़ा गया कोई ताला संकेत नहीं है। एग्जम्प के लिए:

— रॉस बुश

11

यदि आप अपने NOLOCKसाथ उपयोग करते हैं, तो एक SELECTही पंक्तियों को एक से अधिक बार (डुप्लिकेट किए गए डेटा) वापस करने का जोखिम होता है, यदि चयन करते समय डेटा कभी भी तालिका में डाला जाता है (या अपडेट किया जाता है)।

— इयान बॉयड

170

सवाल यह है कि क्या बदतर है:

एक गतिरोध, या
एक गलत मूल्य

वित्तीय डेटाबेस के लिए, डेडलॉक गलत मूल्यों से कहीं अधिक खराब हैं। मुझे पता है कि पीछे से लगता है, लेकिन मुझे सुन लो। DB लेन-देन का पारंपरिक उदाहरण है कि आप दो पंक्तियों को अपडेट करते हैं, एक से घटाना और दूसरे को जोड़ना। यह गलत है।

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

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

एसक्यूएल सर्वर 2005 ने कहा कि अधिकांश बग्स को NOLOCKजरूरी बना दिया । इसलिए जब तक आप SQL Server 2000 या उससे पहले का उपयोग नहीं कर रहे हैं, आपको इसकी आवश्यकता नहीं है।

इसके अलावा पढ़ना
पंक्ति-स्तरीय संस्करण

— जोनाथन एलन
स्रोत

22

अस्थायी रूप से गलत तरीके से खाता शेष प्राप्त करना कोई बड़ी बात नहीं है? क्या होगा यदि वह लेनदेन वह है जहां आप बिना किसी ओवरड्राफ्ट सीमा के एटीएम से नकदी निकाल रहे हैं?

— लर्निंग

13

@ लर्निंग: यदि आप किसी को अपना कार्ड चार्ज करने से 30 सेकंड पहले पैसे निकाल लेते हैं तो क्या होगा? जब तक सभी संचार तुरत अस्थिर नहीं हो जाते, तब तक ओवरड्राफ्ट जीवन का एक तथ्य होगा।

— जोनाथन एलन

6

+1 वित्तीय ऐप में (हर जगह, केवल बैंकों में), न तो अपडेट हैं और न ही डिलीट। रिकॉर्ड डालने से भी गलत संचालन सही हो जाता है। यह शब्द अंग्रेजी में क्या है? क्या यह "स्टर्नो" है? Google ने इस सवाल का जवाब देने में मेरी मदद नहीं की

— Gennady Vanin Геннадий Ванин

7

देर से प्रवेश ... गतिरोधों को पकड़ा जाना चाहिए और पीछे हट जाना चाहिए। डर्टी

— रीड्स के

4

@JonathanAllen सिर्फ एक फ़िजी है, यह शब्द यूपी का है, यूपी का नहीं।

— जिमी डी

57

दुर्भाग्य से यह बिना पढ़े डेटा को पढ़ने के बारे में नहीं है। पृष्ठभूमि में आप दो बार पृष्ठ पढ़ना (पृष्ठ विभाजन के मामले में) समाप्त कर सकते हैं, या आप पृष्ठों को पूरी तरह से याद कर सकते हैं। तो आपके परिणाम काफी कम हो सकते हैं।

की जाँच करें Itzik बेन-गण के लेख । यहाँ एक अंश है:

"NOLOCK संकेत के साथ (या सत्र के अलग-अलग स्तर को पढ़ने के लिए सेट करें) आप SQL सर्वर से कहते हैं कि आप निरंतरता की उम्मीद नहीं करते हैं, इसलिए कोई गारंटी नहीं है। ध्यान रखें कि" असंगत डेटा "का मतलब केवल यह नहीं है। हो सकता है कि आप बिना पढ़े हुए परिवर्तन देखें, जिन्हें बाद में वापस ले लिया गया था, या लेन-देन की मध्यवर्ती स्थिति में डेटा में परिवर्तन हुआ था। इसका मतलब यह भी है कि एक साधारण क्वेरी में जो सभी टेबल / इंडेक्स डेटा को स्कैन करता है SQL सर्वर स्कैन की स्थिति खो सकता है, या आप समाप्त हो सकते हैं दो बार एक ही पंक्ति हो रही है । "

— sqlbelle
स्रोत

5

थोड़ा और नीचे वह बताता है कि एक ही पंक्ति को दो बार कैसे प्राप्त करें: मैं तालिका T1 को फिर से बनाऊंगा जैसे कि col1 पर संकुल सूचकांक IGNORE_DUP_KEY विकल्प के साथ एक अद्वितीय सूचकांक के रूप में परिभाषित किया जाएगा। इसका मतलब यह है कि डुप्लिकेट मान col1 में मौजूद नहीं हो सकते हैं, और यह भी कि डुप्लिकेट कुंजी सम्मिलित करने का प्रयास लेनदेन को विफल नहीं करेगा और केवल एक चेतावनी उत्पन्न करने के लिए त्रुटि उत्पन्न करेगा। यदि आप इस अजीब विकल्प का उपयोग नहीं करते हैं, तो आपको दो बार पंक्तियों के बारे में चिंता करने की ज़रूरत नहीं है

— JanHudecek

आप अभी भी वायर्ड विकल्प के बिना भी डुबकी पंक्तियाँ प्राप्त कर सकते हैं - यदि आपकी क्वेरी एक सूचकांक का लाभ उठाती है जो उदाहरण के लिए अद्वितीय नहीं है। यह नोलॉक के लिए अद्वितीय नहीं है, हालांकि।

— RMD

54

नोलॉक संकेत के वैध उपयोग के लिए पाठ्य पुस्तक का उदाहरण उच्च अद्यतन ओएलटीपी डेटाबेस के खिलाफ रिपोर्ट नमूनाकरण है।

एक सामयिक उदाहरण लेने के लिए। यदि एक बड़े अमेरिकी उच्च सड़क बैंक ने शहर पर चलने वाले शहर के स्तर के पहले संकेतों की तलाश में प्रति घंटा रिपोर्ट चलाना चाहते थे, तो एक नोलॉक क्वेरी नकद जमा और प्रति शहर नकद निकासी के लेनदेन लेनदेन को स्कैन कर सकती थी। इस तरह की रिपोर्ट के लिए रोल बैक अपडेट लेनदेन के कारण होने वाली त्रुटि का छोटा प्रतिशत रिपोर्ट के मूल्य को कम नहीं करेगा।

— saasman
स्रोत

31

यह सुनिश्चित नहीं करें कि आप डेटाबेस लेनदेन में वित्तीय लेनदेन को क्यों नहीं लपेट रहे हैं (जैसे कि जब आप एक खाते से दूसरे खाते में धनराशि स्थानांतरित करते हैं - आप एक बार में लेनदेन का एक पक्ष नहीं करते हैं - यही कारण है कि स्पष्ट लेनदेन मौजूद हैं)। यहां तक कि अगर आपका कोड व्यावसायिक लेनदेन के लिए बाध्य है जैसा कि यह लगता है, तो सभी लेनदेन डेटाबेस में त्रुटियों या विफलता की स्थिति में निहित रोलबैक करने की क्षमता है। मुझे लगता है कि यह चर्चा आपके सिर पर है।

यदि आपको लॉकिंग की समस्या हो रही है, तो संस्करण को लागू करें और अपने कोड को साफ़ करें।

कोई भी ताला न केवल गलत मान लौटाता है, यह प्रेत रिकॉर्ड और डुप्लिकेट देता है।

यह एक आम गलत धारणा है कि यह हमेशा प्रश्नों को तेजी से चलाता है। अगर किसी टेबल पर राइट लॉक नहीं हैं, तो इससे कोई फर्क नहीं पड़ता। यदि मेज पर ताले हैं, तो यह क्वेरी को तेज कर सकता है, लेकिन एक कारण है कि ताले को पहले स्थान पर आविष्कार किया गया था।

निष्पक्षता में, यहां दो विशेष परिदृश्य हैं जहां एक नोलॉक संकेत उपयोगिता प्रदान कर सकता है

1) 2005 से पहले के SQL सर्वर डेटाबेस को लाइव OLTP डेटाबेस के खिलाफ लंबी क्वेरी चलाने की आवश्यकता है यह एकमात्र तरीका हो सकता है

2) खराब लिखित आवेदन जो यूआई और पाठकों के लिए रिकॉर्ड्स और रिटर्न नियंत्रण को अनिश्चित काल के लिए बंद कर देता है। अगर आवेदन (थर्ड पार्टी आदि) तय नहीं किया जा सकता है तो नोलॉक यहां मददगार हो सकता है और डेटाबेस या तो 2005 से पहले का है या वर्जनिंग को चालू नहीं किया जा सकता है।

— एंड्रयू
स्रोत

11

मैं आपसे सहमत हूं कि खराब लिखित कोड के लिए NOLOCK का उपयोग नहीं किया जाना चाहिए। हालाँकि, मुझे लगता है कि जॉनथन का आपका हमला अनुचित है क्योंकि उसने कभी भी डेटाबेस लेनदेन का उल्लेख नहीं किया है । वह केवल इशारा कर रहा था कि वित्तीय अनुप्रयोग आम तौर पर संपादन को रिकॉर्ड करने की अनुमति नहीं देते हैं (जाहिर है कि कुछ अपवाद हैं)। आपके फंड ट्रांसफर उदाहरण में, वह कह रहा है कि यदि आप डेबिट / क्रेडिट प्रविष्टि को किसी प्रकार के लेज़र में जोड़ने के बजाय खाते के शेष के मूल्य को बदलना चाहते हैं, तो यह अजीब होगा ।

— चर्नोला

19

जब विभिन्न बैंकों में धन एक खाते से दूसरे खाते में स्थानांतरित किया जाता है तो आपको क्या लगता है? कुछ uber-database बैंक ऑफ अमेरिका में एक मेज पर ताला लगाता है और दूसरा वेल्स फारगो में? नहीं, एक वित्तीय लेन-देन प्रत्येक को लिखा जाता है और फिर एक दिन के अंत की प्रक्रिया की पुष्टि होती है जो सभी रिकॉर्ड से मेल खाती है।

— जोनाथन एलन

24

NOLOCKके समतुल्य है READ UNCOMMITTED, हालाँकि Microsoft कहता है कि आपको इसका उपयोग UPDATEया DELETEकथन के लिए नहीं करना चाहिए :

UPDATE या DELETE कथनों के लिए: यह सुविधा Microsoft SQL सर्वर के भविष्य के संस्करण में हटा दी जाएगी। नए विकास कार्य में इस सुविधा का उपयोग करने से बचें, और वर्तमान में इस सुविधा का उपयोग करने वाले अनुप्रयोगों को संशोधित करने की योजना बनाएं।

http://msdn.microsoft.com/en-us/library/ms187373.aspx

यह आलेख SQL सर्वर 2005 पर लागू होता है, इसलिए NOLOCKयदि आप उस संस्करण का उपयोग कर रहे हैं तो इसके लिए समर्थन मौजूद है। भविष्य के प्रमाण के लिए आप कोड (यह मानकर कि आपने गंदे रीड्स का उपयोग करने का फैसला किया है) आप इसे अपनी संग्रहीत प्रक्रियाओं में उपयोग कर सकते हैं:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

— Seibar
स्रोत

21

आप इसका उपयोग तब कर सकते हैं जब आप केवल डेटा पढ़ रहे हों, और आप वास्तव में इस बात की परवाह नहीं करते हैं कि आपको ऐसा डेटा वापस मिल सकता है या नहीं जो अभी तक प्रतिबद्ध नहीं है।

यह एक रीड ऑपरेशन पर तेज़ हो सकता है, लेकिन मैं वास्तव में कितना नहीं कह सकता।

सामान्य तौर पर, मैं इसका उपयोग करने के खिलाफ सलाह देता हूं - बिना डेटा को पढ़ना सर्वोत्तम में थोड़ा भ्रमित हो सकता है।

— marc_s
स्रोत

1

यह अच्छा होगा यदि आप इस तथ्य का उल्लेख करते हैं कि एसक्यूएल सर्वर 2005 में पंक्ति संस्करण है तो नोलक्स को किसी भी अधिक आवश्यकता नहीं है।

— जोनाथन एलन

ठीक है, "के साथ (नोलॉक)" अभी भी SQL सर्वर 2005 में अपनी जगह है - लेकिन लाभ स्लिमर और स्लिमर हो रहे हैं, यह सच है।

— marc_s

18

एक अन्य मामला जहां यह आम तौर पर ठीक है एक रिपोर्टिंग डेटाबेस में है, जहां डेटा शायद पहले से ही पुराना है और लिखता है बस नहीं होता है। इस मामले में, हालांकि, डिफॉल्ट अलगाव स्तर को बदलकर विकल्प को डेटाबेस या टेबल स्तर पर सेट किया जाना चाहिए।

सामान्य स्थिति में: आप इसका इस्तेमाल कर सकते हैं जब आप कर रहे हैं बहुत यकीन है कि यह पुराने डेटा को पढ़ने के लिए ठीक है। याद रखने वाली महत्वपूर्ण बात यह है कि उस गलत को प्राप्त करना बहुत आसान है । उदाहरण के लिए, भले ही आप क्वेरी लिखते समय ठीक हो, लेकिन क्या आप सुनिश्चित हैं कि भविष्य में डेटाबेस में कुछ बदलाव नहीं होंगे ताकि ये अपडेट बहुत महत्वपूर्ण हो सकें?

मैं यह भी सोचता हूँ कि बैंकिंग ऐप में यह एक अच्छा विचार नहीं है। या इन्वेंट्री ऐप। या कहीं भी आप लेनदेन के बारे में सोच रहे हैं।

— जोएल कोएहॉर्न
स्रोत

4

एक व्यक्ति के रूप में जो बैंकिंग अनुप्रयोगों पर काम करता है, मेरा कहना है कि नो-लॉक कोई समस्या नहीं है। ट्रांसेक्शनल रिकॉर्ड, वह पंक्तियाँ जो सम्मिलित की जाती हैं लेकिन कभी अपडेट या डिलीट नहीं की जाती हैं, जो बिना पढ़े डेटा की समस्याओं के लिए आश्चर्यजनक प्रतिरोधी हैं।

— जोनाथन एलन

15

सरल उत्तर - जब भी आपकी SQL डेटा में परिवर्तन नहीं कर रही है, और आपके पास एक क्वेरी है जो अन्य गतिविधि (लॉकिंग के माध्यम से) के साथ हस्तक्षेप कर सकती है।

यह रिपोर्ट के लिए उपयोग किए जाने वाले किसी भी प्रश्न पर विचार करने के लायक है, खासकर अगर क्वेरी 1 सेकंड से अधिक हो।

यह विशेष रूप से उपयोगी है यदि आपके पास ओएलएपी-प्रकार की रिपोर्ट है जो आप ओएलटीपी डेटाबेस के खिलाफ चला रहे हैं।

पहला सवाल, हालांकि, "मुझे इस बारे में चिंता क्यों है?" मेरा अनुभव ln, डिफ़ॉल्ट लॉकिंग व्यवहार को ठगना अक्सर तब होता है जब कोई "कुछ भी करने की कोशिश" मोड में होता है और यह एक ऐसा मामला है जहां अप्रत्याशित परिणाम की संभावना नहीं है। अक्सर यह समय से पहले अनुकूलन का मामला होता है और "आवेदन के मामले में" भी आसानी से छोड़ दिया जा सकता है। यह समझना महत्वपूर्ण है कि आप ऐसा क्यों कर रहे हैं, यह किस समस्या को हल करता है, और क्या आपको वास्तव में समस्या है।

— dkretz
स्रोत

11

संक्षिप्त जवाब:

केवल उन WITH (NOLOCK)सूचियों पर SELECT स्टेटमेंट का उपयोग करें जिनमें क्लस्टर इंडेक्स है।

लंबा जवाब:

(NOLOCK) के साथ अक्सर डेटाबेस रीड्स को गति देने के लिए एक जादू के रूप में शोषण किया जाता है।

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

यदि बिना (NOLOCK) एक तालिका में लागू किया जाता है जिसमें एक गैर-संकुल सूचकांक है तो पंक्ति-अनुक्रमण को अन्य लेनदेन द्वारा बदला जा सकता है क्योंकि पंक्ति डेटा को परिणाम-तालिका में स्ट्रीम किया जा रहा है। इसका मतलब है कि परिणाम-सेट गायब पंक्तियाँ हो सकती हैं या एक ही पंक्ति को कई बार प्रदर्शित कर सकती हैं।

READ COMMITTED एक अतिरिक्त समस्या जोड़ता है जहां डेटा एक एकल स्तंभ के भीतर दूषित होता है जहां कई उपयोगकर्ता एक ही सेल को एक साथ बदलते हैं।

— WonderWorker
स्रोत

2

यदि अंतिम निर्णय नहीं बदलता है, तो बिना पढ़े डेटा पढ़ना स्वीकार्य है। उदाहरण के लिए, यदि आप यह जानने की कोशिश कर रहे हैं कि अगले 6 महीनों में आपका रिटेल स्टोर कितना पैसा बनाने जा रहा है, तो यह देखते हुए कि टैमी ने पेपर टॉवल के 2 रोल खरीदे, जब उसने वास्तव में 3 खरीदा तो वह भविष्य के बारे में आपकी राय बदलने वाला नहीं है। ।

— जोनाथन एलन 9

1

यदि आपके फ़िल्टर में अभी शामिल है, तो आपका डेटा उस क्षण को गलत करने वाला है जो आप क्वेरी चलाते हैं। यदि आपके फ़िल्टर में केवल ऐतिहासिक डेटा शामिल है, तो इसका उपयोग READ UNCOMITTED करना बिल्कुल भी प्रभावित नहीं करेगा। एएनएसआई मानक में इसे शामिल करने का एक कारण है।

— जोनाथन एलन

2

नेवर से नेवर। यदि आपने डेटा 100% सही होने की आवश्यकता की है, तो आपको नोलॉक का उपयोग नहीं करना चाहिए। मेरे लिए, यह आमतौर पर मामला नहीं है। किसी उपयोगकर्ता को डेटा प्रस्तुत करते समय, जब तक वे डेटा पर कार्य करते हैं, तब तक यह पहले से ही वैसे भी बदल सकता है, लेकिन सबसे अधिक संभावना नहीं थी, और लॉक विवाद प्रतिक्रिया देरी के लायक नहीं है।

— परपोस्टर

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

— वंडरवर्कर

10

मेरे 2 सेंट - यह उपयोग करने के लिए समझ में आता है WITH (NOLOCK) जब आपको रिपोर्ट उत्पन्न करने की आवश्यकता होती है। इस बिंदु पर, डेटा बहुत नहीं बदलेगा और आप उन रिकॉर्ड्स को लॉक नहीं करना चाहेंगे।

— SoftwareGeek
स्रोत

2

मुझे लगता है कि यदि आप वर्तमान परिवर्तनों की परवाह नहीं करते हैं तो (NoLOCK) बेहतर है।

— अब्दुल सबूर

9

यदि आप वित्त लेनदेन को संभाल रहे हैं तो आप कभी भी उपयोग नहीं करना चाहेंगे nolock। nolockबड़े तालिकाओं से चयन करने के लिए सबसे अच्छा उपयोग किया जाता है जिसमें बहुत सारे अपडेट होते हैं और आपको परवाह नहीं है कि आपको जो रिकॉर्ड मिलता है वह संभवतः पुराना हो सकता है।

वित्तीय रिकॉर्ड के लिए (और अधिकांश अनुप्रयोगों में लगभग सभी अन्य रिकॉर्ड) nolockकहर बरपाएंगे क्योंकि आप संभावित रूप से एक रिकॉर्ड से डेटा को वापस पढ़ सकते हैं जो सही डेटा प्राप्त नहीं किया गया था।

— एंड्रयू हरे
स्रोत

5

हैरानी की बात है, जब वित्तीय आंकड़ों के साथ काम करना कोई समस्या नहीं है। चूंकि पंक्तियों को कभी भी संपादित नहीं किया जाता है और दिन के अंत में खातों को समेट लिया जाता है, अस्थायी रूप से फर्जी डेटा पढ़ने से कुछ नहीं होता है।

— जोनाथन एलन

8

मैंने चीजों के लिए "अगला बैच" प्राप्त करने के लिए उपयोग किया है। यह इस मामले में कोई फर्क नहीं पड़ता है जो सटीक आइटम है, और मेरे पास बहुत सारे उपयोगकर्ता हैं जो एक ही क्वेरी चला रहे हैं।

— ओटवियो डेसिओ
स्रोत

1

हम काम करने के लिए एक कतार के साथ एक पृष्ठभूमि कार्य प्रस्तुत करने के लिए कुछ इसी तरह करते हैं। यदि, जब यह एक विशेष रिकॉर्ड के लिए हो जाता है, तो यह मौजूद नहीं है / चयन मानदंड से मेल खाता है, यह सिर्फ अगले पर जाता है।

— ट्रिप्पहाउंड

7

जब आप "गंदे" डेटा के साथ ठीक हों तो नोलॉक का उपयोग करें। जिसका अर्थ है कि नॉकॉक डेटा को भी पढ़ सकता है जो संशोधित और / या अनक्मिटेड डेटा होने की प्रक्रिया में है।

यह आम तौर पर उच्च लेनदेन वातावरण में इसका उपयोग करने के लिए एक अच्छा विचार नहीं है और यही कारण है कि यह क्वेरी पर एक डिफ़ॉल्ट विकल्प नहीं है।

— सीख रहा हूँ
स्रोत

3

केवल एक बार जब आपको इसकी आवश्यकता होती है तो उच्च लेनदेन के माहौल में होती है। अगर आपकी टेबल ज्यादातर बेकार है, तो आप इसके द्वारा कुछ हासिल नहीं करेंगे।

— जोनाथन एलन

7

मैं विशेष रूप से SQLServer 2000 डेटाबेस में उच्च गतिविधि के साथ (नोलॉक) संकेत के साथ उपयोग करता हूं। मुझे यकीन नहीं है कि यह SQL Server 2005 में आवश्यक है। मैंने हाल ही में क्लाइंट के डीबीए के अनुरोध पर SQL सर्वर 2000 में उस संकेत को जोड़ा है, क्योंकि वह बहुत सारे SPID रिकॉर्ड लॉक को देख रहा था।

मैं केवल इतना कह सकता हूं कि संकेत का उपयोग करने से हमें कोई नुकसान नहीं पहुंचा है और ऐसा प्रतीत होता है कि लॉकिंग की समस्या स्वयं हल हो गई है। उस विशेष ग्राहक के DBA ने मूल रूप से जोर दिया कि हम संकेत का उपयोग करते हैं।

वैसे, जिन डेटाबेस से मैं निपटता हूं, वे मेडिकल क्लेम सिस्टम के लिए बैक-एंड होते हैं, इसलिए हम कई रिकॉर्ड्स में लाखों रिकॉर्ड और 20+ टेबल के बारे में बात कर रहे हैं। मैं आमतौर पर प्रत्येक तालिका के लिए एक (नोलॉक) संकेत के साथ जुड़ता हूं (जब तक कि यह एक व्युत्पन्न तालिका नहीं है, उस स्थिति में आप उस विशेष संकेत का उपयोग नहीं कर सकते हैं)

— user52212
स्रोत

1

SQL सर्वर 2005 ने "रो वर्जनिंग" को जोड़ा जो नोलॉक्स की आवश्यकता को बहुत कम कर दे। हमने हाल ही में अपग्रेड किया है और हमारे डीबीए को उनका उपयोग बंद करने के लिए प्रशिक्षण में नहीं हैं।

— जोनाथन एलन

5

सबसे सरल उत्तर एक सरल प्रश्न है - क्या आपको दोहराने योग्य होने के लिए अपने परिणामों की आवश्यकता है? यदि हाँ तो NOLOCKS किसी भी परिस्थिति में उचित नहीं है

यदि आपको पुनरावृत्ति की आवश्यकता नहीं है, तो nolocks उपयोगी हो सकते हैं, खासकर यदि आपके पास लक्ष्य डेटाबेस से जुड़ने वाली सभी प्रक्रियाओं पर नियंत्रण नहीं है।

— एड ग्रीन
स्रोत