जैसा कि हम सभी जानते हैं, READ UNCOMMITTED सबसे कम आइसोलेशन स्तर है जिसमें गंदे रीड और फैंटम रीड जैसी चीजें आ सकती हैं। इस अलगाव स्तर का उपयोग करने का सबसे अच्छा समय कब है और किन कारणों से इसका उपयोग किया जा सकता है?
वास्तव में मैंने पहले उत्तर पढ़े थे, लेकिन मैं इसे पूरी तरह से समझ नहीं पाया क्योंकि पर्याप्त उदाहरण नहीं थे।
जवाबों:
मैं एसएसएमएस से उत्पादन डेटाबेस की क्वेरी करते समय READ_UNCOMMITTED(या NOLOCK) उपयोग करता हूं, लेकिन एप्लिकेशन कोड से नियमित रूप से नहीं। यह अभ्यास (MAXDOP 1 क्वेरी संकेत के साथ) डेटा विश्लेषण के लिए आकस्मिक प्रश्नों को सुनिश्चित करने में मदद करता है और समस्या निवारण उत्पादन कार्यभार को प्रभावित नहीं करता है, समझ के साथ परिणाम सही नहीं हो सकते हैं।
अफसोस की बात है, मैं डेटा अखंडता की कीमत पर अवरुद्ध से बचने के लिए उत्पादन कोड में व्यापक रूप से देखता READ_UNCOMMITTED/ NOLOCKउपयोग करता हूं । उचित समाधान एक पंक्ति-वर्ज़निंग अलगाव स्तर (है SNAPSHOTया READ_COMMITTEDसाथ READ_COMMITTED_SNAPSHOTडेटाबेस विकल्प ON) और / या क्वेरी और सूचकांक ट्यूनिंग के लिए ध्यान।
मैंने हाल ही में एक कोड की समीक्षा की, जहां केवल परिवर्तन को हटाना था NOLOCKक्योंकि यह कभी-कभी गलत परिणाम देता था। हटाना NOLOCKएक अच्छी बात थी लेकिन, यह जानकर कि मिस या डुप्लिकेट की गई पंक्तियाँ आम तौर पर बड़ी तालिकाओं के आवंटन आदेश स्कैन के दौरान होती हैं , मैंने यह भी सुझाव दिया कि UNION ALLकुशल इंडेक्स के उपयोग को बढ़ावा देने के लिए तकनीक का उपयोग करना चाहिए। क्वेरी अब सही परिणाम के साथ कुछ मिलीसेकंड में चलती है, सभी दुनिया के सर्वश्रेष्ठ।
मुझे लगता है कि यह कुछ परिस्थितियों में ठीक है, जब तक आप परिणाम स्वीकार करते हैं, और अन्य विकल्प नहीं होते।
अन्य विकल्पों के लिए, मैं नए अनुप्रयोगों के लिए पढ़े हुए स्नैपशॉट अलगाव (RCSI), या पुराने अनुप्रयोगों के लिए SNAPSHOT अलगाव (SI) का उपयोग करने की दिशा में लोगों को आगे बढ़ाऊंगा, जहाँ आप RCSI के साथ दौड़ की स्थिति के लिए पूरे कोड आधार का आसानी से परीक्षण नहीं कर सकते।
हालांकि, वे एक अच्छे फिट नहीं हो सकते हैं। आपको tempdb के लिए प्यार और देखभाल करने के लिए कुछ अतिरिक्त समय बिताने की आवश्यकता हो सकती है, और सुनिश्चित करें कि कोई भी एक खुला लेनदेन नहीं छोड़ता है जो संस्करण स्टोर (और tempdb) को विकसित करता है और डिस्क को भरता है।
यदि आपके पास DBA नहीं है, या कोई ऐसा व्यक्ति है जिसका काम आपके SQL सर्वर की निगरानी और प्रबंधन करना है, तो वे विकल्प खतरनाक हो सकते हैं। अधिक सामान्यतः, हर किसी के पास अपने सर्वर पर जाने वाले कोड का पूर्ण नियंत्रण नहीं होता है जहां वे समस्या के प्रश्नों के लिए SI से पूछने के लिए कनेक्शन स्ट्रिंग या कोड को बदल सकते हैं।
इसके अलावा, ज्यादातर लोगों को अपने पूरे आवेदन में लॉकिंग की समस्या नहीं है । उन्हें ओएलटीपी डेटा पर रिपोर्टिंग जैसी सामग्री की समस्या है। यदि आप लेखकों द्वारा अवरुद्ध नहीं की जा रही रिपोर्टों के बदले में NOLOCK / RU के ट्रेड-ऑफ को स्वीकार कर सकते हैं, तो इसके लिए जाएं।
बस यह सुनिश्चित करें कि आप इसका क्या मतलब समझते हैं। इसका मतलब यह नहीं है कि आपकी क्वेरी किसी भी ताले को नहीं लेती है, इसका मतलब है कि यह अन्य प्रश्नों द्वारा उठाए गए ताले का सम्मान नहीं करता है।
और हां, अगर आपकी समस्या लेखक / लेखक लॉकिंग है, तो एकमात्र विकल्प जो मदद करेगा, वह है SI, लेकिन यह त्रुटि को ठीक से लागू करने के लिए डेवलपर के काम की एक अविश्वसनीय राशि लेगा, आदि।
IMHO आधुनिक प्रणाली पर पढ़े जाने के लिए एकमात्र वैध उपयोग का मामला है, जब विकास में एक सत्र को दूसरे से डिबग कर रहा है, तो आप देख सकते हैं कि यह क्या कर रहा है जैसे कि एक संग्रहीत खरीद अभी भी चल रही है। यह आम तौर पर एक उत्पादन प्रणाली में इस्तेमाल नहीं किया जाएगा। कुछ मामूली प्रदर्शन लाभ हो सकता है लेकिन लंबी अवधि में यह इसके लायक कभी नहीं होगा।
हम हर समय स्वास्थ्य देखभाल में इसका उपयोग करते हैं।
मध्य-क्वेरी को बदलने के लिए डेटा की व्यक्तिगत पंक्तियों के लिए यह आश्चर्यजनक रूप से दुर्लभ है, और पढ़ने / लिखने का अनुपात 10,000 / 1 की तरह है - और उनमें से अधिकांश आवेषण हैं, अपडेट नहीं। उदाहरण के लिए, जब लैब इंटरफ़ेस डेटाबेस में किसी मरीज की लैब परिणाम लिखता है, तो वे मान कभी नहीं बदलने वाले हैं।
डेटा जब करता है परिवर्तन, यह एक समय में एक पंक्ति बदल जाता है। कोई भी पूरे कॉलम को अपडेट नहीं कर रहा है (डीबीए को छोड़कर, जब वे वास्तव में खराब होते हैं)।
दूसरी तरफ, हम ईआर पर आने वाले मरीजों के लिए 72 घंटों या उससे कम समय में चीजों को स्कैन करने के लिए प्रश्नों का एक समूह चलाते हैं, जो बिल्कुल तालिकाओं को हथौड़े से मारते हैं।
स्वास्थ्य देखभाल एसक्यूएल के 10 वर्षों में, मैंने कभी नहीं देखा है Rollback Transaction। मैं अंत उपयोगकर्ता अनुभव को बाधित किए बिना अंदर और बाहर निकलना चाहता हूं। यदि ओएलटीपी डेटाबेस को धीमा करने और खराब डेटा प्राप्त करने का कम जोखिम है, तो मैं NOLOCK होगा।
क्या हमें इसका उपयोग करना चाहिए ? शायद शायद नहीं। सामान्यतया, मैं यह नहीं कहूंगा कि मैंने जिन एप्लिकेशन डेटाबेस पर काम किया है उनमें से कई अच्छी तरह से डिज़ाइन किए गए हैं। वे आम तौर पर विरोधी प्रतिरूपों से भरे होते हैं।
READ_UNCOMMITTED/NOLOCKएक अच्छा विकल्प है जब डेटा की सटीकता वास्तव में मुख्य उद्देश्य नहीं है। कभी-कभी जब एक अनुमानित कुल गणना की आवश्यकता होती है। उदाहरण के लिए: संग्रहीत कार्यविधियाँ हैं जिनका उपयोग INSERT या UPDATE तालिकाओं में किया जाता है। कभी-कभी अपडेट या सम्मिलित किए जाने वाले रिकॉर्ड की संख्या बहुत बड़ी होती है (हजारों रिकॉर्ड)। इन संग्रहीत कार्यविधियों के चलने के दौरान, हम NOLOCKसमय-समय पर लक्ष्य तालिका के साथ एक सरल चयन क्वेरी चला सकते हैं, यह देखने के लिए कि क्या यह सुचारू रूप से प्रगति करता है (अपडेट क्वेरी के लिए, यदि आपके पास रिकॉर्ड किए जा रहे रिकॉर्ड के लिए स्थिति बदलने वाला कॉलम है, तो हम group byक्वेरी चलाने के लिए उस कॉलम का उपयोग कर सकते हैं NOLOCKयह जानने के लिए कि क्या स्थिति परिवर्तन गणना लगातार बदल रही है)।
ज्ञात हो कि READ UNCOMMITTED केवल गंदे पढ़ने के लिए नहीं, बल्कि अतिरिक्त स्थिरता के मुद्दों को प्रस्तुत करता है। पहुंच विधि के आधार पर, आप पंक्तियों को याद कर सकते हैं, या यहां तक कि एक ही पंक्ति को एक से अधिक बार पढ़ सकते हैं। यदि आप विवरण में रुचि रखते हैं, तो इत्ज़िक बेन-गण का लेख पढ़ें