Database
 sql >> डेटाबेस >  >> RDS >> Database

पढ़ें अनकमिटेड आइसोलेशन लेवल

[ पूरी श्रृंखला के लिए सूचकांक देखें ]

SQL मानक (और SQL सर्वर में कार्यान्वित छह में से) में परिभाषित चार लेन-देन अलगाव स्तरों में से बिना पढ़े पढ़ना सबसे कमजोर है। यह तीनों तथाकथित "समवर्ती घटना" की अनुमति देता है, गंदा पढ़ता है , गैर-दोहराए जाने योग्य पठन , और प्रेत:

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

लेन-देन अलगाव - ACID में 'I'

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

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

यदि काउंटिंग ऑपरेशन के दौरान समवर्ती लेन-देन द्वारा पंक्तियों को तालिका में जोड़ा (या हटाया जा रहा है), तो अलग-अलग परिणाम प्राप्त हो सकते हैं, जो इस बात पर निर्भर करता है कि क्या पंक्ति-गिनती लेनदेन का सामना सभी, कुछ, या उन समवर्ती परिवर्तनों में से कोई भी नहीं है - जो बदले में पंक्ति-गणना लेनदेन के अलगाव स्तर पर निर्भर करता है।

आइसोलेशन स्तर, भौतिक विवरण और समवर्ती संचालन के समय के आधार पर, हमारा गिनती लेनदेन एक ऐसा परिणाम भी उत्पन्न कर सकता है जो लेनदेन के दौरान किसी भी समय तालिका की प्रतिबद्ध स्थिति का सही प्रतिबिंब नहीं था।

उदाहरण

एक पंक्ति-गिनती लेनदेन पर विचार करें जो समय T1 पर शुरू होता है, और तालिका को प्रारंभ से अंत तक स्कैन करता है (तर्क के लिए क्लस्टर इंडेक्स कुंजी क्रम में)। उस समय, तालिका में 100 प्रतिबद्ध पंक्तियाँ हैं। कुछ समय बाद (समय T2 पर), हमारे गिनती लेनदेन में उन पंक्तियों में से 50 का सामना करना पड़ा है। उसी समय, एक समवर्ती लेनदेन तालिका में दो पंक्तियों को सम्मिलित करता है, और थोड़े समय बाद T3 (गिनती लेनदेन समाप्त होने से पहले) पर करता है। सम्मिलित पंक्तियों में से एक क्लस्टर इंडेक्स संरचना के आधे हिस्से में आती है जिसे हमारी गिनती लेनदेन पहले ही संसाधित कर चुकी है, जबकि दूसरी सम्मिलित पंक्ति बेशुमार हिस्से में बैठती है।

जब पंक्ति-गणना लेनदेन पूरा हो जाता है, तो यह इस परिदृश्य में 101 पंक्तियों की रिपोर्ट करेगा; प्रारंभ में तालिका में 100 पंक्तियाँ और स्कैन के दौरान सामने आई एकल सम्मिलित पंक्ति। यह परिणाम तालिका के प्रतिबद्ध इतिहास के विपरीत है:समय T1 और T2 पर 100 प्रतिबद्ध पंक्तियाँ थीं, फिर T3 समय पर 102 प्रतिबद्ध पंक्तियाँ थीं। ऐसा कोई समय नहीं था जब 101 प्रतिबद्ध पंक्तियाँ थीं।

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

विश्लेषण

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

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

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

प्रतिबद्ध डेटा के नवीनतम सेट के आधार पर परिणाम तैयार करने (और निर्णय लेने!) सुनिश्चित करने के लिए, डेटाबेस के खिलाफ संचालन के कुछ सीरियल इतिहास के लिए, हमें क्रमिक लेनदेन अलगाव की आवश्यकता होगी। बेशक यह विकल्प आम तौर पर संसाधन उपयोग और कम संगामिति (गतिरोध के बढ़े हुए जोखिम सहित) के मामले में सबसे महंगा है।

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

कितना बुरा है बिना पढ़े पढ़ा?

उपलब्ध आइसोलेशन स्तरों में से सबसे कमजोर के रूप में बिना पढ़े आइसोलेशन को पेश करने के बाद, आपको यह उम्मीद करनी चाहिए कि यह रीड कमिटेड (अगले उच्चतम आइसोलेशन स्तर) को लॉक करने की तुलना में कम आइसोलेशन गारंटी की पेशकश करेगा। वास्तव में यह करता है; लेकिन सवाल यह है कि प्रतिबद्ध अलगाव को लॉक करने से कितना बुरा है?

