अधिक लेन-देन लॉग काटना वसा

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

अनेक, अनेक छोटे लेन-देन

हर बार SQL सर्वर ट्रांजेक्शन लॉग के एक हिस्से को डिस्क पर फ्लश कर देगा। लॉग फ्लश तब होता है जब:

एक लेन-देन प्रतिबद्ध लॉग रिकॉर्ड उत्पन्न होता है।
एक लेन-देन निरस्त लॉग रिकॉर्ड एक लेन-देन रोलबैक के अंत में उत्पन्न होता है।
पिछले लॉग फ्लश के बाद से 60KB लॉग रिकॉर्ड तैयार किए गए हैं।

सबसे छोटा लॉग फ्लश संभव एक 512-बाइट लॉग ब्लॉक है। यदि कार्यभार में सभी लेन-देन बहुत छोटे हैं (उदाहरण के लिए एक एकल, छोटी तालिका पंक्ति सम्मिलित करना) तो बहुत सारे न्यूनतम आकार के लॉग फ्लश होंगे। लॉग फ्लश को अतुल्यकालिक रूप से निष्पादित किया जाता है, ताकि अच्छे लेन-देन लॉग थ्रूपुट की अनुमति मिल सके, लेकिन किसी भी समय 32 समवर्ती लॉग-फ्लश I/Os की एक निश्चित सीमा है (SQL सर्वर 2012 पर 112 तक बढ़ा दी गई)।

इसके दो संभावित प्रभाव हो सकते हैं:

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

दोनों ही मामलों में, लेन-देन को लंबा करना (जो बहुत प्रति-सहज है!) लेन-देन लॉग फ्लश की आवृत्ति को कम कर सकता है और प्रदर्शन को बढ़ा सकता है। इसके अतिरिक्त, #1 के मामले में, उच्च-प्रदर्शन करने वाले I/O सबसिस्टम में जाने से मदद मिल सकती है – लेकिन इससे केस #2 हो सकता है। मामले #2 के साथ, यदि लेन-देन लंबे समय तक नहीं किया जा सकता है, तो एकमात्र विकल्प 32 समवर्ती लॉग-फ्लश I/Os की निश्चित सीमा प्राप्त करने या SQL सर्वर 2012 या उच्चतर में अपग्रेड करने के लिए एकाधिक डेटाबेस पर कार्यभार को विभाजित करना है।

लेन-देन लॉग ऑटो-ग्रोथ

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

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

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

आप इसके बारे में यहाँ और यहाँ और अधिक पढ़ सकते हैं।

उच्च उपलब्धता सुविधाएं

कुछ उच्च-उपलब्धता सुविधाएँ भी लेन-देन लॉग समाशोधन में देरी कर सकती हैं:

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

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

संयोग से, एक ही तरह की समस्या तब हो सकती है जब I/O सबसिस्टम स्वयं सिंक्रोनाइज़ किया जाता है - सभी के लिए संभावित विलंब के साथ जो SQL सर्वर करता है।

सारांश

जैसा कि आप देख सकते हैं, लेन-देन लॉग प्रदर्शन केवल अतिरिक्त लेन-देन लॉग रिकॉर्ड उत्पन्न करने के बारे में नहीं है - ऐसे कई पर्यावरणीय कारक हैं जिनका गहरा प्रभाव भी हो सकता है।

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

यदि आप लेन-देन लॉग संचालन और प्रदर्शन ट्यूनिंग के बारे में बहुत कुछ सीखना चाहते हैं, तो मेरा सुझाव है कि आप प्लूरलसाइट के माध्यम से उपलब्ध लॉगिंग, पुनर्प्राप्ति और लेनदेन लॉग पर मेरा 7.5 घंटे का ऑनलाइन प्रशिक्षण पाठ्यक्रम देखें।