लेन-देन लॉग को ट्रिम करना फैट

कई SQL सर्वर वर्कलोड में, विशेष रूप से OLTP में, डेटाबेस का लेन-देन लॉग एक अड़चन हो सकता है जो लेन-देन को पूरा करने में लगने वाले समय को जोड़ता है। अधिकांश लोग मानते हैं कि I/O सबसिस्टम वास्तविक अड़चन है, क्योंकि यह कार्यभार द्वारा उत्पन्न होने वाले लेन-देन लॉग की मात्रा को बनाए रखने में सक्षम नहीं है।

लेन-देन लॉग लिखें विलंबता

sys.dm_io_virtual_file_stats का उपयोग करके लेन-देन लॉग में लिखने के संचालन की विलंबता की निगरानी की जा सकती है DMV और WRITELOG . के साथ सहसंबद्ध प्रतीक्षा करता है जो सिस्टम पर हो रहा है। मैंने 2011 में लेन-देन लॉग I/O का विश्लेषण करने का एक डेमो वीडियो रिकॉर्ड किया था, इसलिए मैं इस पोस्ट में वह सब नहीं दोहराऊंगा। आप यहां वीडियो और डेमो कोड यहां (अभी उत्पादन में चलने के लिए उपयुक्त) प्राप्त कर सकते हैं।

यदि लेखन विलंबता आपके I/O सबसिस्टम के लिए अपेक्षा से अधिक है तो I/O सबसिस्टम सामान्य धारणा के अनुसार जारी नहीं रख सकता है। क्या इसका मतलब यह है कि I/O सबसिस्टम में सुधार की आवश्यकता है? जरूरी नहीं।

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

बाहरी लॉग रिकॉर्ड उत्पन्न होने के दो मुख्य कारण हैं:अप्रयुक्त गैर-संकुल अनुक्रमणिका, और अनुक्रमणिका का खंडित होना।

अप्रयुक्त गैर-संकुल अनुक्रमणिका

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

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

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

वे जहां से आए हैं, उनके ओवरहेड को कम करने के लिए अप्रयुक्त इंडेक्स को हटा दिया जाना चाहिए। आप sys.dm_db_index_usage_stats DMV का उपयोग करके यह निर्धारित कर सकते हैं कि कौन सी अनुक्रमणिका अप्रयुक्त हैं, और मैं अनुशंसा करता हूं कि आप मेरे सहयोगियों Kimberly L. Tripp (यहां), और जो सैक (यहां और यहां) द्वारा पोस्ट पढ़ें, क्योंकि वे बताते हैं कि DMV का सही तरीके से उपयोग कैसे करें।

सूचकांक विखंडन

अधिकांश लोग इंडेक्स फ़्रेग्मेंटेशन को एक समस्या के रूप में सोचते हैं जो बड़ी मात्रा में डेटा को पढ़ने वाले प्रश्नों को प्रभावित करती है। जबकि यह उन समस्याओं में से एक है जो विखंडन का कारण बन सकती हैं, विखंडन भी एक समस्या है क्योंकि यह कैसे होता है।

विखंडन एक ऑपरेशन के कारण होता है जिसे पेज स्प्लिट कहा जाता है। पृष्ठ विभाजन का सबसे सरल कारण तब होता है जब किसी विशेष पृष्ठ पर एक अनुक्रमणिका रिकॉर्ड डाला जाना चाहिए (इसके प्रमुख मूल्य के कारण) और पृष्ठ में पर्याप्त खाली स्थान नहीं है। इस परिदृश्य में, निम्नलिखित ऑपरेशन होंगे:

• एक नया अनुक्रमणिका पृष्ठ आवंटित और स्वरूपित किया गया है
• पूरे पृष्ठ से कुछ रिकॉर्ड नए पृष्ठ पर ले जाए जाते हैं, इस प्रकार आवश्यक पृष्ठ में खाली स्थान बनाते हैं
• नया पेज इंडेक्स स्ट्रक्चर से जुड़ा हुआ है
• नया रिकॉर्ड आवश्यक पेज पर डाला गया है

ये सभी ऑपरेशन लॉग रिकॉर्ड उत्पन्न करते हैं, और जैसा कि आप कल्पना कर सकते हैं, यह उस पृष्ठ पर एक नया रिकॉर्ड डालने के लिए आवश्यक से काफी अधिक हो सकता है जिसके लिए पृष्ठ विभाजन की आवश्यकता नहीं होती है। 2009 में वापस मैंने लेन-देन लॉग के संदर्भ में पृष्ठ विभाजन लागत का विश्लेषण ब्लॉग किया और कुछ मामलों को पाया जहां एक पृष्ठ विभाजन एक नियमित प्रविष्टि की तुलना में 40 गुना अधिक लेनदेन लॉग उत्पन्न करता है!

अतिरिक्त लागत को कम करने में पहला कदम अप्रयुक्त इंडेक्स को हटाना है, जैसा कि मैंने ऊपर वर्णित किया है, ताकि वे पेज स्प्लिट उत्पन्न नहीं कर रहे हैं। दूसरा चरण sys.dm_db_index_physical_stats का उपयोग करके उन शेष अनुक्रमणिकाओं की पहचान करना है जो खंडित हो रही हैं (और इसलिए पृष्ठ विभाजन से पीड़ित होना चाहिए) DMV (या नया SQL Sentry Fragmentation Manager) और इंडेक्स फिलफैक्टर का उपयोग करके उनमें लगातार खाली स्थान बना रहा है। एक फिलफैक्टर SQL सर्वर को इंडेक्स पेज पर खाली जगह छोड़ने के लिए निर्देश देता है जब इंडेक्स बनाया जाता है, पुनर्निर्माण किया जाता है, या पुनर्गठित किया जाता है ताकि पेज स्प्लिट की आवश्यकता के बिना नए रिकॉर्ड डालने की अनुमति मिल सके, इसलिए उत्पन्न अतिरिक्त लॉग रिकॉर्ड में कटौती हो।

बेशक कुछ भी मुफ्त में नहीं आता है - फिलफैक्टर्स का उपयोग करते समय ट्रेड-ऑफ यह है कि आप अधिक लॉग रिकॉर्ड उत्पन्न होने से रोकने के लिए इंडेक्स में अतिरिक्त स्थान का प्रावधान कर रहे हैं - लेकिन यह आमतौर पर बनाने के लिए एक अच्छा ट्रेड-ऑफ है। फिलफैक्टर चुनना अपेक्षाकृत आसान है और मैंने इसके बारे में यहां ब्लॉग किया है।

सारांश

लेन-देन लॉग फ़ाइल की लेखन विलंबता को कम करने का अर्थ हमेशा तेज़ I/O सबसिस्टम में जाना या फ़ाइल को I/O सबसिस्टम के अपने हिस्से में अलग करना नहीं होता है। अपने डेटाबेस में इंडेक्स के कुछ सरल विश्लेषण के साथ, आप उत्पन्न होने वाले लेन-देन लॉग रिकॉर्ड की मात्रा को काफी कम करने में सक्षम हो सकते हैं, जिससे लेखन विलंबता में कमी आती है।

अन्य, अधिक सूक्ष्म मुद्दे हैं जो लेन-देन लॉग के प्रदर्शन को प्रभावित कर सकते हैं, और मैं भविष्य की पोस्ट में उनका पता लगाऊंगा।