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

सिंक्रोनस सांख्यिकी अपडेट को ट्रैक करना

परिचय

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

ध्यान दें कि "बहुत अधिक" गैर-विशिष्ट है क्योंकि यह संस्करण के अनुसार भिन्न होता है और क्या ट्रेस फ़्लैग 2371 सक्षम है - विवरण के लिए इस पृष्ठ का AUTO_UPDATE_STATISTICS अनुभाग देखें।

समकालिक सांख्यिकी अपडेट के साथ समस्या

संकलन से पहले आँकड़ों को समकालिक रूप से अद्यतन करना स्पष्ट रूप से देरी का परिचय देता है और क्वेरी को संकलित करने और निष्पादित करने में अधिक समय लेता है। देरी कितनी बड़ी है, यह कई कारकों पर निर्भर करता है, जिनमें शामिल हैं:

  • क्वेरी में शामिल कितनी तालिकाएं "बहुत अधिक परिवर्तन" सीमा तक पहुंच गई हैं
  • उनमें से प्रत्येक तालिका के लिए कितने आंकड़े अपडेट किए जाने हैं क्योंकि वे संकलन के लिए आवश्यक हैं
  • शामिल तालिकाओं में कितनी पंक्तियाँ हैं
  • निर्दिष्ट विकल्प जब प्रत्येक आंकड़ा बनाया गया था (उदाहरण के लिए, FULLSCAN और PERSIST_SAMPLE_PERCENT=ON)

इसलिए, एक यादृच्छिक रूप से विलंब हो सकता है, जो कुछ परिदृश्यों में समस्या पैदा कर सकता है, खासकर यदि किसी एप्लिकेशन में बहुत कम क्वेरी टाइमआउट सेट है।

सिंक्रोनस सांख्यिकी अपडेट से बचना

समकालिक सांख्यिकी अपडेट से बचने के कई तरीके हैं, जैसे:

  • AUTO_UPDATE_STATISTICS को OFF पर सेट करना, जो सभी स्वचालित अपडेट को बंद कर देता है और इसका मतलब है कि पुराने आंकड़ों से उप-इष्टतम क्वेरी योजनाओं की संभावना से बचने के लिए आपको अपना खुद का सांख्यिकी रखरखाव करना होगा।
  • AUTO_UPDATE_STATISTICS_ASYNC को ON पर सेट करना, इसलिए जब ऑप्टिमाइज़र नोटिस करता है कि किसी आँकड़ों को अद्यतन करने की आवश्यकता है, तो यह संकलन के साथ जारी रहता है, और एक पृष्ठभूमि कार्य थोड़ा बाद में आँकड़ों को अद्यतन करता है। यह केवल तभी काम करता है जब आपके पास AUTO_UPDATE_STATISTICS भी चालू हो।
  • नियमित आंकड़ों का रखरखाव करें, ताकि स्वचालित सिंक्रोनस या एसिंक्रोनस आंकड़े अपडेट बिल्कुल न हों।

SQL सर्वर समुदाय में अतुल्यकालिक सांख्यिकी अद्यतनों को सक्षम करने के बारे में बहुत बहस है। मैंने अपनी प्यारी पत्नी, किम्बर्ली एल। ट्रिप से पूछा कि उसकी क्या राय है, और वह हमेशा इसे सक्षम करने की सलाह देती है, और वह आँकड़ों के बारे में अधिक भूल गई है जितना मैं कभी जान पाऊंगा, इसलिए मुझे उस पर विश्वास है।

सिंक्रोनस सांख्यिकी अपडेट ट्रैक करना

यह बताने का कोई स्पष्ट तरीका कभी नहीं रहा है कि क्या किसी क्वेरी में लंबा समय लग रहा था क्योंकि वह एक समकालिक सांख्यिकी अद्यतन की प्रतीक्षा कर रही थी। आप बता सकते हैं *बाद* आंकड़े अपडेट पूरा हो गया था यदि आपके पास एक विस्तारित ईवेंट सत्र पहले से चल रहा था जो auto_stats देख रहा था async . पर ईवेंट और फ़िल्टरिंग कॉलम को 0 पर सेट किया जा रहा है। हालांकि, इवेंट आउटपुट में वह कॉलम केवल SQL सर्वर 2017 में जोड़ा गया था, और आपको एक ऐसी क्रिया को भी कॉन्फ़िगर करना होगा जिसमें शामिल क्वेरी की पहचान करने के लिए कुछ कैप्चर किया गया हो।

