LATCH_EX संसाधन METADATA_SEQUENCE_GENERATOR पर प्रतीक्षा करता है

Question

हमारे पास एक प्रक्रिया है जो एक इन्वेंट्री रिपोर्ट तैयार करती है। क्लाइंट की ओर से, इस प्रक्रिया में रिपोर्ट के लिए डेटा का एक हिस्सा बनाने के लिए कार्यकर्ता थ्रेड्स की एक कॉन्फ़िगर करने योग्य संख्या को विभाजित करता है जो कई में से एक स्टोर से मेल खाती है (संभवतः हजारों, आमतौर पर दर्जनों)। प्रत्येक कार्यकर्ता थ्रेड एक वेब सेवा को कॉल करता है जो संग्रहीत प्रक्रिया को निष्पादित करता है।

प्रत्येक चंक को संसाधित करने के लिए डेटाबेस प्रक्रिया एक # तालिका तालिका में डेटा का एक गुच्छा इकट्ठा करती है। प्रत्येक प्रोसेसिंग चंक के अंत में, डेटा को टेम्पर्ड टेबल में स्थायी तालिका में लिखा जाता है। अंत में, प्रक्रिया के अंत में, क्लाइंट साइड पर एक धागा स्थायी टेम्पर्ड टेबल से सभी डेटा का अनुरोध करता है।

जितने अधिक उपयोगकर्ता इस रिपोर्ट को चलाते हैं, उतना ही धीमा हो जाता है। मैंने डेटाबेस में गतिविधि का विश्लेषण किया। एक बिंदु पर, मैंने देखा कि 35 अलग-अलग अनुरोध सभी प्रक्रिया में एक बिंदु पर अवरुद्ध हैं। इन सभी SPIDs के पास LATCH_EXसंसाधन पर 50 ms प्रतीक्षा प्रकार के आदेश पर था METADATA_SEQUENCE_GENERATOR (00000010E13CA1A8)। एक SPID के पास यह संसाधन है, और अन्य सभी अवरुद्ध हैं। मुझे वेब खोज पर इस प्रतीक्षा संसाधन के बारे में कुछ भी नहीं मिला।

हम उपयोग कर रहे हैं कि अस्थायी तालिका में एक IDENTITY(1,1)स्तंभ है। क्या ये SPIDs IDENTITY कॉलम की प्रतीक्षा कर रहे हैं? अवरोध को कम करने या समाप्त करने के लिए हम किन तरीकों का उपयोग कर सकते हैं?

सर्वर एक क्लस्टर का हिस्सा है। सर्वर 64-बिट Windows 2008 R2 एंटरप्राइज़ पर 64-बिट SQL Server 2012 मानक संस्करण SP1 चला रहा है। सर्वर में 64 जीबी रैम और 48 प्रोसेसर हैं, लेकिन डेटाबेस केवल 16 का उपयोग कर सकता है क्योंकि यह मानक संस्करण है।

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

अद्यतन 4/23/2013

हमने Microsoft के साथ एक समर्थन मामला खोला है। जैसे ही हम और अधिक सीखेंगे, मैं इस प्रश्न को अद्यतन रखूँगा।

अद्यतन 5/10/2013

SQL सर्वर समर्थन अभियंता सहमत हुए कि वेट आईडी आईडी के कारण थे। IDENTITY को हटाकर वेट को समाप्त किया गया। हम SQL 2008 R2 पर समस्या की नकल नहीं कर सके; यह केवल SQL 2012 पर हुआ।

Comments

क्या प्रक्रिया अनिवार्य रूप से # टेबल की स्थायी तालिका से डेटा की प्रतिलिपि बनाती है, या क्या उस चरण में अतिरिक्त परिवर्तन तर्क हो रहा है?

— जॉन सिगेल

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

— पॉल विलियम्स

Answer 1

यह मानते हुए कि आप समस्या को पहचान के मूल्यों की पीढ़ी को अलग कर सकते हैं (परीक्षण के रूप में उस कॉलम को हटाने की कोशिश करें), जो मैं सुझाऊंगा वह यह है:

1. IDENTITYअंतिम तालिका में कॉलम से संपत्ति निकालें ।
2. प्रत्येक # तालिका में पहचान मान उत्पन्न करें।
3. अंतिम तालिका लोड करते समय, चरण 2 से पहचान मूल्यों के साथ विशेष स्टोर के लिए एक संख्यात्मक पहचानकर्ता को मिलाएं।

इसलिए यदि आपके पास स्टोर आईडी 3 और 4 है, तो आप अंतिम आईडी मानों को इस तरह समाप्त करेंगे:

3000000001
3000000002
3000000003
...
4000000001
4000000002
...

या ऐसा ही कुछ। तुम्हें नया तरीका मिल गया है।

यह IDENTITYअंतिम परिणाम में विशिष्टता को संरक्षित करते हुए पीढ़ी पर क्रमबद्ध करने की आवश्यकता को समाप्त करेगा ।

वैकल्पिक रूप से, प्रक्रिया कैसे काम करती है, इस पर निर्भर करते हुए अंतिम गणना आईडी मानों को # टेबल टेबल में डालें। तब आप एक ऐसा दृश्य बना सकते हैं UNION ALLजो डेटा को कॉपी करने की आवश्यकता को समाप्त करते हुए उन्हें एक साथ जोड़ दे।

Comments

