मैं यह कैसे बता सकता हूं कि एक निश्चित तालिका पर एक प्रविष्टि धीमी क्यों है?


29

मुझे पता है कि SQL टेबल पर एक INSERT किसी भी कारण से धीमा हो सकता है:

  • टेबल पर INSERT ट्रिगर्स का अस्तित्व
  • लागू की जाने वाली बाधाओं के बहुत सारे (आमतौर पर विदेशी कुंजी)
  • जब तालिका के मध्य में एक पंक्ति डाली जाती है तो पृष्ठ खंडित सूचकांक में विभाजित होता है
  • सभी संबंधित गैर-संकुलित अनुक्रमणिकाओं को अद्यतन करना
  • मेज पर अन्य गतिविधि से अवरुद्ध
  • खराब IO प्रतिक्रिया समय लिखें
  • ... कुछ भी मैं याद किया?

मैं कैसे बता सकता हूं कि मेरे विशिष्ट मामले में कौन जिम्मेदार है? मैं पेज स्प्लिट्स बनाम गैर-क्लस्टर इंडेक्स अपडेट बनाम सब कुछ के प्रभाव को कैसे माप सकता हूं?

मेरे पास एक संग्रहित खरीद है जो एक समय में (एक अस्थायी तालिका से) लगभग 10,000 पंक्तियों को सम्मिलित करता है, जिसमें प्रति 10k पंक्तियों के बारे में 90 सेकंड लगते हैं। यह अस्वीकार्य रूप से धीमा है, क्योंकि यह समय-समय पर अन्य स्पिड का कारण बनता है।

मैंने निष्पादन योजना को देखा है, और मैं एफके लुकअप से INSERT CLUSTERED INDEX कार्य और सभी INDEX SEEKS देखता हूं, लेकिन यह अभी भी मुझे यह सुनिश्चित करने के लिए नहीं बताता है कि इसमें इतना समय क्यों लगता है। कोई ट्रिगर नहीं है, लेकिन तालिका में मुट्ठी भर FKeys हैं (जो ठीक से अनुक्रमित प्रतीत होते हैं)।

यह एक SQL 2000 डेटाबेस है।


क्या आपके पास अपने डेटा फ़ाइलों पर स्वतःप्रमाण सक्षम है? वह डिफ़ॉल्ट कॉन्फ़िगरेशन के साथ प्रदर्शन समस्याओं का कारण बन सकता है।
लैरी कोलमैन

क्या हम एक प्रोफाइलर का उपयोग करने के बारे में बात कर रहे हैं? msdn.microsoft.com/en-us/library/ms187929.aspx
गुप्त

@ लॉरी: डेटा फ़ाइलों में महत्वपूर्ण खाली स्थान होता है, इसलिए मेरा मानना ​​है कि डेटा फ़ाइल की वृद्धि कोई समस्या नहीं है। हालांकि, "चीजों को जांचने के लिए" सूची में जोड़ना अच्छा है, हालांकि।
ब्रैडेक

@ user210: कथन को पूरा करने का औचित्य बताता है कि मुझे 90 सेकंड का समय लगा, यह मुझे नहीं बताता। जब तक कि ऐसी अन्य घटनाएँ न हों जिन्हें आप सोचते हैं कि अधिक बताना होगा।
ब्रैडेक

जवाबों:


10

कुछ चीजें जिन्हें आप देख सकते हैं ...

बैच का आकार 10000 से कुछ छोटा करें, जैसे 2000 या 1000 (आपने यह नहीं कहा था कि आपकी पंक्ति का आकार कितना बड़ा है)।

यह देखने के लिए IO आँकड़े चालू करने की कोशिश करें कि FO लुकअप में कितना IO लग रहा है।

जब इंसर्ट हो रहा हो तो इसकी क्या प्रतीक्षा है (master.dbo.sysprocesses)?

यहाँ से शुरू करते हैं और देखते हैं कि हम कहाँ जाते हैं।


2
बैच का आकार कम करने से मदद मिलती है (1000 रिकॉर्ड ~ 25 सेकंड लगते हैं)। हमारे वर्तमान "वर्कअराउंड" होने की संभावना है। मैं देखूंगा कि क्या मैं IO आँकड़े और प्रतीक्षा निर्धारित कर सकता हूं (जब ग्राहक के पास काम करने के लिए फ़ाइल होती है, तो उनके पास प्रक्रिया के लिए एक फ़ाइल होती है, इसलिए मैं हमेशा भविष्यवाणी नहीं कर सकता कि नौकरी वास्तव में कब चलेगी)।
ब्रैडेक

7

ब्रैड,

आपको अपनी क्वेरी के लिए प्रतीक्षा आंकड़ों की जांच करनी चाहिए। SQL2000 के साथ आप उन विवरणों को प्राप्त करने के लिए DBCC SQLPERF ("wastats") सिंटैक्स का उपयोग कर सकते हैं।


6

मैं कह सकता हूं कि किसी क्वेरी के प्रदर्शन का विश्लेषण करते समय मैं क्या देख रहा हूं। शायद यह मदद करता है।

  • क्वेरी निष्पादन योजना का विश्लेषण करें और सूचकांक स्कैन, टेबल स्कैन, एसक्यूएल डेटा प्रकार, समानता के लिए Convert_implicit कार्यों का उपयोग करें।
  • निष्पादन समय देखने और प्रत्येक प्रविष्टि के लिए io लिखने / लिखने के लिए SET STATISTICS IO ON और SET STATISTICS TIME ON के साथ क्वेरी चलाएँ।
  • अपने सत्र स्पिड के लिए sysprocesses से छूट की जाँच करें।
  • प्रोफाइलर चलाएं और मानक टेम्पलेट चुनें। निम्नलिखित का चयन करें: प्रदर्शन आँकड़े (यदि दोहराया गया तो आपकी योजना कई बार संकलित की जाती है - अच्छा नहीं), RPC: पूर्ण, SQL: बैच-कम और SQL: बैचस्टार्टिंग। उन्हें स्तंभ में जोड़े rowcounts बिल्कुल बैच में पंक्तियों की संख्या को देखने के लिए। केवल अपनी क्वेरी देखने के लिए परिणामों को फ़िल्टर करें।
  • अंतिम बार विंडो परफ़ॉर्मेंस से पेज लाइफ एक्सपेक्टेंसी काउंटर इकट्ठा करें और यदि यह 300 (5 मिनट) से कम है तो SQL में मेमोरी कम है। डिस्क काउंटर भी इकट्ठा करें: डिस्क कतार की लंबाई , डिस्क समय (आपकी डेटा फ़ाइलें ड्राइव), डिस्क समय (आपकी लॉग फ़ाइलें ड्राइव) यह देखने के लिए कि डिस्क पर दबाव है या नहीं।

5

प्रयोग करके देखें:

SET STATISTICS IO ON

तथा

SET STATISTICS PROFILE ON

सांख्यिकी IO

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

सांख्यिकी प्रोफ़ाइल

मुख्य रूप से क्वेरी योजना को एक सारणीबद्ध प्रारूप में वापस कर देंगे, फिर आप IO और CPU कॉलम को देख सकते हैं कि क्वेरी में सबसे अधिक लागत क्या है (क्या यह आपके टेम्‍प टेबल पर टेबल स्‍कैन है। बनाम यह आपके द्वारा डालने के लिए सॉर्ट करता है। गुच्छेदार कुंजी, आदि ...)

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.