ताकि हम सही संदर्भ के साथ शुरू करें, यहां मुख्य समवर्ती प्रभावों की एक सूची है जिसे SQL सर्वर डिफ़ॉल्ट लॉकिंग रीड कमिटेड आइसोलेशन स्तर के तहत अनुभव किया जा सकता है:

  • प्रतिबद्ध पंक्तियाँ अनुपलब्ध
  • पंक्तियों का कई बार सामना करना पड़ा
  • एक ही कथन/क्वेरी योजना में एक ही पंक्ति के विभिन्न संस्करणों का सामना करना पड़ा
  • एक ही पंक्ति में समय के विभिन्न बिंदुओं से प्रतिबद्ध स्तंभ डेटा (उदाहरण)

ये समवर्ती प्रभाव केवल पढ़ने के लिए प्रतिबद्ध लॉकिंग कार्यान्वयन के कारण हैं, डेटा पढ़ते समय केवल बहुत ही अल्पकालिक साझा ताले लेते हैं। रीड अनकमिटेड आइसोलेशन स्तर एक कदम आगे जाता है, साझा ताले को बिल्कुल भी नहीं लेने से, जिसके परिणामस्वरूप "डर्टी रीड्स" की अतिरिक्त संभावना होती है।

डर्टी रीड्स

एक त्वरित अनुस्मारक के रूप में, एक "डर्टी रीड" डेटा को पढ़ने के लिए संदर्भित करता है जिसे किसी अन्य समवर्ती लेनदेन द्वारा बदला जा रहा है (जहां "परिवर्तन" में सम्मिलित करना, अपडेट करना, हटाना और मर्ज करना शामिल है)। दूसरे तरीके से कहें तो, एक गंदा पठन तब होता है जब कोई लेन-देन उस डेटा को पढ़ता है जिसे किसी अन्य लेनदेन ने संशोधित किया है, इससे पहले कि संशोधित लेनदेन ने उन परिवर्तनों को किया या निरस्त कर दिया।

फायदे और नुकसान

रीड अनकमिटेड आइसोलेशन के प्राथमिक लाभ असंगत लॉक (लॉक एस्केलेशन के कारण अनावश्यक ब्लॉकिंग सहित) के कारण ब्लॉकिंग और डेडलॉकिंग की कम संभावना है, और संभवतः बेहतर प्रदर्शन (साझा किए गए लॉक को प्राप्त करने और जारी करने की आवश्यकता से बचकर)।

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

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

आवंटन आदेश स्कैन

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

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

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

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

"भ्रष्ट" डेटा पढ़ना

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

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

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

आगे जाकर, बिना पढ़े हुए लेन-देन के लिए एकल कॉलम मान पढ़ना भी संभव है प्रतिबद्ध और अप्रतिबद्ध डेटा की मिश्रित स्थिति में। यह तब हो सकता है जब एक LOB मान (उदाहरण के लिए, xml, या 'अधिकतम' प्रकारों में से कोई भी) पढ़ते समय मान एकाधिक डेटा पृष्ठों में संग्रहीत किया जाता है। एक अप्रतिबद्ध पठन अलग-अलग पृष्ठों पर अलग-अलग बिंदुओं से प्रतिबद्ध या अप्रतिबद्ध डेटा का सामना कर सकता है, जिसके परिणामस्वरूप अंतिम एकल-स्तंभ मान होता है जो मूल्यों का मिश्रण होता है!

एक उदाहरण लेने के लिए, एक एकल वर्चर (अधिकतम) कॉलम पर विचार करें जिसमें शुरू में 10,000 'x' वर्ण हों। एक समवर्ती लेनदेन इस मान को 10,000 'y' वर्णों में अद्यतन करता है। एक पढ़ा हुआ अप्रतिबंधित लेन-देन LOB के एक पृष्ठ से 'x' वर्ण और दूसरे से 'y' वर्ण पढ़ सकता है, जिसके परिणामस्वरूप 'x' और 'y' वर्णों का मिश्रण वाला अंतिम पठन मान होता है। यह तर्क देना कठिन है कि यह "भ्रष्ट" डेटा पढ़ने का प्रतिनिधित्व नहीं करता है।

डेमो

LOB डेटा की एक पंक्ति के साथ एक संकुल तालिका बनाएँ:

CREATE TABLE dbo.Test
(
    RowID integer PRIMARY KEY,
    LOB varchar(max) NOT NULL,
);
 
INSERT dbo.Test
    (RowID, LOB)
VALUES
    (1, REPLICATE(CONVERT(varchar(max), 'X'), 16100));

एक अलग सत्र में, पढ़ने के लिए अनकमिटेड आइसोलेशन पर LOB मान पढ़ने के लिए निम्न स्क्रिप्ट चलाएँ:

-- Run this in session 2
SET NOCOUNT ON;
 
DECLARE 
    @ValueRead varchar(max) = '',
    @AllXs varchar(max) = REPLICATE(CONVERT(varchar(max), 'X'), 16100),
    @AllYs varchar(max) = REPLICATE(CONVERT(varchar(max), 'Y'), 16100);
 
