ग्रीष्मकालीन प्रदर्शन पलूजा 2013 पर अनुवर्ती कार्रवाई

27 जून को, PASS परफॉर्मेंस वर्चुअल चैप्टर ने अपने 2013 के समर परफॉर्मेंस पलूजा का आयोजन किया - एक तरह का 24 घंटे का पास, लेकिन पूरी तरह से प्रदर्शन से संबंधित विषयों पर ध्यान केंद्रित किया। मैंने एक सत्र दिया, जिसका शीर्षक था, "10 बुरी आदतें जो प्रदर्शन को खराब कर सकती हैं," निम्नलिखित 10 अवधारणाओं का इलाज करते हुए:

1. चुनें*
2. ब्लाइंड इंडेक्स
3. कोई स्कीमा उपसर्ग नहीं
4. डिफ़ॉल्ट कर्सर विकल्प
5. sp_ उपसर्ग
6. कैश ब्लोट की अनुमति देना
7. विस्तृत डेटा प्रकार
8. SQL सर्वर डिफ़ॉल्ट
9. कार्यों का अत्यधिक उपयोग
10. "मेरी मशीन पर काम करता है"

आप मेरी "बुरी आदतें और सर्वोत्तम अभ्यास" वार्ता या हमारे साप्ताहिक क्वेरी ट्यूनिंग वेबिनार जैसी प्रस्तुतियों से इनमें से कुछ विषयों को याद कर सकते हैं जिन्हें मैं केविन क्लाइन के साथ इस सप्ताह की शुरुआत से होस्ट कर रहा हूं। (वैसे, वे 6 वीडियो अगस्त की शुरुआत में YouTube पर उपलब्ध होंगे।)

मेरे सत्र में 351 उपस्थित थे, और मुझे बहुत अच्छी प्रतिक्रिया मिली। मैं उसमें से कुछ को संबोधित करना चाहता था।

सबसे पहले, एक कॉन्फ़िगरेशन समस्या:मैं एक बिल्कुल नए माइक्रोफ़ोन का उपयोग कर रहा था, और मुझे नहीं पता था कि प्रत्येक कीस्ट्रोक गड़गड़ाहट की तरह ध्वनि करेगा। मैंने अपने बाह्य उपकरणों के बेहतर प्लेसमेंट के साथ उस मुद्दे का समाधान किया है, लेकिन मैं इससे प्रभावित सभी लोगों से माफी मांगना चाहता हूं।

अगला, डाउनलोड; डेक और नमूने घटना स्थल पर पोस्ट किए जाते हैं। वे पृष्ठ में सबसे नीचे हैं, लेकिन आप उन्हें यहीं से डाउनलोड भी कर सकते हैं।

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

ए: आपको मामला-दर-मामला आधार पर इस तक पहुंचना होगा, क्योंकि यह वास्तव में विभिन्न कारकों (योजना की जटिलता सहित) पर निर्भर करेगा। यह भी ध्यान दें कि आप स्टेटमेंट-लेवल रीकंपाइल कर सकते हैं जैसे कि पूरे मॉड्यूल के विपरीत केवल प्रभावित स्टेटमेंट को हिट लेना पड़ता है। पॉल व्हाइट ने मुझे याद दिलाया कि लोग अक्सर RECOMPILE के साथ सूँघने वाले पैरामीटर को 'फिक्स' करते हैं , लेकिन अक्सर इसका अर्थ होता है 2000-शैली WITH RECOMPILE बेहतर OPTION (RECOMPILE) . के बजाय , जो न केवल स्वयं को कथन तक सीमित रखता है, बल्कि पैरामीटर एम्बेडिंग को भी सक्षम बनाता है, जो WITH RECOMPILE नहीं करता। इसलिए, यदि आप RECOMPILE . का उपयोग करने जा रहे हैं पैरामीटर सूँघने को विफल करने के लिए, इसे कथन में जोड़ें, न कि मॉड्यूल।

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

ए: मुझे यकीन नहीं है कि "वास्तविक दुनिया में पठनीय" का क्या अर्थ है। यदि आपका मतलब है कि आप एक विशिष्ट प्रारूप में आउटपुट चाहते हैं, तो आप आमतौर पर क्लाइंट साइड पर एक स्ट्रिंग में कनवर्ट करने से बेहतर होते हैं। C# और अधिकांश अन्य भाषाएँ जिनका आप प्रेजेंटेशन टियर में उपयोग कर रहे हैं, डेटाबेस से दिनांक/समय आउटपुट को किसी भी क्षेत्रीय प्रारूप में स्वरूपित करने में सक्षम हैं।

