IndexOptimize के बाद क्वेरीज़ और अपडेट्स बेहद धीमी

डेटाबेस SQL सर्वर 2017 एंटरप्राइज़ CU16 14.0.3076.1

हमने हाल ही में डिफॉल्ट इंडेक्स रिब्यूटी मेंटेनेंस जॉब्स से ओला हॉलनग्रेन में स्विच करने की कोशिश की IndexOptimize। डिफ़ॉल्ट सूचकांक पुनर्निर्माण नौकरियां बिना किसी मुद्दे के कुछ महीनों से चल रही थीं, और क्वेरी और अपडेट स्वीकार्य निष्पादन समय के साथ काम कर रहे थे। IndexOptimizeडेटाबेस पर चलने के बाद :

EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y'

प्रदर्शन बेहद खराब था। एक अपडेट स्टेटमेंट जिसने पहले IndexOptimize100.000 लिया था बाद में 78.000ms (एक समान योजना का उपयोग करके) लिया, और प्रश्न भी परिमाण के कई आदेशों को खराब कर रहे थे।

चूंकि यह अभी भी एक परीक्षण डेटाबेस है (हम ओरेकल से एक उत्पादन प्रणाली को स्थानांतरित कर रहे हैं) हम एक बैकअप और अक्षम पर IndexOptimizeवापस लौट आए और सब कुछ सामान्य पर लौट आया।

हालांकि, हम यह समझना चाहते हैं कि IndexOptimize"सामान्य" से अलग क्या होता है Index Rebuildजो इस चरम प्रदर्शन में गिरावट का कारण बन सकता है ताकि हम उत्पादन में जाने से पहले इसे टाल सकें। क्या देखने के लिए कोई सुझाव बहुत सराहना की जाएगी।

धीमी गति से होने पर अपडेट स्टेटमेंट के लिए निष्पादन योजना। यानी
IndexOptimize के बाद
वास्तविक कार्य योजना लागू करके (asap आ रहा है)

मैं एक अंतर हाजिर नहीं कर पाया।
तेज़ क्वेरी के लिए उसी योजना की योजना बनाएँ जब वह
वास्तविक निष्पादन योजना हो

— मार्टिन बर्गस्ट्रॉम
स्रोत

जवाबों:

मुझे संदेह है कि आपको अपने दो रखरखाव दृष्टिकोणों के बीच एक अलग नमूना दर परिभाषित किया गया है । मेरा मानना है कि ओला की स्क्रिप्ट्स डिफ़ॉल्ट नमूने का उपयोग करती हैं जब तक कि आप @StatisticsSampleपैरामीटर को निर्दिष्ट नहीं करते हैं , जो यह नहीं दिखता है कि आप वर्तमान में क्या कर रहे हैं।

इस बिंदु पर, यह अटकलें हैं, लेकिन आप यह देखने के लिए जांच कर सकते हैं कि वर्तमान में आपके डेटाबेस में निम्नलिखित क्वेरी चलाकर आपके आंकड़ों पर नमूना दर का क्या उपयोग किया जा रहा है:

SELECT  OBJECT_SCHEMA_NAME(st.object_id) + '.' + OBJECT_NAME(st.object_id) AS TableName
    ,   col.name AS ColumnName
    ,   st.name AS StatsName
    ,   sp.last_updated
    ,   sp.rows_sampled
    ,   sp.rows
    ,   (1.0*sp.rows_sampled)/(1.0*sp.rows) AS sample_pct
FROM sys.stats st 
    INNER JOIN sys.stats_columns st_col
        ON st.object_id = st_col.object_id
        AND st.stats_id = st_col.stats_id
    INNER JOIN sys.columns col
        ON st_col.object_id = col.object_id
        AND st_col.column_id = col.column_id
    CROSS APPLY sys.dm_db_stats_properties (st.object_id, st.stats_id) sp
ORDER BY 1, 2

यदि आप देखते हैं कि यह 1s (जैसे 100%) के माध्यम से आ रहा है तो संभावना है कि यह आपका मुद्दा है। हो सकता है कि ओला की स्क्रिप्ट को फिर से कोशिश करें जिसमें @StatisticsSampleपैरामीटर इस प्रतिशत से वापस आ जाए और देखें कि क्या यह आपकी समस्या को ठीक करता है?

इस सिद्धांत के अतिरिक्त सहायक साक्ष्य के रूप में, निष्पादन योजना XML धीमी क्वेरी (2.18233%) के लिए अलग-अलग नमूने दर दिखाती है:

<StatisticsInfo LastUpdate="2019-09-01T01:07:46.04" ModificationCount="0" 
    SamplingPercent="2.18233" Statistics="[INDX_UPP_4]" Table="[UPPDRAG]" 
    Schema="[SVALA]" Database="[ulek-sva]" />

व्रत क्वेरी (100%):

<StatisticsInfo LastUpdate="2019-08-25T23:01:05.52" ModificationCount="555" 
    SamplingPercent="100" Statistics="[INDX_UPP_4]" Table="[UPPDRAG]" 
    Schema="[SVALA]" Database="[ulek-sva]" />

