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