WHILE 1 = 1
BEGIN
    SELECT @ValueRead = T.LOB
    FROM dbo.Test AS T WITH (READUNCOMMITTED)
    WHERE T.RowID = 1;
 
    IF @ValueRead NOT IN (@AllXs, @AllYs)
    BEGIN
    	PRINT LEFT(@ValueRead, 8000);
        PRINT RIGHT(@ValueRead, 8000);
        BREAK;
    END
END;

पहले सत्र में, LOB कॉलम में वैकल्पिक मान लिखने के लिए इस स्क्रिप्ट को चलाएँ:

-- Run this in session 1
SET NOCOUNT ON;
 
DECLARE 
    @AllXs varchar(max) = REPLICATE(CONVERT(varchar(max), 'X'), 16100),
    @AllYs varchar(max) = REPLICATE(CONVERT(varchar(max), 'Y'), 16100);
 
WHILE 1 = 1
BEGIN
    UPDATE dbo.Test
    SET LOB = @AllYs
    WHERE RowID = 1;
 
    UPDATE dbo.Test
    SET LOB = @AllXs
    WHERE RowID = 1;
END;

थोड़े समय के बाद, सत्र दो में स्क्रिप्ट समाप्त हो जाएगी, उदाहरण के लिए LOB मान के लिए एक मिश्रित स्थिति पढ़कर:

यह विशेष समस्या एलओबी कॉलम मानों के पढ़ने तक ही सीमित है जो कई पृष्ठों में फैले हुए हैं, अलगाव स्तर द्वारा प्रदान की गई किसी भी गारंटी के कारण नहीं, बल्कि इसलिए कि SQL सर्वर भौतिक अखंडता सुनिश्चित करने के लिए पृष्ठ-स्तरीय लैच का उपयोग करता है। इस कार्यान्वयन विवरण का एक दुष्परिणाम यह है कि यह ऐसे "भ्रष्ट" डेटा को पढ़ने से रोकता है यदि एकल रीड ऑपरेशन का डेटा एक ही पृष्ठ पर रहता है।

आपके पास SQL ​​​​सर्वर के संस्करण के आधार पर, यदि "मिश्रित स्थिति" डेटा एक xml कॉलम के लिए पढ़ा जाता है, तो आपको संभावित रूप से विकृत xml परिणाम के परिणामस्वरूप एक त्रुटि मिलेगी, कोई त्रुटि नहीं, या असामान्य-विशिष्ट त्रुटि 601 , "डेटा संचलन के कारण NOLOCK के साथ स्कैन जारी नहीं रख सका।" अन्य LOB प्रकारों के लिए मिश्रित-राज्य डेटा पढ़ने से आमतौर पर कोई त्रुटि संदेश नहीं मिलता है; उपभोग करने वाले एप्लिकेशन या क्वेरी के पास यह जानने का कोई तरीका नहीं है कि उसने सबसे खराब प्रकार के गंदे पढ़ने का अनुभव किया है। विश्लेषण को पूरा करने के लिए, इंडेक्स चौराहे के परिणामस्वरूप पढ़ी गई गैर-एलओबी मिश्रित-राज्य पंक्ति को कभी भी त्रुटि के रूप में रिपोर्ट नहीं किया जाता है।

यहां संदेश यह है कि यदि आप बिना पढ़े अलगाव का उपयोग करते हैं, तो आप स्वीकार करते हैं कि गंदे पढ़ने में "भ्रष्ट" मिश्रित-राज्य LOB मान पढ़ने की संभावना शामिल है।

नोलॉक हिंट

मुझे लगता है कि कम से कम इस (व्यापक रूप से अति प्रयोग और गलत समझा) तालिका संकेत का उल्लेख किए बिना पढ़ने के बिना पढ़े गए अलगाव स्तर की कोई चर्चा पूरी नहीं होगी। संकेत अपने आप में READUNCOMMITTED तालिका संकेत का एक पर्याय है। यह बिल्कुल वैसा ही कार्य करता है:जिस ऑब्जेक्ट पर इसे लागू किया जाता है, उसे बिना पढ़े आइसोलेशन सेमेन्टिक्स (हालांकि एक अपवाद है) का उपयोग करके एक्सेस किया जाता है।

जहां तक ​​"NOLOCK" नाम का सवाल है, इसका सीधा सा मतलब है कि डेटा पढ़ते समय कोई साझा लॉक नहीं लिया जाता है . अन्य लॉक (स्कीमा स्थिरता, डेटा संशोधन के लिए अनन्य लॉक आदि) को अभी भी सामान्य रूप में लिया जाता है।

