पूर्ण बैकअप के बाद मैं लेन-देन लॉग बैकअप आकार को कैसे कम करूँ?

Question

मेरे पास Sql Server 2005 आवृत्ति पर चलने के लिए तीन रखरखाव योजनाएँ हैं:

• एक पूर्ण बैकअप के बाद साप्ताहिक डेटाबेस अनुकूलन
• दैनिक अंतर बैकअप
• हर घंटे लेन-देन लॉग बैकअप

प्रति घंटा लॉग बैकअप आमतौर पर गतिविधि के स्तर के आधार पर कुछ सौ केबी और 10 एमबी के बीच होता है, दैनिक अंतर आमतौर पर सप्ताह के अंत तक लगभग 250 एमबी तक बढ़ जाता है, और साप्ताहिक बैकअप लगभग 3.5 जीबी है।

मेरे पास समस्या यह है कि पूर्ण बैकअप से पहले ऑप्टिमाइज़ेशन प्रतीत होता है कि अगला लेन-देन लॉग बैकअप पूर्ण बैकअप के 2x पर बढ़ने का कारण बनता है, इस मामले में 8 जीबी, सामान्य पर लौटने से पहले।

इसके अलावा BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY, क्या उस लॉग बैकअप के आकार को कम करने, या लेन-देन के लॉग में दर्ज किए जाने से होने वाले अनुकूलन को रोकने के लिए कोई रास्ता नहीं है, क्योंकि निश्चित रूप से वे पूर्ण बैकअप के लिए जिम्मेदार होंगे, जो वे पहले थे?

Comments

+1 इस प्रश्न द्वारा उत्पन्न विचारों के आदान-प्रदान के कारण इसे अपग्रेड किया गया।

— मार्लोनरिब्यूनल

Answer 1

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

इस नियम का एकमात्र अपवाद यह है कि यदि लॉग बैकअप श्रंखला को तोड़ा गया है (जैसे कि SIMPLE रिकवरी मॉडल पर जाकर, डेटाबेस स्नैपशॉट से पुनर्प्राप्त करके, जो कि NO_LOG / TRUNCATE_ONLY के साथ BACKUP लॉग का उपयोग करके लॉग को रौंदता है), जिस स्थिति में पहला लॉग बैकअप होता है अंतिम पूर्ण बैकअप के बाद से सभी लेन-देन लॉग शामिल होंगे - जो लॉग बैकअप श्रृंखला को पुनरारंभ करता है; या यदि लॉग बैकअप श्रृंखला शुरू नहीं की गई है - जब आप पहली बार पूर्ण में स्विच करते हैं, तो आप पहले पूर्ण बैकअप लेने तक एक प्रकार के छद्म-SIMPLE पुनर्प्राप्ति मॉडल में काम करते हैं।

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

यदि आप रखरखाव ऑप्स के बारे में कुछ जानकारी पोस्ट कर सकते हैं, तो मैं आपको उनका अनुकूलन करने में मदद कर सकता हूं। क्या आप किसी भी संयोग से, इंडेक्स रिबोर कर रहे हैं, जिसके बाद एक सिकुड़ा हुआ डेटाबेस इंडेक्स रिबर्ड द्वारा उपयोग किए गए स्थान को पुनः प्राप्त करने के लिए है।

यदि आपके पास रखरखाव के दौरान डेटाबेस में कोई अन्य गतिविधि नहीं है, तो आप निम्न कार्य कर सकते हैं:

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

आशा है कि यह मदद करता है - अधिक जानकारी के लिए तत्पर है।

धन्यवाद

