कभी भी क्वेरी स्टोर की खोज समाप्त न करें

Question

मैं शुरू से कहूंगा कि मेरा प्रश्न / समस्या इस पहले की तरह ही है, लेकिन चूंकि मुझे यकीन नहीं है कि यदि कारण या शुरुआती जानकारी समान है, तो मैंने अपने प्रश्न को कुछ और विवरणों के साथ पोस्ट करने का निर्णय लिया।

मुद्दे पर हाथ:

• एक अजीब घंटे (व्यवसाय के दिन के अंत के पास) एक उत्पादन उदाहरण के लिए गलत व्यवहार करना शुरू कर देता है:
  • उदाहरण के लिए उच्च CPU (~ 30% की आधार रेखा से यह लगभग दोगुना हो गया और अभी भी बढ़ रहा है)
  • लेनदेन / सेकंड की संख्या में वृद्धि (हालांकि ऐप लोड में कोई बदलाव नहीं हुआ है)
  • निष्क्रिय सत्रों की संख्या में वृद्धि
  • इस व्यवहार को प्रदर्शित करने वाले सत्रों के बीच अजीब अवरुद्ध घटनाएं (यहां तक ​​कि बिना पढ़े सत्र अवरुद्ध होने का कारण थे)
  • अंतराल के लिए शीर्ष प्रतीक्षा 1 स्थान पर गैर पृष्ठ कुंडी थी, जिसमें ताले दूसरे स्थान पर थे

प्रारंभिक जांच:

• sp_whoIsActive का उपयोग करते हुए हमने देखा कि हमारे निगरानी उपकरण द्वारा निष्पादित एक क्वेरी बेहद धीमी गति से चलती है और बहुत सारे सीपीयू हड़पती है, ऐसा कुछ जो पहले नहीं हुआ था;
• इसका अलगाव स्तर बिना पढ़े था;
• हमने उस योजना को देखा जिसे हमने निराला संख्याओं में देखा था: स्टेटमेंटस्ट्रो = "3.86846e + 010" जिसमें अनुमानित 150 टीबी का कुछ डेटा वापस किया जाए।
• हमें संदेह था कि निगरानी उपकरण का एक क्वेरी मॉनिटर फीचर कारण था, इसलिए हमने सुविधा को निष्क्रिय कर दिया (हमने किसी भी मुद्दे के बारे में पता करने के लिए हमारे प्रदाता के साथ एक टिकट खोला है)
• उस पहली घटना से, यह कुछ और बार हुआ, हर बार जब हम सत्र को मारते हैं, तो सब कुछ सामान्य हो जाता है;
• हमें एहसास है कि क्वेरी बीओएल में क्वेरी स्टोर की निगरानी के लिए एमएस द्वारा उपयोग किए गए प्रश्नों में से एक के समान है - प्रश्न जो हाल ही में प्रदर्शन में पुन: प्राप्त हुए (समय में विभिन्न बिंदुओं की तुलना करते हुए)
• हम एक ही क्वेरी को मैन्युअल रूप से चलाते हैं और एक ही व्यवहार देखते हैं (सीपीयू कभी बढ़ रहा है, कुंडी का इंतजार बढ़ रहा है, अप्रत्याशित ताले .. आदि)

दोषी प्रश्न:

Select qt.query_sql_text, 
    q.query_id, 
    qt.query_text_id, 
    rs1.runtime_stats_id AS runtime_stats_id_1,
    interval_1 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi1.start_time), 
    p1.plan_id AS plan_1, 
    rs1.avg_duration AS avg_duration_1, 
    rs2.avg_duration AS avg_duration_2,
    p2.plan_id AS plan_2, 
    interval_2 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi2.start_time), 
    rs2.runtime_stats_id AS runtime_stats_id_2
From sys.query_store_query_text AS qt 
Inner Join sys.query_store_query AS q 
    ON qt.query_text_id = q.query_text_id 
Inner Join sys.query_store_plan AS p1 
    ON q.query_id = p1.query_id 
Inner Join sys.query_store_runtime_stats AS rs1 
    ON p1.plan_id = rs1.plan_id 
Inner Join sys.query_store_runtime_stats_interval AS rsi1 
    ON rsi1.runtime_stats_interval_id = rs1.runtime_stats_interval_id 
 Inner Join sys.query_store_plan AS p2 
    ON q.query_id = p2.query_id 
