लेनदेन लॉग विन्यास मुद्दे

अपनी पिछली दो पोस्टों में मैंने लेन-देन लॉग की मात्रा को कम करने के तरीकों पर चर्चा की और कैसे सुनिश्चित किया जाए कि लेन-देन लॉग हमेशा ठीक से साफ़ हो सके। इस पोस्ट में मैं लेन-देन लॉग प्रदर्शन विषय के साथ जारी रखना चाहता हूं और कुछ लेनदेन लॉग कॉन्फ़िगरेशन मुद्दों पर चर्चा करना चाहता हूं जो समस्याएं पैदा कर सकते हैं।

बहुत अधिक वीएलएफ

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

उदाहरण के लिए, यदि आप 8GB का लेन-देन लॉग बनाते हैं, तो आपको 16 VLF मिलेंगे, जिनमें से प्रत्येक लगभग 512MB का होगा। अगर आप लॉग को और 4GB बढ़ा देते हैं, तो आपको अतिरिक्त 16 VLF मिलेंगे, जिनमें से प्रत्येक का आकार लगभग 256MB होगा, कुल 32 VLF के लिए।

नोट:वीएलएफ विखंडन समस्याओं को कम करने के लिए एसक्यूएल सर्वर 2014 के लिए यह एल्गोरिदम थोड़ा बदल गया - विवरण के लिए यह ब्लॉग पोस्ट देखें

एक सामान्य सर्वोत्तम अभ्यास लॉग ऑटो-ग्रोथ को डिफ़ॉल्ट 10% के अलावा किसी अन्य चीज़ पर सेट करना है, ताकि आप उस ठहराव को नियंत्रित कर सकें जो शून्य-नए लेन-देन लॉग स्थान को प्रारंभ करते समय आवश्यक है। मान लें कि आप एक 256MB लेन-देन लॉग बनाते हैं और ऑटो-ग्रोथ को 32MB पर सेट करते हैं, और फिर लॉग 16GB के स्थिर-राज्य आकार में बढ़ता है। ऊपर दिए गए फॉर्मूले को देखते हुए, इसके परिणामस्वरूप आपके लेन-देन लॉग में 2,000 से अधिक वीएलएफ होंगे।

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

आपके पास कितने वीएलएफ हैं, यह बताने का तरीका अनिर्दिष्ट (और पूरी तरह से सुरक्षित) DBCC LOGINFO का उपयोग करना है आज्ञा। आउटपुट की पंक्तियों की संख्या आपके लेन-देन लॉग में वीएलएफ की संख्या है। अगर आपको लगता है कि आपके पास बहुत अधिक हैं, तो उन्हें कम करने का तरीका यह है:

1. लॉग को साफ़ करने दें
2. लॉग को मैन्युअल रूप से छोटा करें
3. चरण 1 और 2 को तब तक दोहराएं जब तक कि लॉग छोटे आकार तक न पहुंच जाए (जो व्यस्त उत्पादन प्रणाली पर मुश्किल हो सकता है)
4. मैन्युअल रूप से लॉग को उस आकार में बढ़ाना चाहिए, जो 8GB चरणों में होना चाहिए ताकि प्रत्येक VLF लगभग 0.5GB से बड़ा न हो

आप वीएलएफ विखंडन मुद्दों और उन्हें ठीक करने की प्रक्रिया के बारे में अधिक पढ़ सकते हैं:

• Microsoft KB आलेख जो VLF संख्या को कम करने की सलाह देता है
• क्या लॉग फ़ाइलों की वृद्धि DML को प्रभावित कर सकती है?
• बेहतर लेन-देन लॉग थ्रूपुट के लिए 8 कदम

Tempdb

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

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

नियमित रूप से लॉग फ़ाइल सिकुड़ रही है

अक्सर मैं लोगों को यह कहते हुए सुनता हूं कि एक नियमित संचालन (जैसे साप्ताहिक डेटा आयात) से बढ़ने के बाद वे आमतौर पर डेटाबेस के लेनदेन लॉग को कैसे छोटा करते हैं। ऐसा करना अच्छी बात नहीं है।

जैसा कि मैंने ऊपर बताया, जब भी लेन-देन लॉग बढ़ता है या स्वतः बढ़ता है, तो एक विराम होता है जबकि लॉग फ़ाइल का नया भाग शून्य-प्रारंभिक होता है। यदि आप लेन-देन लॉग को नियमित रूप से छोटा कर रहे हैं क्योंकि यह आकार X तक बढ़ता है, तो इसका मतलब है कि आप नियमित रूप से प्रदर्शन समस्याओं का सामना कर रहे हैं क्योंकि लेन-देन लॉग फिर से आकार X में वापस आ जाता है।

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

एकाधिक लॉग फ़ाइलें

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

मुझसे अक्सर पूछा जाता है कि क्या दूसरी लॉग फ़ाइल को हटाने का कोई महत्वपूर्ण कारण है या क्या इसे जगह में छोड़ना ठीक है। इसका उत्तर यह है कि आप इसे जितनी जल्दी हो सके हटा दें।

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

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

डेटाबेस स्नैपशॉट से वापस लाया जा रहा है

मेरी सूची में अंतिम समस्या वास्तव में SQL सर्वर में एक बग है। यदि आप बैकअप को पुनर्स्थापित किए बिना (स्नैपशॉट से वापस लौटने के रूप में जाना जाता है) बिना किसी ज्ञात बिंदु पर जल्दी से पुनर्प्राप्त करने के तरीके के रूप में डेटाबेस स्नैपशॉट का उपयोग करते हैं तो आप बहुत समय बचा सकते हैं। हालांकि, एक बड़ी कमी है।

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

सारांश

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

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