मेरी पिछली पोस्ट में ("यार, उस #temp तालिका का मालिक कौन है?"), मैंने सुझाव दिया कि SQL सर्वर 2012 और इसके बाद के संस्करण में, आप #temp तालिकाओं के निर्माण की निगरानी के लिए विस्तारित ईवेंट का उपयोग कर सकते हैं। यह आपको tempdb में बहुत अधिक स्थान लेने वाली विशिष्ट वस्तुओं को उस सत्र के साथ सहसंबंधित करने की अनुमति देगा जिसने उन्हें बनाया था (उदाहरण के लिए, यह निर्धारित करने के लिए कि स्थान खाली करने का प्रयास करने के लिए सत्र को मार दिया जा सकता है)। मैंने इस ट्रैकिंग के ऊपरी हिस्से पर चर्चा नहीं की - हम उम्मीद करते हैं कि विस्तारित ईवेंट ट्रेस की तुलना में हल्के होंगे, लेकिन कोई भी निगरानी पूरी तरह से मुफ़्त नहीं है।
चूंकि अधिकांश लोग डिफ़ॉल्ट ट्रेस को सक्षम छोड़ देते हैं, हम उसे वहीं छोड़ देंगे। हम SELECT INTO . का उपयोग करके दोनों हीप का परीक्षण करेंगे (जिसे डिफ़ॉल्ट ट्रेस एकत्र नहीं करेगा) और क्लस्टर इंडेक्स (जो यह करेगा), और हम बैच को बेसलाइन के रूप में अपने आप में समय देंगे, फिर बैच को फिर से विस्तारित ईवेंट सत्र के साथ चलाएंगे। हम SQL Server 2012 और SQL Server 2014 दोनों के विरुद्ध भी परीक्षण करेंगे। बैच अपने आप में बहुत सरल है:
नोकाउंट चालू करें; SYSDATETIME (); का चयन करें - इस भाग को केवल ढेर बैच के लिए चलाएं:शीर्ष (100) [object_id] चुनें #foo से sys.all_objects [object_id] द्वारा ऑर्डर करें; ड्रॉप टेबल #foo; -- इस भाग को केवल CIX बैच के लिए चलाएँ:CREATE TABLE #bar(id INT PRIMARY KEY);INSERT #bar(id) SELECT TOP (100) [object_id] FROM sys.all_objects ORDER BY [object_id];DROP TABLE #bar; GO 100000 चुनें SYSDATETIME ();
दोनों उदाहरणों में चार डेटा फ़ाइलों के साथ tempdb कॉन्फ़िगर किया गया है और TF 1117 और TF 1118 सक्षम है, एक VM में चार CPU, 16GB मेमोरी और केवल SSD के साथ है। मैंने जानबूझकर बैच पर किसी भी देखे गए प्रभाव को बढ़ाने के लिए छोटी #temp तालिकाएँ बनाई हैं (जो अगर #temp तालिकाओं को बनाने में लंबा समय लेती हैं या अत्यधिक ऑटोग्रोथ घटनाओं का कारण बनती हैं, तो डूब जाती हैं)।
मैंने इन बैचों को प्रत्येक परिदृश्य में चलाया, और ये परिणाम थे, जिन्हें बैच अवधि में सेकंड में मापा गया:
बैच की अवधि, सेकंड में, 100,000 #temp टेबल बनाने के लिए
डेटा को थोड़ा अलग तरीके से व्यक्त करते हुए, यदि हम अवधि से 100,000 विभाजित करते हैं, तो हम #temp तालिकाओं की संख्या दिखा सकते हैं जो हम प्रत्येक परिदृश्य में प्रति सेकंड बना सकते हैं (पढ़ें:थ्रूपुट)। ये रहे वो नतीजे:
#temp तालिकाएं प्रत्येक परिदृश्य में प्रति सेकेंड बनाई गई हैं
परिणाम मेरे लिए थोड़े आश्चर्यजनक थे - मुझे उम्मीद थी कि SQL सर्वर 2014 में उत्सुक लेखन तर्क में सुधार के साथ, ढेर की आबादी बहुत तेजी से चलेगी। 2014 में हीप बेसलाइन कॉन्फ़िगरेशन में 2012 की तुलना में दो सेकंड तेज था, लेकिन एक्सटेंडेड इवेंट्स ने समय को काफी बढ़ा दिया (बेसलाइन पर लगभग 10% की वृद्धि); जबकि क्लस्टर्ड इंडेक्स का समय बेसलाइन पर 2012 के बराबर था, लेकिन विस्तारित इवेंट सक्षम होने के साथ लगभग 18% बढ़ गया। 2012 में, ढेर और क्लस्टर इंडेक्स के लिए डेल्टा अधिक मामूली थे - क्रमशः 1.1% और 1.5%। (और स्पष्ट होने के लिए, किसी भी परीक्षण के दौरान कोई ऑटोग्रो इवेंट नहीं हुआ।)
तो, मैंने सोचा, क्या होगा यदि मैंने एक दुबला, अर्थपूर्ण विस्तारित ईवेंट सत्र बनाया है? निश्चित रूप से मैं उन कुछ एक्शन कॉलम को हटा सकता हूं - शायद मुझे केवल लॉगिन नाम और स्पिड की आवश्यकता है, और ऐप नाम, होस्ट नाम और संभावित रूप से महंगे sql_text को अनदेखा कर सकता हूं। शायद मैं प्रतिबद्धता के खिलाफ अतिरिक्त फ़िल्टर छोड़ सकता हूं (दो बार कई घटनाओं को इकट्ठा करना, लेकिन फ़िल्टरिंग पर कम सीपीयू खर्च करना) और कार्यभार पर संभावित प्रभाव को कम करने के लिए कई घटना हानि की अनुमति देता है। यह दुबला सत्र इस तरह दिखता है:
ईवेंट सत्र बनाएं [TempTableCreation2014_LeanerMeaner] सर्वर पर ईवेंट जोड़ें ( SET FILENAME ='c:\temp\TempTableCreation2014_LeanerMeaner.xel', MAX_FILE_SIZE =32768, MAX_ROLLOVER_FILES =10)साथ (EVENT_RETENTION_MODE =ALLOW_MULTIPLE_EVENT_LOSS) SONERकाश, नहीं, वही परिणाम। ढेर के लिए सिर्फ तीन मिनट से अधिक, और संकुल सूचकांक के लिए सिर्फ सात मिनट से कम। जहां अतिरिक्त समय बिताया जा रहा था, वहां गहराई से खुदाई करने के लिए, मैंने 2014 के उदाहरण को SQL संतरी के साथ देखा, और बिना किसी विस्तारित ईवेंट सत्र को कॉन्फ़िगर किए बिना केवल क्लस्टर इंडेक्स बैच चलाया। फिर मैंने बैच को फिर से चलाया, इस बार लाइटर XE सत्र के साथ कॉन्फ़िगर किया गया। बैच का समय 5:47 (347 सेकेंड) और 6:55 (415 सेकेंड) था - पिछले बैच के अनुरूप बहुत अधिक (मुझे यह देखकर खुशी हुई कि हमारी निगरानी ने अवधि में कोई और योगदान नहीं दिया :-)) . मैंने पुष्टि की कि कोई भी इवेंट ड्रॉप नहीं किया गया था, और फिर से कोई ऑटोग्रो इवेंट नहीं हुआ।
मैंने इतिहास मोड में SQL संतरी डैशबोर्ड को देखा, जिसने मुझे दोनों बैचों के प्रदर्शन मेट्रिक्स को साथ-साथ देखने की अनुमति दी:
SQL संतरी डैशबोर्ड, इतिहास मोड में, दोनों बैच दिखा रहा हैनेटवर्क, सीपीयू, लेन-देन, संकलन, कुंजी लुकअप आदि के मामले में दोनों बैच लगभग समान थे। वेट्स में कुछ मामूली अंतर है - पहले बैच के दौरान स्पाइक्स विशेष रूप से WRITELOG थे, जबकि कुछ मामूली CXPACKET वेट पाए गए थे। दूसरा बैच। मध्यरात्रि के बाद मेरा कार्य सिद्धांत यह है कि शायद देरी का एक अच्छा हिस्सा विस्तारित ईवेंट प्रक्रिया के कारण संदर्भ स्विचिंग के कारण था। चूंकि हमारे पास कवर के तहत एक्सई क्या कर रहा है, इसकी कोई दृश्यता नहीं है, और न ही हम जानते हैं कि 2012 और 2014 के बीच एक्सई में अंतर्निहित यांत्रिकी क्या बदल गई है, यही वह कहानी है जिसे मैं अभी तक जारी रखने जा रहा हूं, जब तक कि मैं नहीं हूं xperf और/या WinDbg के साथ अधिक सहज।
निष्कर्ष
किसी भी घटना में, यह स्पष्ट है कि #temp तालिका निर्माण पर नज़र रखना मुफ़्त नहीं है, और आपके द्वारा बनाई जा रही #temp तालिकाओं के प्रकार, आपके द्वारा अपने XE सत्रों में एकत्रित की जा रही जानकारी और यहां तक कि संस्करण के आधार पर लागत भिन्न हो सकती है। आप जिस SQL सर्वर का उपयोग कर रहे हैं। इसलिए आप मेरे द्वारा यहां किए गए परीक्षणों के समान परीक्षण चला सकते हैं, और यह तय कर सकते हैं कि आपके परिवेश में यह जानकारी एकत्र करना कितना मूल्यवान है।
