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


मेरे पास एक एसक्यूएल सर्वर 2005 उदाहरण पर चलाने के लिए स्थापित तीन रखरखाव योजनाएं हैं:

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

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

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

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


37
2018-05-27 12:23


मूल


+1 इस सवाल से उत्पादित विचारों के आदान-प्रदान के कारण इसे हटा दिया गया। - MarlonRibunal


जवाब:


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

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

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

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

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

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

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

धन्यवाद

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


30
2018-05-27 16:29



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


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

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

मैं दैनिक पूर्ण बैकअप बीटीडब्ल्यू के पक्ष में दैनिक अंतर को छोड़ दूंगा।


4
2018-05-27 12:34



मुझे लगता है कि मैं पूर्ण बैकअप के अंत में सीधे ट्रंकेट लॉग कर सकता हूं, लेकिन यह बिल्कुल सही तरीके से प्रतीत नहीं होता है, मैं कुछ विकल्पों की उम्मीद कर रहा था ... दैनिक पूर्ण बैकअप करने के लाभ क्या होंगे diffs से? ऐसा लगता है कि अपेक्षाकृत कम लाभ के लिए और अधिक जगह का उपयोग करना प्रतीत होता है। मैं भी सरल वसूली पर स्विच नहीं कर सकता क्योंकि मुझे प्रति घंटा लॉग बैकअप देने की ग्रैन्युलरिटी के स्तर की आवश्यकता होती है। आखिरकार, मुझे यकीन नहीं है कि एक स्क्रिप्ट में ऑप्टिमाइज़ेशन कैसे बढ़ते हैं, निश्चित रूप से मुझे अभी भी वही समस्या होगी जो कम बार होती है? - Dave
मैंने diff को छोड़ने और दैनिक पूर्ण पर जाने के सुझाव के कारण इसे घटा दिया। क्यूं कर? एक 3.5 जीबी पूर्ण करता है जबकि diffs केवल 250 एमबी हैं। बैकअप रणनीति मेरे लिए बिल्कुल ठीक लगती है। Diffs को हटाने का मतलब बहाल समय में केवल एक छोटे, छोटे गति के लिए कई जीबी अधिक भंडारण है। - Paul Randal
हर किसी की स्थिति अलग होती है, अलग-अलग में कुछ भी गलत नहीं होता है, लेकिन जब तक कि प्रीमियम प्रीमियम पर न हो, यदि आपको जल्दी से ठीक होने की आवश्यकता है, तो बेहतर है कि दो से एक कदम हो। - SqlACID
@ डेव जेरेमी की प्रतिक्रिया देखें, विशिष्ट फ़ाइलों को डिफ्रैग करने के लिए संग्रहीत प्रक्रिया बनाएं, इसे छोटे हिस्सों में विभाजित करें। - SqlACID


आपका अंतिम सवाल था: "TRUNCATE_ONLY के साथ बैकअप लॉग के अलावा, क्या लॉग लॉग बैकअप के आकार को कम करने का कोई तरीका है, या लेन-देन लॉग में ऑप्टिमाइज़ेशन रिकॉर्ड होने से रोकें, निश्चित रूप से वे पहले से पूर्ण बैकअप में होंगे?"

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

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

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


2
2018-05-27 14:23



और आपको 10 पीएम से ठीक पहले सिंपल पर स्विच करना होगा, है ना? अन्यथा 12AM लॉग बैकअप में 10 पीएम और 12AM के बीच उत्पन्न सभी लॉग होंगे। - Paul Randal
ओह उल्लेख करने के लिए भूल गए मैंने इसे भी कम कर दिया क्योंकि आपने सरल में होने का जिक्र नहीं किया था। BULK_LOGGED में रहने से भी अगले लॉग बैकअप का आकार नहीं बदलेगा क्योंकि यह न्यूनतम डेटा लॉग इन किए गए सभी डेटा एक्सटेंशन को उठाएगा। वाह - अब तक हर जवाब को कम कर दिया। - Paul Randal
नहीं, निश्चित रूप से सरल पर स्विच नहीं है। उन्होंने अपने लेनदेन लॉग बैकअप के आकार के बारे में पूछा, न कि उनके पूर्ण बैकअप या उसकी लेनदेन लॉग फ़ाइल का आकार। - Brent Ozar
तो आप लेनदेन लॉग बैकअप के आकार को कैसे कम करते हैं? जब तक आप लॉग बैकअप श्रृंखला तोड़ नहीं रहे हैं और फिर पूर्ण बैकअप के साथ पुनरारंभ कर रहे हैं, तब तक वे पिछले लॉग बैकअप के बाद सब कुछ शामिल करेंगे। - Paul Randal
जब तक आपकी अनुक्रमणिका रखरखाव नौकरी कुछ भी नहीं करता ... - Paul Randal


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

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

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


2
2018-05-27 18:46





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


1
2018-05-27 18:05





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

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

क्या आप अंतर (या पूर्ण) से पहले या उसके बाद प्रतिदिन अपना अनुकूलन कर सकते हैं, तो 7 की बजाय आखिरी बार 1 दिन होने के बाद अनुकूलित करने के लिए कम है?

क्या आप प्रत्येक अंतर से पहले या बाद में ऑप्टिमाइज़ेशन का 1/7 वां कर सकते हैं, (टेबल द्वारा टूटा हुआ हो सकता है) ताकि प्रत्येक सप्ताह सभी अनुकूलन एक बार के माध्यम से चक्कर लगाया जा सके?


1
2018-05-27 18:37





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

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

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

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

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


1
2018-06-03 20:10