ए: अधिकांश DMV केवल अंतिम सेवा शुरू होने के बाद से ही मान्य होते हैं, और यहां तक ​​कि दूसरों को भी अधिक बार फ्लश किया जा सकता है (मांग पर भी - अनजाने में और उद्देश्य पर)। योजना कैश, निश्चित रूप से, निरंतर प्रवाह में है, और AFAIK योजनाएं जो कैश से बाहर निकलती हैं, यदि वे वापस पॉप करते हैं तो उनकी पिछली गिनती को बनाए नहीं रखते हैं। इसलिए जब भी आप कैश में कोई योजना देखते हैं तो मैं 100% नहीं हूं विश्वास है कि आप उपयोग की गई संख्या पर विश्वास कर सकते हैं।

उस ने कहा, जो आप शायद खोज रहे हैं वह है sys.dm_exec_cached_plans.usecounts और आपको sys.dm_exec_procedure_stats.execution_count भी मिल सकता है प्रक्रियाओं के लिए पूरक जानकारी में मदद करने के लिए जहां प्रक्रियाओं के भीतर अलग-अलग बयान कैश में नहीं मिलते हैं।

ए: इसके आस-पास की मुख्य चिंता कुछ सिंटैक्स का उपयोग करने की क्षमता है, जैसे कि OUTER APPLY या तालिका-मूल्यवान फ़ंक्शन वाले चर। मुझे ऐसे किसी भी मामले की जानकारी नहीं है जहां कम संगतता का उपयोग करने से प्रदर्शन पर कोई सीधा प्रभाव पड़ता है, लेकिन आमतौर पर अनुशंसित कुछ चीजें इंडेक्स का पुनर्निर्माण और आंकड़े अपडेट करना (और अपने विक्रेता को नए संगतता स्तर ASAP का समर्थन करने के लिए) प्राप्त करना है। मैंने देखा है कि यह कई मामलों में अप्रत्याशित प्रदर्शन गिरावट का समाधान करता है, लेकिन मैंने कुछ राय भी सुनी हैं कि ऐसा करना आवश्यक नहीं है और शायद नासमझी भी है।

