एसक्यूएल सर्वर - [SELECT] लॉक [अद्यतन] करता है?

Question

मेरे पास एक जटिल चयन क्वेरी और एक विशाल तालिका है।

मैं इस select बयान चल रहा हूँ, इस बीच एक Update बयान आता है और अद्यतन तालिका की कोशिश करता है।

IMHO - अद्यतन एक अनन्य लॉक की आवश्यकता है - तो अद्यतन बयान होगा करने के लिए इंतजार तक चयन आदेश समाप्त हो गया है। सही

1. एम आई?

2. है कि मैं क्या करने के लिए कर सकते हैं: जटिल update आदेश रन select, और भी करते हैं (वर्तमान में मैं गंदा डेटा के बारे में परवाह नहीं है) पर अमल

Answer 1

हाँ - करने के लिए एक उपाधि।

कब तक एक SELECT लेन-देन के अलगाव के स्तर पर निर्भर करता है एक साझा लॉक करने पर रखती है:

• READ UNCOMMITTED - कोई साझा ताला सब पर प्राप्त किया जाता है - UPDATE अवरोधित नहीं है
• READ COMMITTED - साझा लॉक को डेटा पढ़ने की अवधि के लिए अधिग्रहित किया जाता है - UPDATE बहुत कम समय के लिए अवरुद्ध हो सकता है
• REPEATABLE READ और SERIALIZABLE - साझा लॉक अधिग्रहण किया जाता है और unti पर आयोजित किया जाता है एल लेन-देन के अंत - जो एक साझा ताला (के रूप में SELECT द्वारा प्रयुक्त) के साथ संगत है - - अवधि के लिए UPDATE अवरुद्ध है जब तक SELECT लेन-देन समाप्त होता है

तकनीकी तौर पर, UPDATE बयान पहली बार एक UPDATE ताला हो जाता है समय के साथ यह पंक्तियों के वर्तमान मूल्यों को अद्यतन करने के लिए पढ़ रहा है।

एक बार यह हो, Update ताला नए डेटा के लिए एक विशेष लॉक करने के लिए उठाई गई है मेज पर लिखा होना चाहिए।

Answer 2

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

यह सरलीकृत कहानी है। वास्तविक जीवन बहुत जटिल है। चयन में एकाधिक पढ़े गए अंक (समांतर योजनाएं) हो सकती हैं। चयन और अद्यतन दोनों एक पहुंच पथ चुनने के अधीन हैं, जिसका मतलब पंक्तियों का पता लगाने के लिए एक या अधिक माध्यमिक अनुक्रमणिका का उपयोग करना है। जटिल प्रश्नों में ऑपरेटर हो सकते हैं जो एक तालिका में एकाधिक लुकअप का कारण बनते हैं (उदाहरण के लिए।)। चयन और अद्यतन दोनों बीएलओबी डेटा लाने के लिए बुकमार्क लुकअप कर सकते हैं, जो महत्वपूर्ण रूप से लॉकिंग व्यवहार को बदलता है। कार्डिनालिटी अनुमान से उच्च ग्रॅन्युलैरिटी लॉक मोड (जैसे तालिका स्तर साझा लॉक) पर SELECT को चलाने का कारण हो सकता है। अद्यतन लॉक वृद्धि को ट्रिगर कर सकता है, और वृद्धि विफल हो सकती है या सफल हो सकती है। Choosing different access paths can lead to deadlock। False lock contention can occur due to hash collisions। इसमें केवल एक असंख्य चर हैं जिनके बारे में कोई कहना है। और मैंने उच्च अलगाव स्तर का उल्लेख भी नहीं किया (दोहराने योग्य पढ़ने, धारावाहिक)।

शायद आपको SNAPSHOT अलगाव का उपयोग करना चाहिए और इस मुद्दे के बारे में चिंता करना बंद कर देना चाहिए?