चूंकि मैं स्टैक ओवरफ्लो पर किसी भी जवाब से वास्तव में संतुष्ट नहीं हूं , जिसमें सबसे भारी-भरकम सुझाव भी शामिल है, और क्योंकि कुछ चीजें हैं जिन्हें मैं संबोधित करना चाहूंगा कि माइक का जवाब नहीं है, मैंने सोचा कि मैं प्रदान करता हूं मेरा इनपुट यहाँ भी। मैंने इस जवाब की एक प्रति वहां भी रखी।
लॉग फ़ाइल को छोटा बनाना वास्तव में उन परिदृश्यों के लिए आरक्षित होना चाहिए जहां इसे अप्रत्याशित वृद्धि का सामना करना पड़ा है जो आपको फिर से होने की उम्मीद नहीं है। यदि लॉग फ़ाइल फिर से उसी आकार में बढ़ेगी, तो अस्थायी रूप से सिकुड़कर बहुत कुछ पूरा नहीं होता है। अब, आपके डेटाबेस के पुनर्प्राप्ति लक्ष्यों के आधार पर, ये वो कार्य हैं जो आपको करने चाहिए।
सबसे पहले, एक पूर्ण बैकअप लें
अपने डेटाबेस में कभी भी बदलाव न करें, यह सुनिश्चित करने के बिना कि आप इसे बहाल कर सकते हैं, कुछ गलत होना चाहिए।
अगर आप पॉइंट-इन-टाइम रिकवरी की परवाह करते हैं
(और पॉइंट-इन-टाइम रिकवरी से मेरा मतलब है कि आप एक पूर्ण या अंतर बैकअप के अलावा किसी भी चीज़ को पुनर्स्थापित करने में सक्षम होने के बारे में परवाह करते हैं।)
संभवतः आपका डेटाबेस FULLरिकवरी मोड में है। यदि नहीं, तो सुनिश्चित करें कि यह है:
ALTER DATABASE yourdb SET RECOVERY FULL;
यहां तक कि अगर आप नियमित पूर्ण बैकअप ले रहे हैं, तो लॉग फ़ाइल तब तक बढ़ेगी और बढ़ेगी जब तक आप लॉग बैकअप नहीं लेते हैं - यह आपकी सुरक्षा के लिए है, न कि आपके डिस्क स्थान पर अनावश्यक रूप से खाने के लिए। आपको अपने रिकवरी उद्देश्यों के अनुसार, इन लॉग बैकअप को बार-बार करना चाहिए। उदाहरण के लिए, यदि आपके पास एक व्यावसायिक नियम है जो बताता है कि आप आपदा की स्थिति में 15 मिनट से कम डेटा नहीं खो सकते हैं, तो आपके पास एक नौकरी होनी चाहिए जो हर 15 मिनट में लॉग का बैकअप लेती है। यहां एक स्क्रिप्ट है जो मौजूदा समय के आधार पर टाइमस्टैम्पड फ़ाइल नाम उत्पन्न करेगा (लेकिन आप इसे रखरखाव योजनाओं आदि के साथ भी कर सकते हैं, बस रखरखाव योजनाओं में से किसी भी हटना विकल्प का चयन न करें, वे भयानक हैं)।
DECLARE @path NVARCHAR(255) = N'\\backup_share\log\yourdb_'
+ CONVERT(CHAR(8), GETDATE(), 112) + '_'
+ REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
+ '.trn';
BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;
ध्यान दें कि \\backup_share\एक अलग मशीन पर होना चाहिए जो एक अलग अंतर्निहित भंडारण उपकरण का प्रतिनिधित्व करता है। एक ही मशीन (या एक अलग मशीन में जो एक ही अंतर्निहित डिस्क का उपयोग करता है, या एक ही भौतिक होस्ट पर एक अलग VM का उपयोग करता है) के लिए इनका समर्थन करना वास्तव में आपकी मदद नहीं करता है, क्योंकि यदि मशीन चल रही है, तो आपने अपना डेटाबेस खो दिया है और इसके बैकअप। आपके नेटवर्क इन्फ्रास्ट्रक्चर के आधार पर यह स्थानीय रूप से बैकअप के लिए अधिक समझ में आता है और फिर उन्हें पर्दे के पीछे एक अलग स्थान पर स्थानांतरित कर सकता है; या तो मामले में, आप उन्हें प्राथमिक डेटाबेस मशीन से जितनी जल्दी हो सके निकालना चाहते हैं।
अब, जब आपके पास नियमित रूप से लॉग बैकअप चल रहा है, तो लॉग फ़ाइल को कुछ और जो वह अब तक उड़ाया गया है, की तुलना में अधिक उचित है, को सिकोड़ना उचित होना चाहिए। इसका मतलब यह नहीं है SHRINKFILEकि लॉग फ़ाइल 1 एमबी तक बार-बार चल रही है - भले ही आप लॉग को बार-बार बैकअप कर रहे हों, फिर भी इसे होने वाले किसी भी समवर्ती लेनदेन के योग को समायोजित करने की आवश्यकता है। लॉग फ़ाइल ऑटोज्रो इवेंट्स महंगे होते हैं, क्योंकि SQL सर्वर को फ़ाइलों को शून्य करना पड़ता है (डेटा फ़ाइलों के विपरीत जब त्वरित फ़ाइल आरंभीकरण सक्षम होता है), और ऐसा होने पर उपयोगकर्ता लेनदेन का इंतजार करना पड़ता है। आप इस ग्रोथ-सिकुड़न-बढ़ते-सिकुड़ते रूटीन को जितना हो सके कम करना चाहते हैं, और आप निश्चित रूप से अपने उपयोगकर्ताओं को इसके लिए भुगतान नहीं करना चाहते हैं।
ध्यान दें कि सिकुड़ने से पहले लॉग को दो बार बैकअप लेना पड़ सकता है (धन्यवाद रॉबर्ट)।
तो, आपको अपनी लॉग फ़ाइल के लिए एक व्यावहारिक आकार के साथ आने की आवश्यकता है। यहां कोई भी आपको यह नहीं बता सकता है कि आपके सिस्टम के बारे में बहुत कुछ जानने के बिना क्या है, लेकिन अगर आप लॉग फ़ाइल को बार-बार सिकोड़ रहे हैं और यह फिर से बढ़ रहा है, तो एक अच्छा वॉटरमार्क शायद 10-50% सबसे बड़ा है। । मान लीजिए कि 200 एमबी आता है, और आप चाहते हैं कि कोई भी ऑटोग्रॉथ इवेंट 50 एमबी का हो, तो आप लॉग फाइल का आकार इस तरह से समायोजित कर सकते हैं:
USE [master];
GO
ALTER DATABASE Test1
MODIFY FILE
(NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO
ध्यान दें कि यदि लॉग फ़ाइल वर्तमान में> 200 एमबी है, तो आपको इसे पहले चलाने की आवश्यकता हो सकती है:
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
यदि आप समय-समय पर पुनर्प्राप्ति के बारे में परवाह नहीं करते हैं
यदि यह एक परीक्षण डेटाबेस है, और आप पॉइंट-इन-टाइम रिकवरी के बारे में परवाह नहीं करते हैं, तो आपको यह सुनिश्चित करना चाहिए कि आपका डेटाबेस SIMPLEरिकवरी मोड में है।
ALTER DATABASE yourdb SET RECOVERY SIMPLE;
डेटाबेस को SIMPLEरिकवरी मोड में रखने से यह सुनिश्चित हो जाएगा कि SQL सर्वर सभी लेनदेन का रिकॉर्ड रखने के लिए बढ़ते हुए लॉग फ़ाइल (अनिवार्य रूप से निष्क्रिय लेनदेन को चरणबद्ध तरीके से) का पुन: उपयोग करता है (जैसे FULLरिकवरी तब तक होती है जब तक आप लॉग को वापस नहीं करते)। CHECKPOINTईवेंट लॉग को नियंत्रित करने में मदद करेंगे और यह सुनिश्चित करेंगे कि जब तक आप CHECKPOINTएस के बीच बहुत अधिक टी-लॉग गतिविधि नहीं उत्पन्न करते हैं, तब तक इसे बढ़ने की आवश्यकता नहीं है ।
अगला, आपको यह सुनिश्चित करना चाहिए कि यह लॉग वृद्धि वास्तव में एक असामान्य घटना (जैसे, एक वार्षिक वसंत सफाई या आपकी सबसे बड़ी अनुक्रमित पुनर्निर्माण) के कारण हुई है, और सामान्य, रोजमर्रा के उपयोग के कारण नहीं। यदि आप लॉग फ़ाइल को एक हास्यास्पद छोटे आकार में सिकोड़ते हैं, और SQL सर्वर को अपनी सामान्य गतिविधि को समायोजित करने के लिए इसे फिर से बढ़ाना पड़ता है, तो आपको क्या लाभ होगा? क्या आप उस डिस्क स्थान का उपयोग करने में सक्षम थे जिसे आपने केवल अस्थायी रूप से मुक्त किया था? यदि आपको तत्काल सुधार की आवश्यकता है, तो आप निम्नलिखित को चला सकते हैं:
USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
GO
अन्यथा, एक उचित आकार और विकास दर निर्धारित करें। पॉइंट-इन-टाइम रिकवरी केस में उदाहरण के अनुसार, आप यह निर्धारित करने के लिए एक ही कोड और लॉजिक का उपयोग कर सकते हैं कि क्या फ़ाइल का आकार उचित है और उचित ऑटोग्रॉथ पैरामीटर सेट करें।
कुछ चीजें जो आप नहीं करना चाहते हैं
TRUNCATE_ONLYविकल्प के साथ लॉग का बैकअप लें और फिरSHRINKFILE । एक के लिए, यह TRUNCATE_ONLYविकल्प हटा दिया गया है और अब SQL सर्वर के वर्तमान संस्करणों में उपलब्ध नहीं है। दूसरा, यदि आप FULLपुनर्प्राप्ति मॉडल में हैं, तो यह आपकी लॉग श्रृंखला को नष्ट कर देगा और एक नए, पूर्ण बैकअप की आवश्यकता होगी।
डेटाबेस को अलग करें, लॉग फ़ाइल को हटा दें और फिर से संलग्न करें । मैं इस बात पर जोर नहीं दे सकता कि यह कितना खतरनाक हो सकता है। आपका डेटाबेस वापस नहीं आ सकता है, यह संदिग्ध के रूप में सामने आ सकता है, आपको एक बैकअप (यदि आपके पास एक है, आदि) को वापस करना पड़ सकता है।
"सिकुड़ डेटाबेस" विकल्प का उपयोग करें । DBCC SHRINKDATABASEऔर ऐसा करने के लिए रखरखाव योजना विकल्प बुरे विचार हैं, खासकर यदि आपको वास्तव में केवल लॉग समस्या का समाधान करने की आवश्यकता है। उस फ़ाइल को लक्षित करें जिसे आप स्वतंत्र रूप से समायोजित और समायोजित करना चाहते हैं, ( DBCC SHRINKFILEया ALTER DATABASE ... MODIFY FILEऊपर दिए गए उदाहरण)।
लॉग फ़ाइल को 1 MB तक सिकोड़ें । यह आकर्षक लग रहा है क्योंकि, हे, SQL सर्वर मुझे कुछ परिदृश्यों में ऐसा करने देगा, और इसे मुक्त करने वाले सभी स्थान को देखेगा! जब तक आपके डेटाबेस को केवल पढ़ा जाता है (और यह है, तो आपको इसे इस तरह के उपयोग के रूप में चिह्नित करना चाहिए ALTER DATABASE), यह बिल्कुल कई अनावश्यक विकास घटनाओं को जन्म देगा, क्योंकि लॉग को पुनर्प्राप्ति मॉडल की परवाह किए बिना वर्तमान लेनदेन को समायोजित करना होगा। उस स्थान को अस्थायी रूप से मुक्त करने का क्या मतलब है, बस एसक्यूएल सर्वर इसे धीरे-धीरे और दर्द से वापस ले सकता है?
एक दूसरी लॉग फ़ाइल बनाएँ । यह उस ड्राइव के लिए अस्थायी रूप से राहत प्रदान करेगा जिसने आपकी डिस्क को भर दिया है, लेकिन यह एक बैंड-सहायता के साथ छिद्रित फेफड़े को ठीक करने की कोशिश करने जैसा है। आपको केवल एक और संभावित समस्या को जोड़ने के बजाय समस्याग्रस्त लॉग फ़ाइल से सीधे निपटना चाहिए। कुछ लेनदेन लॉग गतिविधि को एक अलग ड्राइव पर पुनर्निर्देशित करने के अलावा, दूसरी लॉग फ़ाइल वास्तव में आपके लिए (एक दूसरी डेटा फ़ाइल के विपरीत) कुछ भी नहीं करती है, क्योंकि केवल एक फ़ाइल का उपयोग कभी भी किया जा सकता है। पॉल रैंडल यह भी बताते हैं कि कई लॉग फाइलें आपको बाद में क्यों काट सकती हैं ।
सक्रिय होना
अपनी लॉग फ़ाइल को कुछ छोटी राशि में सिकोड़ने और इसे अपने आप एक छोटी दर पर लगातार ऑटोग्रॉ करने देने के बजाय, इसे कुछ यथोचित बड़े आकार में सेट करें (एक जो समवर्ती लेनदेन के आपके सबसे बड़े सेट का योग समायोजित करेगा) और एक उचित ऑटोग्रो सेट करें एक गिरावट के रूप में स्थापित करना, ताकि एकल लेनदेन को संतुष्ट करने के लिए कई बार विकसित न होना पड़े और इसलिए कि सामान्य व्यवसाय संचालन के दौरान इसे कभी-कभी विकसित करना अपेक्षाकृत दुर्लभ होगा।
यहां सबसे खराब संभव सेटिंग्स 1 एमबी विकास या 10% वृद्धि हैं। मजाकिया तौर पर, ये SQL सर्वर के लिए डिफॉल्ट हैं (जिनके बारे में मैंने शिकायत की है और बिना किसी लाभ के बदलाव के लिए पूछा है ) - डेटा फ़ाइलों के लिए 1 एमबी, और लॉग फ़ाइलों के लिए 10%। पूर्व इस दिन और उम्र में बहुत छोटा है, और बाद में हर बार लंबी और लंबी घटनाएं होती हैं (कहते हैं, आपकी लॉग फ़ाइल 500 एमबी है, पहली वृद्धि 50 एमबी है, अगली वृद्धि 55 एमबी है, अगली वृद्धि 60.5 एमबी है , इत्यादि - और धीमी आई / ओ पर, मेरा विश्वास करो, आप वास्तव में इस वक्र को नोटिस करेंगे)।
आगे की पढाई
कृपया यहाँ मत रुकिए; लॉग फ़ाइल के सिकुड़ने के बारे में आप जो सलाह देते हैं, उसमें से बहुत कुछ गलत है और संभावित रूप से विनाशकारी भी है, लेकिन कुछ लोग ऐसे भी हैं जो डिस्क स्पेस को खाली करने की तुलना में डेटा अखंडता की अधिक परवाह करते हैं।