जवाब देने के लिए धन्यवाद। मैं सहमत हूं कि अगर यह समस्या है, तो कुछ निर्मित कुंजी (या बिल्कुल भी कोई कुंजी नहीं) का उपयोग करके इसे ठीक कर सकते हैं। हमने इस मुद्दे के बारे में Microsoft के साथ एक मामला खोला है। मैं यहां परिणाम पोस्ट करूंगा और आपके उत्तर को स्वीकार करूंगा यदि वे सहमत हैं कि समस्या है।

— पॉल विलियम्स

@Paul: कृपया मुझे बताएं; मैं उतना ही उत्सुक हूं। आपकी तरह, मुझे इस कुंडी के बारे में वेब पर कुछ भी पता नहीं चल पाया है, लेकिन यह निश्चित रूप से उचित है कि यह पहचान / अनुक्रम क्रमांकन है। यह टोंटी कहना मुश्किल है या नहीं, हालांकि 30+ थ्रेड्स मूल्यों के लिए प्रतिस्पर्धा करते हैं, यह संभावना है। आप यह देखने में भी मदद कर सकते हैं कि श्रृंखला में (समानांतर में) समानांतर में प्रत्येक # तालिका से प्रतिलिपि बनाने का प्रयास करें।

— जॉन सेगेल

SQL सर्वर इंजीनियर सहमत था कि यह शायद IDENTITYकॉलम था। हमने इसे पहले से ही विस्तृत क्लस्टर इंडेक्स से हटा दिया और कॉलम को पूरी तरह से हटा दिया। यह आवश्यक नहीं था। बाद में, ये LATCH_EX वेट चले गए। हम SQL 2008 R2 पर प्रतीक्षा की नकल नहीं कर सके। समस्या केवल SQL सर्वर 2012 पर हुई।

— पॉल विलियम्स

@Paul: फॉलो अप के लिए धन्यवाद। बहुत ही रोचक। मैं अनुमान लगा रहा हूं कि कोड जो IDENTITYमान उत्पन्न करता है वह 2012 में नई अनुक्रम पीढ़ी के सामान का उपयोग करने के लिए फिर से लिखा गया था। <2012 पर, आप एक अलग कुंडी प्रकार देख सकते हैं, हालांकि अगर कोई पूर्ण मुद्दा नहीं था, तो ऐसा लगता है कि वहाँ था कोड में एक प्रतिगमन। किसी भी घटना में, IDENTITYकॉलम को हटाना सबसे सुरक्षित चीज है।

— जॉन सीगेल

पहचान के बजाय आप एक 'SEQUENCE ’(जो SQL 2012 में नया है) का उपयोग करने की कोशिश कर सकते हैं

— बोगदान मैक्सिम

Answer 2

(फरवरी 2019 अपडेट किया गया)

यह एक पुरानी पोस्ट है, जिसमें कहा गया है कि मैं आखिरकार Microsoft को समझाने में कामयाब रहा कि ऐसा होने वाला तथ्य वास्तव में एक दोष है।

अपडेट: एमएस ने दोष की पुष्टि की और इसे 12628722 का एक बग सौंपा।

मैंने इस पोस्ट को पिछले नवंबर 2018 में देखा था, जब हमने Sql Server 2005 से Sql Server 2017 में अपग्रेड करने के बाद बहुत कुछ भुगतना शुरू किया था। 3.3 मिलियन की एक पंक्ति तालिका जो कि 10 सेकंड लेती थी थोक में डालने के लिए अचानक 10 लेने लगे Identityस्तंभों के साथ तालिकाओं पर मिनट ।

इसके पीछे दो मुद्दे हैं:

1. Microsoft ने Sql Server 2014 में व्यवहार को बदलकर Bulk Inserts को समानांतर चलाने के लिए मजबूर किया - पूर्व संस्करणों में Bulk Inserts को एक सीरियल प्लान दिया गया था।
2. एक बार हमारे 32 कोर बॉक्स के समानांतर चलने के बाद, इंजन ने वास्तव में काम करने की तुलना में एक दूसरे को लॉक करने वाले कोर के साथ अधिक समय बिताया।

मुझे 4 सप्ताह का समय लगा, लेकिन छुट्टियों के ठीक बाद मुझे सैंटा की ओर से एक बेल्ट मिला - पुष्टि की कि मुद्दा वास्तव में एक दोष था।

कुछ संभावित वर्कअराउंड हैं जो हमने तय होने तक पाए:

1. Option (MaxDop 1)क्रमबद्ध योजना में बल्क इंसर्ट को वापस करने के लिए क्वेरी में उपयोग करें ।
2. इसे पहचान कर कॉलम को पहचानें (उदाहरण के लिए Select Cast(MyIdentityColumn As Integer) As MyIdentityColumn)
   • यह पहचान संपत्ति को उपयोग करते समय कॉपी होने से रोकता है SELECT...INTO
3. ऊपर बताए अनुसार पहचान कॉलम को हटा दें।
4. डेटाबेस संगतता मोड को Sql Server 2012 में बदलें या क्रमिक योजना को फिर से स्थापित करने के लिए कम करें।

अपडेट: फिक्स एमएस लागू किया जाएगा एक Serialized योजना का उपयोग करने के लिए इन प्रकार के आवेषण वापस करने के लिए होगा । यह Sql Server 2017 CU14 के लिए योजनाबद्ध है ( Sql Server के अन्य संस्करणों पर कोई खबर नहीं है - क्षमा करें!)। लागू होने पर, ट्रेस फ्लैग 9492 को सर्वर स्तर पर, या इसके माध्यम से चालू करना होगाDBCC TraceOn ।