[संपादित करें: एक पूर्ण बैकअप बाद के लॉग बैकअप के आकार को बदल सकता है या नहीं (इसके बारे में सभी चर्चाओं के बाद) मैंने पृष्ठभूमि सामग्री और इसे साबित करने वाली स्क्रिप्ट के साथ एक व्यापक ब्लॉग पोस्ट को एक साथ रखा। इसे https://www.sqlskills.com/blogs/paul/misconception-around-the-log-and-log-backups-how-to-convince-yourself/] पर देखें।

Comments

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

— ब्रेंट ओजर

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

— पॉल रैंडल

और यहां तक ​​कि यह ओपी के मूल प्रश्न की मदद नहीं करता है कि सूचकांक रखरखाव के बाद लॉग बैकअप के आकार को कैसे कम किया जाए - वास्तव में यह संभावित रूप से इसे बड़ा बना देगा, जो ऑपरेशन किए जा रहे हैं पर निर्भर करता है।

— पॉल रैंडल

Answer 2

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

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

मैं दैनिक पूर्ण बैकअप BTW के पक्ष में दैनिक अंतर छोड़ता हूं।

Comments

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

— डेव

मैंने इसे छोड़ दिया और दैनिक फुल पर जाने के सुझाव के कारण इसे डाउनवोट कर दिया। क्यूं कर? फुल एक 3.5GB जबकि डिफरेंशियल केवल 250MB है। बैकअप रणनीति मुझे बिल्कुल ठीक लगती है। विवर्तन को हटाने का अर्थ है कि बहाल समय में केवल एक छोटे, छोटे स्पीडअप के लिए कई जीबी अधिक भंडारण।

— पॉल रान्डल

हर किसी की स्थिति अलग है, वहाँ कुछ भी गलत नहीं है, लेकिन जब तक अंतरिक्ष एक प्रीमियम पर नहीं है, अगर आपको जल्दी से ठीक होने की आवश्यकता है, तो दो से एक कदम रखना बेहतर है।

— स्क्लैकिड

@ देखें जेरेमी की प्रतिक्रिया देखें, विशिष्ट फ़ाइलों को डीफ़्रैग करने के लिए एक संग्रहीत कार्यविधि बनाएं, इसे छोटे टुकड़ों में तोड़ दें।

— स्क्लैकिड

Answer 3

आपका अंतिम प्रश्न था: "TRUNCATE_ONLY के साथ BACKUP लॉग के अलावा, क्या उस लॉग बैकअप के आकार को कम करने, या लेन-देन के लॉग में दर्ज किए जाने से होने वाले अनुकूलन को रोकने के लिए कोई रास्ता नहीं है, क्योंकि निश्चित रूप से उनका पूरा हिसाब होगा। बैकअप से पहले वे "

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

• 9:30 PM - लेन-देन लॉग बैकअप चलता है।
• 9:45 PM - आखिरी बार लेनदेन लॉग बैकअप चलता है। अनुसूची 9:59 पर बंद हो जाती है।
• 10:00 PM - सूचकांक अनुरक्षण कार्य शुरू होता है और 11:30 से पहले समाप्त करने के लिए अंतर्निहित स्टॉप होता है।
• 11:30 PM - 30 मिनट से कम समय में पूर्ण बैकअप कार्य शुरू होता है और समाप्त होता है।
• 12:00 पूर्वाह्न - लेनदेन लॉग बैकअप हर 15 मिनट में फिर से शुरू होता है।

इसका मतलब है कि मेरे पास 9:45 और 11:30 बजे के बीच पॉइंट-इन-टाइम रिकवरीबिलिटी नहीं है, लेकिन पेऑफ तेज प्रदर्शन है।

Comments

और आपको 10PM से ठीक पहले SIMPLE पर स्विच करना होगा, है ना? अन्यथा 12AM लॉग बैकअप में 10PM और 12AM के बीच उत्पन्न सभी लॉग होंगे।

— पॉल रान्डल

ओह, मैं इस बात का उल्लेख करना भूल गया क्योंकि आपने SIMPLE में होने का उल्लेख नहीं किया है। BULK_LOGGED में बने रहने से भी अगले लॉग बैकअप का आकार नहीं बदलेगा क्योंकि यह न्यूनतम-लॉग-ऑपरेशन द्वारा परिवर्तित किए गए सभी डेटा एक्सटेंशन को उठाएगा। वाह - अब तक इसके हर जवाब को नकार दिया।

— पॉल रैंडल

नहीं , निश्चित रूप से सरल पर स्विच नहीं करें। उसने अपने लेन-देन लॉग बैकअप के आकार के बारे में पूछा, न कि उसके पूर्ण बैकअप या उसके लेनदेन लॉग फ़ाइल के आकार के बारे में।

— ब्रेंट ओजर

तो आप लेन-देन लॉग बैकअप के आकार को कैसे कम करते हैं? वे पिछले लॉग बैकअप के बाद से सब कुछ सम्‍मिलित करेंगे, जब तक कि आप लॉग बैकअप श्रृंखला को तोड़ नहीं रहे हैं और फिर उसे पूर्ण बैकअप के साथ पुनः आरंभ कर रहे हैं।

— पॉल रैंडल

जब तक आपकी अनुरक्षण रखरखाव की नौकरी कुछ भी नहीं करती ...

— पॉल रैंडल

Answer 4

आसान उत्तर: रात के आधार पर अपने साप्ताहिक अनुकूलन कार्य को अधिक संतुलित तरीके से चलाने के लिए बदलें। यानी रविवार की रात को फिर से सूचकांक तालिकाएँ, सोमवार की रात को एफ - एल आदि ... एक अच्छा संतुलन ढूंढें, आपका लॉग औसतन लगभग 1/6 आकार का होगा। यदि आप बिल्ट-इन ssis इंडेक्स मेंटेनेंस जॉब का उपयोग नहीं कर रहे हैं तो बेशक यह सबसे अच्छा काम करता है।

इसका नकारात्मक पक्ष यह है कि आपके db अनुभवों के भार के आधार पर यह महत्वपूर्ण है कि यह ऑप्टिमाइज़र और क्वेरी योजनाओं के पुन: उपयोग के साथ कहर बरपाए।

लेकिन अगर आप परवाह करते हैं कि साप्ताहिक आधार पर आपके टी-लॉग का आकार है, तो इसे दिन-प्रतिदिन या घंटे से घंटे में विभाजित करें और टी-लॉग बैकअप को बीच-बीच में चलाएं।

Answer 5

आप बैकअप और लॉग के आकार को कम करने के लिए थर्ड पार्टी टूल (Litespeed से क्वेस्ट, SQL गेट से रेड गेट, हाइपरबैक) पर भी गौर कर सकते हैं। वे टेप बचत में खुद के लिए जल्दी भुगतान कर सकते हैं।

Answer 6

यह शायद माना जा सकता है कि आपके "अनुकूलन" में इंडेक्स रीबिल्ड्स शामिल हैं। केवल साप्ताहिक आधार पर ये कार्य करना एक डेटाबेस पर स्वीकार्य हो सकता है जो अद्यतनों और आवेषणों का एक बड़ा सौदा नहीं करता है, हालांकि यदि आपका डेटा अत्यधिक तरल है तो आप कुछ चीजें करना चाहते हैं:

1. यदि आपका शेड्यूल अनुमति देता है और यदि प्रभाव स्वीकार्य है तो अपने अनुक्रमितों को रात में पुनर्निर्माण या पुनर्गठित करें। इन रात्रिकालीन अनुरक्षण कार्यों का प्रदर्शन करते समय केवल उन अनुक्रमणिकाओं को लक्षित किया जाता है, जो पुनर्वित्त के लिए ३०% से आगे और खंड के लिए १५-३०% की सीमा से परे हैं।

2. ये कार्य लॉग किए गए लेन-देन हैं, इसलिए यदि आप लॉग वृद्धि के बारे में चिंतित हैं, तो मैं पॉल की सिफारिश करने की वकालत करूंगा। इंडेक्स मेंटेनेंस से पहले फाइनल ट्रांजैक्शन लॉग बैकअप, सिंपल रिकवरी के लिए स्विच, मेंटेनेंस प्रोसेस द्वारा पीछा किया जाता है और फिर फुल रिकवरी पर वापस स्विच किया जाता है।

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

उन लिपियों के लिए जो विवेकाधीन सूचकांक अनुरक्षण ऑनलाइन दिखाती हैं: वहाँ एक टन बाहर हैं। एंड्रयू केली ने लगभग एक साल पहले SQL पत्रिका में एक सभ्य प्रकाशित किया था। SQLServerPedia की मिशेल Ufford से कुछ स्क्रिप्ट हैं, और SQL पत्रिका के नवीनतम अंक (जुलाई 2009 में मेरा मानना ​​है) के विषय पर भी एक पूर्ण लेख है। बिंदु वह है जो आपके लिए अच्छी तरह से काम करता है और इसे न्यूनतम अनुकूलन के साथ अपना बनाएं।

Answer 7

क्या आप अपने डेटाबेस अनुकूलन के दौरान विभिन्न बिंदुओं पर अपने लेनदेन लॉग का विशेष रूप से बैकअप ले सकते हैं? टी-लॉग का कुल आकार समान होगा, लेकिन हर एक छोटा होगा, संभवतः किसी तरह से आपकी मदद करेगा।

क्या आप अधिक लक्षित डेटाबेस अनुकूलन कर सकते हैं इसलिए कम लेनदेन बनाए जाते हैं (किसी ने इसका उल्लेख किया है लेकिन मुझे यकीन नहीं है कि निहितार्थ समाप्त हो गए थे)। जैसे कुछ समय के लिए विखंडन या व्यर्थ जगह की एक निश्चित मात्रा को सहन करना। यदि आपकी 40% टेबल केवल 5% खंडित हैं, तो उन्हें नहीं छूने से काफी सक्रियता बच सकती है।