ए: नहीं, कम से कम प्रदर्शन के मामले में, एक अपवाद जहां SELECT * कोई फर्क नहीं पड़ता जब एक EXISTS के अंदर उपयोग किया जाता है खंड। लेकिन आप * का उपयोग क्यों करेंगे? यहाँ? मैं EXISTS (SELECT 1 ... - ऑप्टिमाइज़र उन लोगों के साथ समान व्यवहार करेगा, लेकिन एक तरह से यह कोड को स्व-दस्तावेज करता है और यह सुनिश्चित करता है कि पाठक समझते हैं कि सबक्वेरी कोई डेटा वापस नहीं करता है (भले ही वे बड़े EXISTS को याद करते हैं। बाहर)। कुछ लोग NULL . का उपयोग करते हैं , और मुझे नहीं पता कि मैंने 1 का उपयोग क्यों शुरू किया, लेकिन मुझे NULL मिलता है थोड़ा सहज भी।

*नोट* यदि आप EXISTS (SELECT * . का उपयोग करने का प्रयास करते हैं, तो आपको सावधान रहने की आवश्यकता होगी एक मॉड्यूल के अंदर जो स्कीमा-बाउंड है:

CREATE VIEW dbo.ThisWillNotWork
WITH SCHEMABINDING
AS
  SELECT BusinessEntityID
    FROM Person.Person AS p
	WHERE EXISTS (SELECT * FROM Sales.SalesOrderHeader AS h
	  WHERE h.SalesPersonID = p.BusinessEntityID);

आपको यह त्रुटि मिलती है:

हालांकि इसे SELECT 1 . में बदल रहे हैं ठीक काम करता है। तो हो सकता है कि SELECT * . से बचने के लिए यह एक और तर्क हो उस परिदृश्य में भी।

ए: विभिन्न भाषाओं में शायद सैकड़ों हैं। नामकरण परंपराओं की तरह, कोडिंग मानक एक बहुत ही व्यक्तिपरक चीज हैं। यह वास्तव में कोई फर्क नहीं पड़ता कि आप कौन सा सम्मेलन तय करते हैं जो आपके लिए सबसे अच्छा काम करता है; अगर आपको tbl पसंद है उपसर्ग, पागल हो जाओ! बिगएंडियन पर पास्कल को प्राथमिकता दें, इसे लें। अपने कॉलम नामों को डेटा प्रकार, जैसे intCustomerID . के साथ उपसर्ग करना चाहते हैं , मैं तुम्हें रोकने वाला नहीं हूँ। अधिक महत्वपूर्ण बात यह है कि आप एक सम्मेलन को परिभाषित करते हैं और इसे *लगातार नियोजित करते हैं।*

उन्होंने कहा, अगर आप मेरी राय चाहते हैं, तो मेरे पास उनकी कोई कमी नहीं है।

ए: मुझे XACT_ABORT . को हटाने की किसी योजना के बारे में पता नहीं है इसलिए इसे ठीक काम करना जारी रखना चाहिए। सच कहूं तो मुझे अब यह बहुत बार उपयोग होता नहीं दिख रहा है कि हमारे पास TRY / CATCH है (और THROW SQL सर्वर 2012 के अनुसार)।

ए: मैंने इसका परीक्षण नहीं किया, लेकिन कई मामलों में एक स्केलर फ़ंक्शन को इनलाइन तालिका-मूल्यवान फ़ंक्शन के साथ बदलने से प्रदर्शन पर बहुत प्रभाव पड़ सकता है। मुझे जो समस्या मिलती है वह यह है कि इस स्विच को बनाने से सिस्टम पर पर्याप्त मात्रा में काम हो सकता है जो APPLY से पहले लिखा गया था। अस्तित्व में है, या अभी भी उन लोगों द्वारा प्रबंधित किया जाता है जिन्होंने इस बेहतर दृष्टिकोण को नहीं अपनाया है।

ए: दो चीजें दिमाग में आती हैं:(1) देरी को संकलन समय के साथ करना पड़ता है या (2) देरी को डेटा की मात्रा के साथ करना पड़ता है जो क्वेरी को संतुष्ट करने के लिए लोड किया जा रहा है, और पहली बार डिस्क से आना है और स्मृति नहीं। (1) के लिए आप SQL संतरी योजना एक्सप्लोरर में क्वेरी निष्पादित कर सकते हैं और स्टेटस बार आपको पहले और बाद के आमंत्रणों के लिए संकलन समय दिखाएगा (हालांकि इसके लिए एक मिनट अधिक लगता है, और असंभव है)। यदि आपको कोई अंतर नहीं मिलता है, तो यह केवल सिस्टम की प्रकृति हो सकती है:डेटा की मात्रा का समर्थन करने के लिए अपर्याप्त मेमोरी जिसे आप इस क्वेरी के साथ अन्य डेटा के संयोजन में लोड करने का प्रयास कर रहे हैं जो पहले से ही बफर पूल में था। यदि आपको विश्वास नहीं है कि इनमें से कोई भी समस्या है, तो देखें कि क्या दो अलग-अलग निष्पादन वास्तव में अलग-अलग योजनाएँ बनाते हैं - यदि कोई अंतर है, तो योजनाओं को answer.sqlperformance.com पर पोस्ट करें और हमें एक नज़र डालने में खुशी होगी . वास्तव में किसी भी स्थिति में प्लान एक्सप्लोरर का उपयोग करके दोनों निष्पादन के लिए वास्तविक योजनाओं को कैप्चर करना आपको I/O में किसी भी अंतर के बारे में भी बता सकता है और जहां SQL सर्वर अपना समय पहले, धीमी गति से खर्च कर रहा है, वहां ले जा सकता है।

ए: नहीं, मुझे नहीं लगता कि तदर्थ कार्यभार के लिए ऑप्टिमाइज़ सेटिंग इस परिदृश्य में मदद करेगी, क्योंकि पैरामीटर सूँघने का अर्थ है कि एक ही योजना के बाद के निष्पादन का उपयोग विभिन्न मापदंडों के लिए और काफी भिन्न प्रदर्शन व्यवहारों के साथ किया जाता है। तदर्थ कार्यभार के लिए ऑप्टिमाइज़ का उपयोग योजना कैश पर भारी प्रभाव को कम करने के लिए किया जाता है जो तब हो सकता है जब आपके पास विभिन्न SQL कथनों की संख्या अधिक हो। इसलिए जब तक आप sp_executesql पर भेजे जा रहे कई अलग-अलग स्टेटमेंट के प्लान कैश पर प्रभाव के बारे में बात नहीं कर रहे हैं - जिसे पैरामीटर सूँघने के रूप में वर्णित नहीं किया जाएगा - मुझे लगता है कि OPTION (RECOMPILE) के साथ प्रयोग करना एक बेहतर परिणाम हो सकता है या, यदि आप पैरामीटर मानों को जानते हैं जो विभिन्न पैरामीटर संयोजनों में *do* अच्छे परिणाम देते हैं, तो OPTIMIZE FOR का उपयोग करें . पॉल व्हाइट का यह उत्तर बेहतर अंतर्दृष्टि प्रदान कर सकता है।

ए: बिल्कुल, बस OPTION (RECOMPILE) शामिल करें गतिशील SQL पाठ में:

DBCC FREEPROCCACHE;
 
USE AdventureWorks2012;
GO
SET NOCOUNT ON;
GO
 
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderHeader;';
GO
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderDetail OPTION (RECOMPILE);'
GO
 
SELECT t.[text], p.usecounts
FROM sys.dm_exec_cached_plans AS p
CROSS APPLY sys.dm_exec_sql_text(p.[plan_handle]) AS t
WHERE t.[text] LIKE N'%Sales.' + 'SalesOrder%';

परिणाम:Sales.SalesOrderHeader . दिखाने वाली 1 पंक्ति सवाल।

अब, यदि बैच में किसी स्टेटमेंट में OPTION (RECOMPILE) शामिल नहीं है , योजना अभी भी कैश की जा सकती है, इसे फिर से उपयोग नहीं किया जा सकता है।

DBCC FREEPROCCACHE(0x06.....);