— जॉन आइस्ब्रेनर
स्रोत

@JoshDarnell LOL, यह दूसरी घटना है जहाँ आपको क्वेरी प्लान में कुछ सहायक आँकड़े जानकारी मिली, जिन्हें मैं देखने में असफल रहा। संपादन के लिए धन्यवाद!

— जॉन आइस्ब्रेनर

हाहा मैं भूल गया कि तुम थे, जॉन! मैं वादा करता हूं कि मैं आपको नहीं रोक रहा हूं।

— जोश डारनेल

@JoshDarnell मैं अतिरिक्त अंतर्दृष्टि की सराहना करता हूं और यह एक और अच्छा अनुस्मारक है कि निष्पादन योजनाओं में इतनी जानकारी है कि आप बस इसे छोड़ देना चाहते हैं।

— जॉन एइसब्रेनर

मदद करने में खुशी! और हाँ, वहाँ सामान है जो मुझे हर समय याद आता है (मैं आँकड़ों की बात से जल गया हूँ, इसलिए मैं जल्दी से वहाँ जाता हूँ देखने के लिए कि क्या है)।

— जोश डारनेल

इस स्पष्टीकरण के लिए धन्यवाद, यह वास्तव में समस्या थी। अधिकांश आँकड़ों में डिफ़ॉल्ट नमूना दर 2.2% थी, लेकिन कुछ जो कि Oracle से प्रवासन के बाद बनाए गए थे, नमूना दर 100% थी। ऐसा लगता है कि डिफ़ॉल्ट इंडेक्स का पुनर्निर्माण 100% रखा गया था, लेकिन जब हमने इंडेक्सऑप्टिमाइज़ का उपयोग किया तो उसने 2.2% के डिफॉल्ट को भी लागू किया। @StatisticsSample पैरामीटर को लागू करना और प्रश्नों को फिर से चलाना यह सत्यापित करता है कि समस्या का कारण क्या था।

— मार्टिन बर्गस्ट्रॉम

जॉन का जवाब सही समाधान है, यह सिर्फ एक अतिरिक्त है क्योंकि निष्पादन योजना के कुछ हिस्सों को बदल दिया गया है और उदाहरण के लिए सेंट्री वन प्लान एक्सप्लोरर के साथ मतभेदों को आसानी से कैसे पता लगाया जाए।

IndexOptimize से पहले 100ms लिया गया एक अपडेट स्टेटमेंट बाद में 78.000ms लिया (एक समान योजना का उपयोग करके)

जब आपके प्रदर्शन को नीचा दिखाया गया था, तब सभी क्वेरी योजनाओं को देखते हुए, आप आसानी से अंतरों को देख सकते हैं।

खराब प्रदर्शन

सीपीयू समय और बीता समय के 35 सेकंड से अधिक के दो मायने रखता है

अपेक्षित प्रदर्शन

काफी बेहतर

इस अद्यतन क्वेरी पर मुख्य गिरावट दो बार है:

UPDATE SVALA.INGÅENDEANALYS
                           SET 
                              UPPDRAGAVSLUTAT = @NEW$AVSLUTAT
                        WHERE INGÅENDEANALYS.ID IN 
                           (
                              SELECT IA.ID
                              FROM 
                                 SVALA.INGÅENDEANALYS  AS IA 
                                    JOIN SVALA.INGÅENDEANALYSX  AS IAX 
                                    ON IAX.INGÅENDEANALYS = IA.ID 
                                    JOIN SVALA.ANALYSMATERIAL  AS AM 
                                    ON AM.ID = IA.ANALYSMATERIALID 
                                    JOIN SVALA.ANALYSMATERIALX  AS AMX 
                                    ON AMX.ANALYSMATERIAL = AM.ID 
                                    JOIN SVALA.INSÄNTMATERIAL  AS IM 
                                    ON IM.ID = AM.INSÄNTMATERIALID 
                                    JOIN SVALA.INSÄNTMATERIALX  AS IMX 
                                    ON IMX.INSÄNTMATERIAL = IM.ID
                              WHERE IM.UPPDRAGSID = SVALA.PKGSVALA$STRIPVERSION(@NEW$ID)
                      )

अपमानित प्रदर्शन के साथ इस क्वेरी के लिए निष्पादन योजना

इस अद्यतन क्वेरी की अनुमानित क्वेरी योजना में प्रदर्शन के ख़राब होने पर बहुत अधिक अनुमान हैं:

जबकि वास्तव में (वास्तविक निष्पादन योजना) अभी भी काम करना है, न कि पागल राशि जो अनुमान दिखाती है।

प्रदर्शन पर सबसे बड़ा प्रभाव नीचे दिए गए दो स्कैन और हैश मैच में शामिल होता है:

अपमानित प्रदर्शन # 1 पर वास्तविक स्कैन

अपमानित प्रदर्शन # 2 पर वास्तविक स्कैन

अपेक्षित प्रदर्शन के साथ इस क्वेरी के लिए निष्पादन योजना

