पंक्ति स्तर और पृष्ठ स्तर लॉकिंग और परिणाम के बीच अंतर


10

अपनी रखरखाव योजना को चलाने का प्रयास करते समय, मुझे निम्न त्रुटि प्राप्त होती है:

क्वेरी को निष्पादित करने में "" निम्न त्रुटि के साथ विफल हुआ: "सूचकांक" "(विभाजन 1) टेबल पर" "पुनर्गठित नहीं किया जा सकता क्योंकि पृष्ठ स्तर लॉकिंग अक्षम है।"

वर्तमान में हमारे पास इस सूचकांक पर पंक्ति स्तर लॉकिंग सक्षम है। मैं पृष्ठ स्तर लॉकिंग को सक्षम कर सकता हूं, लेकिन मैं अनिश्चित हूं कि नतीजे क्या हैं।

मेरा प्रश्न यह है: दो लॉकिंग योजनाओं के बीच अंतर क्या है, और उनके वास्तविक दुनिया (उत्पादन में) परिणाम क्या हैं?

जवाबों:


14

क्वेरी को निष्पादित करने में "" निम्न त्रुटि के साथ विफल हुआ: "सूचकांक" "(विभाजन 1) टेबल पर" "पुनर्गठित नहीं किया जा सकता क्योंकि पृष्ठ स्तर लॉकिंग अक्षम है।"

अनुरक्षण योजना को ALTER INDEX REORGANIZE का प्रयास करना चाहिए, जो एक ऑनलाइन ऑपरेशन है। विखंडन (पृष्ठ क्रम में नहीं) को हटाने के लिए, पृष्ठों को लॉक और स्थानांतरित किया जाना चाहिए, जो कि संभव नहीं है यदि पृष्ठ ताले अक्षम किए गए हैं। पृष्ठ लॉक के बिना डीफ़्रैग्मेन्ट करने का एकमात्र तरीका पूरे विभाजन को लॉक करना है, जो केवल ऑनलाइन के रूप में REORGANIZE के लिए संभव नहीं है।

दो लॉकिंग योजनाओं के बीच अंतर क्या है, और उनकी वास्तविक दुनिया (उत्पादन में) परिणाम क्या हैं?

आपको यह समझने की जरूरत है कि किसी विशेष लॉक प्रकार को रोकने के प्रभाव का मूल्यांकन करने के लिए रिकॉर्ड और पृष्ठ क्या हैं। यदि आप SQL सर्वर संग्रहण इंटर्नल से अपरिचित हैं, तो रिकॉर्ड के एनाटॉमी और पेज के एनाटॉमी से शुरू करें । बहुत सरल शब्दों में कहें:

  • पंक्तियाँ = अभिलेख
  • पंक्तियों को 8kb के पृष्ठों में संग्रहीत किया जाता है

यदि आप अनुमत लॉक प्रकारों को बदलना चाहते थे:

  • पेज लॉक = पंक्ति और टेबल लॉक को केवल अक्षम करें
  • पंक्ति ताले अक्षम करें = पृष्ठ और तालिका लॉक केवल
  • दोनों को अक्षम करें = टेबल लॉक केवल

ऐसे दो परिदृश्य हैं जिनके बारे में मुझे पता है कि लॉक प्रकार को अस्वीकार करना कहां तक ​​फायदेमंद हो सकता है। इसका मतलब यह नहीं है कि वहाँ दूसरों को नहीं कर रहे हैं, उम्मीद है कि कोई और उदाहरण के साथ कदम होगा।

एक बार-बार एक्सेस किया गया लुकअप टेबल, जो बार - बार बदलता है - पेज और रो लेवल लॉक दोनों को अक्षम करके, सभी पाठक एक साझा टेबल लॉक लेंगे। यह मेज पर सामान्य इरादे-साझा किए जाने के बजाय तेजी से / सस्ता है, इसके बाद एक पृष्ठ पर इरादा-साझा किया जाता है और अंत में एक विशिष्ट पंक्ति या पंक्तियों पर एक साझा लॉक होता है।

एक विशिष्ट गतिरोध परिदृश्य को रोकना - यदि आप समवर्ती प्रक्रियाओं के कारण उत्पन्न गतिरोध का सामना करते हैं, जो एक ही पृष्ठ पर अक्सर होने वाले ताले प्राप्त करते हैं, तो पंक्ति ताले के परिणाम को रोकने के बजाय पृष्ठ ताले को लिया जा रहा है। केवल एक प्रक्रिया एक समय में पृष्ठ तक पहुंच सकती है, दूसरे को इंतजार करना होगा।

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

डिफ़ॉल्ट दोनों के लिए सक्षम होना चाहिए और इसे अच्छे कारण के बिना नहीं बदला जाना चाहिए


9

शायद कुछ भी नहीं। मुझे यकीन है कि एमएस आपको या मैं से बेहतर जानता हूं

मैंने उच्च मात्रा वाले ओएलटीपी सिस्टम पर काम किया है और कभी भी सेटिंग्स को बदलने की आवश्यकता महसूस नहीं की है। एक गतिरोध को वापस लिया जाना चाहिए क्योंकि वे वैसे भी होंगे

SQL सर्वर स्टोरेज इंजन ब्लॉग से उद्धृत , "SQL2005 में लॉक एस्केलेशन" n जो वैसे भी पूरी तरह से पढ़ने लायक है।

डिफ़ॉल्ट रूप से, हमारे पास ROW और PAGE दोनों लॉक सक्षम हैं ... SQL सर्वर ज्यादातर मामलों के लिए ROW लॉक ग्रैन्युलैरिटी चुनता है, लेकिन जहां उपयुक्त हो वहां पेज लॉक चुन सकता है। तो आपके द्वारा निर्दिष्ट मामले के लिए, आरओडब्ल्यू लॉक की संभावना है। डेटाबेस या उदाहरण के स्तर पर पेज लॉकिंग को बंद करने का कोई तरीका नहीं है। क्या आप पेज लॉक होने के कारण ब्लॉक कर रहे हैं?

मुझे लगता है कि यदि आप केवल रांग्लॉक्स को मजबूर करते हैं तो आप उन संसाधनों का उपभोग करेंगे जिनका उपयोग कहीं और अधिक प्रभावी ढंग से किया जा सकता है। यदि आपका लोड इतना अधिक है कि यह मायने रखता है, तो मेमोरी का उपभोग क्यों करें? ब्लॉग लेख इस में चला जाता है

मुझे संदेह है कि इसके पीछे कुछ अंधविश्वास है, बस इन जैसे:


+1 लेकिन: ओएलटीपी सिस्टम में गतिरोध को रोका जा सकता है; मेरा सिस्टम महीनों तक गतिरोध मुक्त है, हालांकि हम सप्ताह में 2-3 बार तैनात करते हैं।
एके
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.