अब SQL सर्वर 2019 में, WAIT_ON_SYNCHRONOUS_STATISTICS_UPDATE प्रतीक्षा प्रकार है, और पहली नज़र में ऐसा लगता है कि यह आपको आसानी से यह देखने की अनुमति देगा कि क्या कोई क्वेरी सिंक्रोनस आँकड़ों के अपडेट की प्रतीक्षा कर रही है, यह देखने के लिए कि वर्तमान में क्वेरी क्या है। इंतज़ार कर रहा है।

दुर्भाग्य से, ऐसा नहीं है।

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

यह इतनी बड़ी बात क्यों है? ठीक है, DMV sys.dm_os_waiting_tasks उन सभी थ्रेड्स के लिए प्रतीक्षा प्रकार दिखाता है जो *वास्तव में* प्रतीक्षा कर रहे हैं, अर्थात, शेड्यूलर की प्रतीक्षा कार्य सूची पर, इसलिए यदि सिंक्रोनस स्टैटिस्टिक्स अपडेट थ्रेड WAIT_ON_SYNCHRONOUS_STATISTICS_UPDATE की प्रतीक्षा नहीं कर रहा है, तो वह प्रतीक्षा प्रकार DMV के आउटपुट में दिखाई नहीं देगा। नए प्रतीक्षा प्रकार का उपयोग यह देखने के लिए नहीं किया जा सकता है कि कोई क्वेरी वर्तमान में आंकड़ों के अद्यतन की प्रतीक्षा कर रही है या नहीं।

आप निम्न कार्य करके इसे आसानी से स्वयं सिद्ध कर सकते हैं:

  • कुछ लाख पंक्तियों वाली एक तालिका बनाएं
  • तालिका कॉलम पर एक आंकड़ा बनाएं, और FULLSCAN और PERSIST_SAMPLE_PERCENT =ON को विकल्प के रूप में निर्दिष्ट करें, हर बार आंकड़े अपडेट होने पर पूरी तालिका को पढ़ने के लिए मजबूर करें
  • बीस हजार पंक्तियों को अपडेट करें
  • डेटाबेस की जांच करें और DBCC DROPCLEANBUFFERS निष्पादित करें
  • आपके द्वारा बनाए गए आंकड़े के साथ कॉलम पर WHERE क्लॉज के साथ एक सेलेक्ट स्टेटमेंट करें
  • सेलेक्ट के सत्र आईडी के लिए sys.dm_os_waiting_tasks DMV में देखें, और आप देखेंगे कि यह संभवतः PAGEIOLATCH_SH की प्रतीक्षा कर रहा है क्योंकि आंकड़े अपडेट तालिका के माध्यम से पढ़े जाते हैं

एक तरफ निराश होने के साथ, यह देखने में सक्षम होने के लिए एक तरकीब है कि क्या कोई क्वेरी सिंक्रोनस सांख्यिकी अपडेट की प्रतीक्षा कर रही है। जब कोई सांख्यिकी अद्यतन होता है, तो STATMAN नामक एक कमांड चलता है, और आप इसे sys.dm_exec_requests से आउटपुट में होते हुए देख सकते हैं। :स्थिति "निलंबित" होगा (भले ही थ्रेड चल रहा हो, जैसा कि मैंने ऊपर वर्णित किया है), और कमांड "सेलेक्ट (स्टेटमैन)" होगा।

नए प्रतीक्षा प्रकार का क्या उपयोग है?

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

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

सारांश

मुझे यकीन नहीं है कि WAIT_ON_SYNCHRONOUS_STATISTICS_UPDATE प्रतीक्षा प्रकार को जोड़ने से यह बदलने वाला है कि क्या लोग एसिंक्रोनस सांख्यिकी अपडेट को कॉन्फ़िगर करते हैं या केवल सभी आँकड़ों का रखरखाव स्वयं करते हैं, लेकिन कम से कम अब आप यह बता पाएंगे कि क्या क्वेरीज़ सिंक्रोनस आँकड़ों की प्रतीक्षा कर रही हैं। अपडेट करें और कुछ और कार्रवाई करें।

अगली बार तक, सुखद प्रदर्शन समस्या निवारण!


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. डेटाबेस रीऑर्ग्स - वे क्यों मायने रखते हैं?

  2. सूचना प्रणाली, डेटा और सूचना

  3. Django प्रवासन में गहरी खुदाई

  4. SQL INSERT क्वेरी में डुप्लीकेट रिकॉर्ड डालने से कैसे बचें (5 आसान तरीके)

  5. बिग डेटा तेजी से लोड हो रहा है