Inner Join sys.query_store_runtime_stats AS rs2 
    ON p2.plan_id = rs2.plan_id 
Inner Join sys.query_store_runtime_stats_interval AS rsi2 
    ON rsi2.runtime_stats_interval_id = rs2.runtime_stats_interval_id
Where rsi1.start_time > DATEADD(hour, -48, GETUTCDATE()) 
    AND rsi2.start_time > rsi1.start_time 
    AND p1.plan_id <> p2.plan_id
    AND rs2.avg_duration > rs1.avg_duration * 2
Order By q.query_id, rsi1.start_time, rsi2.start_time

सेटिंग्स और जानकारी:

• Windows Server 2012R2 क्लस्टर पर SQL Server 2016 SP1 CU4 एंटरप्राइज़
• क्वेरी स्टोर डिफ़ॉल्ट के रूप में सक्षम और कॉन्फ़िगर किया गया (कोई सेटिंग नहीं बदली गई)
• डेटाबेस SQL ​​2005 उदाहरण से आयात किया गया (और अभी भी संगतता स्तर 100 पर)

अनुभवजन्य अवलोकन:

• अत्यंत निराला आँकड़ों के कारण, हमने सभी * plan_persist ** वस्तुओं को बुरी अनुमानित योजना में इस्तेमाल किया (अभी तक कोई वास्तविक योजना नहीं है, क्वेरी कभी समाप्त नहीं हुई) और आँकड़ों की जाँच की, योजना में उपयोग किए गए कुछ इंडेक्स में कोई आँकड़े नहीं थे (DBCC SHOWSTATISTICS ने कुछ भी नहीं लौटाया, sys.stats में से चयन करें कुछ अनुक्रमितों के लिए NULL आँकड़े_डेट () फ़ंक्शन दिखाया

त्वरित और गंदा समाधान:

• क्वेरी स्टोर से संबंधित सिस्टम ऑब्जेक्ट्स पर मैन्युअल रूप से लापता आंकड़े बनाएं या
• नए CE (ट्रेसफ्लैग) का उपयोग करके चलाने के लिए क्वेरी को बाध्य करें - जो आवश्यक आँकड़े भी बनाएगा / अपडेट करेगा
• डेटाबेस की संगतता स्तर को 130 में बदलें (इसलिए यह डिफ़ॉल्ट रूप से नए CE का उपयोग करेगा)

तो, मेरा असली सवाल यह होगा:

क्वेरी स्टोर पर एक क्वेरी पूरे उदाहरण पर प्रदर्शन समस्याओं का कारण क्यों बनेगी? क्या हम क्वेरी स्टोर वाले बग क्षेत्र में हैं?

पुनश्च: मैं कुछ फ़ाइलों (प्रिंट स्क्रीन, IO आँकड़े और योजनाएं) को थोड़े समय में अपलोड करूँगा।

ड्रॉपबॉक्स पर फ़ाइलें जोड़ी गईं ।

योजना 1 - उत्पादन में प्रारंभिक निराला अनुमानित योजना

योजना 2 - वास्तविक योजना, पुरानी CE, एक परीक्षण env में (एक ही व्यवहार, एक ही निराला आँकड़े)

योजना 3 - परीक्षण योजना में वास्तविक योजना, नया सीई

Comments

हमने क्वेरी स्टोर को अक्षम करना समाप्त कर दिया है, हम यह सुनिश्चित करते हैं कि मूल कारण क्या था (हमारे पास निश्चित रूप से 1 से अधिक समस्या थी)। मेरे अंत में, सीपीयू क्वेरी स्टोर से आंकड़े प्रदर्शित करने के लिए हमारे द्वारा क्लिक की गई हर चीज को रैंप पर ले जाएगा।

— a_V

Answer 1

जैसा कि मैंने उत्तर में कहा, अनुभवजन्य परीक्षण से पता चला है कि उनके ऊपर बनाए गए (कोई भी) आंकड़ों के बिना sys.plan_persisted * सिस्टम ऑब्जेक्ट पर अनुक्रमित थे। मुझे संदेह है कि डेटाबेस SQL ​​2005 उदाहरण से माइग्रेट किया गया है, और संगतता स्तर 100 पर थोड़ी देर के लिए रखा जाता है, इस प्रकार नए सीई का उपयोग करने के लिए नहीं मिला।

पंक्ति की जाँच करें:

Select count(1) from NoNameDB.sys.plan_persist_runtime_stats with (nolock) --60362   
Select count(1) from NoNameDB.sys.plan_persist_plan with (nolock) --1853    
Select count(1) from NoNameDB.sys.plan_persist_runtime_stats_interval with (nolock) --671    
Select count(1) from NoNameDB.sys.plan_persist_query with (nolock) --1091    
Select count(1) from NoNameDB.sys.plan_persist_query_text with (nolock) --911

इससे पता चला कि शुरुआती अनुमान गलत थे। DAC कनेक्शन के साथ किया, अन्यथा तालिकाएँ क्वेरी के लिए उपलब्ध नहीं हैं।

आँकड़े जाँच:

DBCC SHOW_STATISTICS ('sys.plan_persist_runtime_stats_interval', plan_persist_runtime_stats_interval_cidx);    
DBCC SHOW_STATISTICS ('sys.plan_persist_runtime_stats', plan_persist_runtime_stats_idx1);    
DBCC SHOW_STATISTICS ('sys.plan_persist_runtime_stats', plan_persist_runtime_stats_cidx);    
DBCC SHOW_STATISTICS ('sys.plan_persist_plan', plan_persist_plan_cidx);    
DBCC SHOW_STATISTICS ('sys.plan_persist_plan', plan_persist_plan_idx1);    
DBCC SHOW_STATISTICS ('sys.plan_persist_query', plan_persist_query_cidx)    
DBCC SHOW_STATISTICS ('sys.plan_persist_query_text', plan_persist_query_text_cidx);

इससे पता चला कि कुछ अनुक्रमों में खाली आँकड़े थे (लापता, कोई नहीं, शून्य)।

प्रारंभिक सुधार:

UPDATE STATISTICS sys.plan_persist_runtime_stats WITH fullscan;
UPDATE STATISTICS sys.plan_persist_plan WITH fullscan;
UPDATE STATISTICS sys.plan_persist_runtime_stats_interval WITH fullscan;
UPDATE STATISTICS sys.plan_persist_query WITH fullscan;
UPDATE STATISTICS sys.plan_persist_query_text WITH fullscan;

इस तरह के निश्चित आँकड़े और क्वेरी को 10-12 सेकंड में पूरा किया।

दूसरा फिक्स :

(केवल एक परीक्षण वातावरण पर सत्यापित) और सबसे अधिक संभावना एक उचित है, क्योंकि इसमें क्वेरी के लिए सबसे अच्छे आँकड़े दिखाए गए थे, डेटाबेस की संगतता के स्तर को 130 में बदलना था। अंतिम परिणाम यह था कि क्वेरी लगभग 10-12 सेकंड में समाप्त हो गई थी सामान्य संख्या आँकड़े (10k पंक्तियाँ)।

इंटरमीडिएट तय :

DBCC TRACEON (2312) -- new CE

सिस्टम से संबंधित टेबल पर आँकड़ों के बारे में कुछ संबंधित मदद ।

Answer 2

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

इससे कोई फर्क नहीं पड़ता कि इन टीवीएफ से कितनी पंक्तियाँ वापस की जाती हैं, जितनी बार वे पहुँचते हैं। फिक्स वह होगा जो आप अपनी योजनाओं को कई बार पढ़ने से दूर रखने के लिए कर सकते हैं।

मेरे सीमित डिबगिंग (कौशल और समय दोनों में खर्च) के आधार पर, मेरी परिकल्पना यह है कि क्वेरी स्टोर डेटा के विशेष-मेमोरी घटक के लिए सौंपी गई मेमोरी की संपूर्णता को प्रत्येक टीवीएफ निष्पादन के साथ स्कैन किया जाता है। मैं sp_query_store_flush_dbया तो के साथ इस मेमोरी आवंटन को प्रभावित करने में सक्षम नहीं हूं DBCC FREESYSTEMCACHE।

अब तक के सफल वर्कअराउंड में प्लान गाइड, हिंटिंग ( OPTION(HASH JOIN, LOOP JOIN)मेरे लिए अब तक काफी अच्छा काम किया है), और एजी के रीड-ओनली नोड पर क्वेरी स्टोर के प्रश्नों को चलाना शामिल है।