सामान्यतया, NOLOCK संकेत अन्य प्रति-वस्तु अलगाव स्तर तालिका संकेतों जैसे SERIALIZABLE और READCOMMITTEDLOCK के समान ही सामान्य होने चाहिए। कहने का तात्पर्य यह है:बिल्कुल भी सामान्य नहीं है, और केवल वहीं उपयोग किया जाता है जहां कोई अच्छा विकल्प नहीं है, इसका एक अच्छी तरह से परिभाषित उद्देश्य है, और एक पूर्ण परिणामों की समझ।

NOLOCK (या READUNCOMMITTED) के वैध उपयोग का एक उदाहरण DMV या अन्य सिस्टम दृश्यों तक पहुँच है, जहाँ एक उच्च अलगाव स्तर गैर-उपयोगकर्ता डेटा संरचनाओं पर अवांछित विवाद का कारण बन सकता है। एक और एज-केस उदाहरण हो सकता है जहां एक क्वेरी को एक बड़ी तालिका के एक महत्वपूर्ण हिस्से तक पहुंचने की आवश्यकता होती है, जो कि संकेतित क्वेरी निष्पादित होने पर डेटा परिवर्तनों का अनुभव नहीं करने की गारंटी है। स्नैपशॉट का उपयोग न करने या इसके बजाय प्रतिबद्ध स्नैपशॉट अलगाव को पढ़ने के लिए एक अच्छा कारण होना चाहिए, और अपेक्षित प्रदर्शन वृद्धि को एकल साझा टेबल लॉक संकेत का उपयोग करके परीक्षण, मान्य और तुलना करने की आवश्यकता होगी।

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

अंतिम विचार

लेन-देन अलगाव स्तर के लिए बिना पढ़े पढ़ना एक वैध विकल्प है, लेकिन इसे एक सूचित विकल्प होने की आवश्यकता है। एक अनुस्मारक के रूप में, SQL सर्वर डिफॉल्ट लॉकिंग रीड कमिटेड आइसोलेशन के तहत कुछ समवर्ती घटनाएं यहां संभव हैं:

  • पहले से प्रतिबद्ध पंक्तियाँ अनुपलब्ध
  • प्रतिबद्ध पंक्तियों का कई बार सामना करना पड़ा
  • एक ही कथन/क्वेरी योजना में सामने आए एक ही पंक्ति के विभिन्न प्रतिबद्ध संस्करण
  • एक ही पंक्ति में समय में विभिन्न बिंदुओं से प्रतिबद्ध डेटा (लेकिन अलग-अलग कॉलम)
  • प्रतिबद्ध डेटा पढ़ता है जो सक्षम और चेक की गई बाधाओं के विपरीत प्रतीत होता है

आपके दृष्टिकोण के आधार पर, यह डिफ़ॉल्ट अलगाव स्तर के लिए संभावित विसंगतियों की एक चौंकाने वाली सूची हो सकती है। उस सूची में, अनकमिटेड आइसोलेशन ऐड्स पढ़ें:

  • डर्टी रीड्स (ऐसे डेटा का सामना करना जो अभी तक नहीं हुआ है, और शायद कभी भी प्रतिबद्ध नहीं है)
  • प्रतिबद्ध और अप्रतिबद्ध डेटा के मिश्रण वाली पंक्तियाँ
  • आवंटन-आदेशित स्कैन के कारण छूटी हुई/डुप्लिकेट पंक्तियां
  • मिश्रित-अवस्था ("भ्रष्ट") व्यक्तिगत (एकल-स्तंभ) LOB मान
  • त्रुटि 601 - "डेटा के संचलन के कारण NOLOCK के साथ स्कैन जारी नहीं रख सका" (उदाहरण)।

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

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

अपेक्षाकृत कम संख्या में ऐसे अनुप्रयोग भी होंगे जिनके लिए अनकमिटेड आइसोलेशन पढ़ना सही विकल्प है। इन अनुप्रयोगों को अनुमानित परिणामों और कभी-कभी असंगत, स्पष्ट रूप से अमान्य (बाधाओं के संदर्भ में), या "यकीनन भ्रष्ट" डेटा की संभावना से खुश होने की आवश्यकता है। यदि डेटा अपेक्षाकृत बार-बार बदलता है, तो इन विसंगतियों का जोखिम भी कम होता है।

[ पूरी श्रृंखला के लिए सूचकांक देखें ]


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQL GROUP BY- एक पेशेवर की तरह परिणामों को समूहीकृत करने के लिए 3 आसान टिप्स

  2. हाइपर-वी . के भीतर डायनेमिक मेमोरी का उपयोग करते समय जोखिम

  3. अनुक्रमण कैसे काम करता है

  4. F# को Salesforce.com से कनेक्ट करना

  5. शुरुआती के लिए एसक्यूएल हैविंग क्लॉज