जब आप सामान्य अपेक्षित प्रदर्शन के साथ क्वेरी प्लान के अनुमानों (या वास्तविक) की तुलना करते हैं, तो अंतर हाजिर होना आसान होता है।

इसके अलावा, पिछले दो तालिका अभिगम भी नहीं हुए थे:

आपको हैश ज्वाइन पर यह उन्मूलन दिखाई नहीं देता क्योंकि बिल्ड (शीर्ष) इनपुट को पहले हैश तालिका में डाला जाता है। बाद में शून्य मान इस हैश तालिका में जांचे जाते हैं, शून्य मान लौटाते हैं।

— रैंडी वर्टोन्गेन
स्रोत

योजनाओं के विस्तृत विवरण के लिए धन्यवाद, यह मेरी समझ में बहुत मददगार था कि समस्या क्यों हुई। मैं निश्चित रूप से संतरी वन प्लान एक्सप्लोरर पर एक नज़र डालूंगा, यह बहुत उपयोगी लगता है!

— मार्टिन बर्गस्ट्रॉम

@ MartinBergström यह सुनने के लिए बहुत अच्छा है, क्वेरी योजनाओं को प्रदान करने और टिप्पणियों में पूछे गए सभी प्रासंगिक जानकारी के साथ हमें प्रदान करने के लिए धन्यवाद :)। प्लान एक्सप्लोरर के बारे में सबसे अच्छी बात यह है कि यह मुफ़्त है! यह एसएमएस के अंदर से भी काम कर सकता है (निष्पादन योजना पर राइट क्लिक करके "संतरी प्लान एक्सप्लोरर के साथ दृश्य" दबाएं)।

— रैंडी वर्टॉन्गेन

अधिक जानकारी के बिना हम केवल अंधेरे में हल्के ढंग से सूचित किए गए स्टैब्स ले सकते हैं, इसलिए आपको प्रश्न को थोड़ा और प्रदान करने के लिए संपादित करना चाहिए। उदाहरण के लिए, उस अपडेट स्टेटमेंट के लिए जो आपने इंडेक्स मेंटिनेंस ऑपरेशंस ऑपरेशंस से पहले और बाद में दिए हैं, उस प्लान स्टेटमेंट के लिए इंडेक्स स्टैटिस्टिक्स अपडेट होने के कारण प्लान अलग हो सकते हैं ( https://www.brentozar.com/pastetheplan) / इसके लिए उपयोगी है, प्रश्न को भरने के बजाय एक्सएमएल का एक बड़ा हिस्सा हो सकता है या स्क्रीन-ग्रैब दे सकता है जिसमें कुछ प्रासंगिक जानकारी शामिल नहीं है जिसमें योजना का पाठ शामिल है)।

हालांकि बल्ले से दो बहुत आसान अंक:

क्या ऑप्टिमाइज़ रन निश्चित रूप से पूरा हो गया है? यदि आपके परीक्षण IO के साथ लंबे समय से चल रहे सूचकांक के साथ प्रतिस्पर्धा कर रहे हैं, तो यह समय को प्रभावित करेगा।
क्या आपने कई बार परीक्षा दी? यदि अद्यतन उस क्वेरी के डेटा पर आधारित है, जो बहुत सारे डेटा पर विचार करता है (एक साधारण `अद्यतन के बजाय यह सेट करें = 'एक स्थैतिक मूल्य') तो यह हो सकता है कि यह डेटा सामान्य रूप से स्मृति में है, लेकिन इसमें फ़्लश हो गया है जिसमें संबंधित प्रश्नों के पहले रन स्मृति के बफ़र पूल में पहले से ही आवश्यक पृष्ठों को खोजने के बजाय डिस्क से टकराने के कारण सामान्य से अधिक धीमे होंगे ।

— डेविड स्पिलेट
स्रोत

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

— मार्टिन बर्गस्ट्रॉम

"कई बार" द्वारा, मैं इंडेक्स में बदलाव के स्क्रिप्ट को एक बार इंडेक्स ऑप्टिमाइज़ेशन स्क्रिप्ट को कई बार स्वतंत्र रूप से चलाने के बजाय कई बार अपडेट की कोशिश कर रहा था (हालांकि यह परिणाम को सत्यापित करने का एक उपयोगी तरीका है) प्रतिलिपि प्रस्तुत करने योग्य है। यदि मेमोरी फ्लशिंग है (या हिस्सा है) समस्या है तो पहले अपडेट-से-चयन बफर पूल को प्राइम करेंगे ताकि बाद में संभावित रूप से कम आईओ के कारण बाद वाले तेजी से हो जाएंगे।

— डेविड स्पीलेट

माफ़ करना अगर मेरा जवाब अस्पष्ट था। हां हमने कई बार अपडेट की कोशिश की। परीक्षण और परीक्षण के दौरान परीक्षकों द्वारा उपयोग किए जाने वाले डेटाबेस पर मंदी और सुधार के बिना दिन में कई बार चलने वाले प्रश्नों और अद्यतनों को धीमा कर दिया गया।

— मार्टिन बर्गस्ट्रॉम