577

मैं एक SQL विशेषज्ञ नहीं हूं, और मुझे हर बार मूल बातें से परे कुछ करने की आवश्यकता के बारे में याद दिलाया जाता है। मेरे पास एक परीक्षण डेटाबेस है जो आकार में बड़ा नहीं है, लेकिन लेनदेन लॉग निश्चित रूप से है। मैं लेन-देन लॉग को कैसे साफ़ करूं?

sql-server transaction-log

— Kilhoffer
स्रोत

SQL Server 2005 में लेन-देन लॉग फ़ाइल को सिकोड़ने के लिए DBCC SHRINKFILE स्टेटमेंट का उपयोग कैसे करें

— गुलज़ार नाजिम

3

प्रबंध स्टूडियो में एक कमांड होनी चाहिए: "लॉग पर क्लिक करें हटना" और आपका काम हो गया।

— फ्रेंच जू

748

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

सबसे पहले, एक पूर्ण बैकअप लें

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

अगर आप पॉइंट-इन-टाइम रिकवरी की परवाह करते हैं

(और पॉइंट-इन-टाइम रिकवरी से मेरा मतलब है कि आप पूर्ण या अंतर बैकअप के अलावा किसी भी चीज़ को पुनर्स्थापित करने में सक्षम होने के बारे में परवाह करते हैं।)

संभवतः आपका डेटाबेस 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एस के बीच बहुत अधिक टी-लॉग गतिविधि उत्पन्न न करें ।

अगला, आपको यह सुनिश्चित करना चाहिए कि यह लॉग वृद्धि वास्तव में एक असामान्य घटना (जैसे, एक वार्षिक वसंत सफाई या आपके सबसे बड़े अनुक्रमित पुनर्निर्माण) के कारण हुई है, और सामान्य, रोजमर्रा के उपयोग के कारण नहीं। यदि आप लॉग फ़ाइल को एक हास्यास्पद छोटे आकार में सिकोड़ते हैं, और 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 MB तक सिकोड़ें । यह आकर्षक लग रहा है क्योंकि, अरे, SQL सर्वर मुझे कुछ परिदृश्यों में ऐसा करने देगा, और इसे मुक्त करने वाले सभी स्थान को देखेगा! जब तक आपके डेटाबेस को केवल पढ़ा नहीं जाता है (और यह है, आपको इसे इस तरह के उपयोग के रूप में चिह्नित करना चाहिए ALTER DATABASE), यह बिल्कुल कई अनावश्यक विकास घटनाओं को जन्म देगा, क्योंकि लॉग को पुनर्प्राप्ति मॉडल की परवाह किए बिना वर्तमान लेनदेन को समायोजित करना होगा। उस स्थान को अस्थायी रूप से मुक्त करने का क्या मतलब है, बस एसक्यूएल सर्वर इसे धीरे-धीरे और दर्द से वापस ले सकता है?
एक दूसरी लॉग फ़ाइल बनाएँ । यह उस ड्राइव के लिए अस्थायी रूप से राहत प्रदान करेगा जिसने आपकी डिस्क को भर दिया है, लेकिन यह बैंड-सहायता के साथ छिद्रित फेफड़े को ठीक करने की कोशिश कर रहा है। आपको किसी अन्य संभावित समस्या को जोड़ने के बजाय समस्याग्रस्त लॉग फ़ाइल से सीधे निपटना चाहिए। कुछ लेनदेन लॉग गतिविधि को एक अलग ड्राइव पर पुनर्निर्देशित करने के अलावा, एक दूसरी लॉग फ़ाइल वास्तव में आपके लिए कुछ भी नहीं करती है (एक दूसरी डेटा फ़ाइल के विपरीत), क्योंकि केवल एक फ़ाइल का उपयोग कभी भी किया जा सकता है। पॉल रैंडल यह भी बताते हैं कि कई लॉग फाइलें आपको बाद में क्यों काट सकती हैं ।

सक्रिय होना

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

यहां सबसे खराब संभव सेटिंग्स 1 एमबी विकास या 10% वृद्धि हैं। अजीब बात है, ये SQL सर्वर के लिए डिफॉल्ट हैं (जिनके बारे में मैंने शिकायत की है और बिना किसी लाभ के बदलाव के लिए कहा है ) - डेटा फ़ाइलों के लिए 1 एमबी, और लॉग फ़ाइलों के लिए 10%। पूर्व इस दिन और उम्र में बहुत छोटा है, और बाद वाला हर बार लंबी और लंबी घटनाओं की ओर जाता है (कहते हैं, आपकी लॉग फ़ाइल 500 एमबी है, पहली वृद्धि 50 एमबी है, अगली वृद्धि 55 एमबी है, अगली वृद्धि 60.5 एमबी है , इत्यादि - और धीमी आई / ओ पर, मेरा विश्वास करो, आप वास्तव में इस वक्र को नोटिस करेंगे)।

आगे की पढाई

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

एक ब्लॉग पोस्ट जो मैंने 2009 में लिखी थी, जब मैंने कुछ "यहाँ लॉग फ़ाइल को सिकोड़ने का तरीका देखा" पोस्ट स्प्रिंग अप ।

एक ब्लॉग पोस्ट ब्रेंट ओजर ने चार साल पहले लिखा था, जो एक SQL सर्वर मैगज़ीन के लेख के जवाब में कई संसाधनों की ओर इशारा करता था, जिसे प्रकाशित नहीं किया जाना चाहिए था ।

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

माइक वाल्श के पास इन पहलुओं में से कुछ को कवर करने का एक शानदार उत्तर भी है, जिसमें ऐसे कारण भी शामिल हैं कि आप अपनी लॉग फ़ाइल को तुरंत सिकोड़ नहीं सकते ।

— हारून बर्ट्रेंड
स्रोत

5

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

— रॉबर्ट एल डेविस

9

इस तरफ, यह इस पृष्ठ पर दिया गया सबसे पूर्ण और सही उत्तर है।

— रॉबर्ट एल डेविस

11

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

— रॉबर्ट एल डेविस

2

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

— हारून बर्ट्रेंड

3

@zinczinc ठीक है, आपकी प्रतिक्रिया के लिए धन्यवाद। समस्या मैं पहले जवाब और बाद में स्पष्टीकरण के साथ देख रहा हूं कि वे महत्वपूर्ण भागों को कभी नहीं पढ़ेंगे। व्याख्यान मैं पाठक के साथ डूब जाता है वास्तव में अंत में उत्तर की तुलना में कहीं अधिक महत्वपूर्ण है, और IMHO पृष्ठभूमि मैं उन विकल्पों को बनाने के लिए बहुत महत्वपूर्ण है। लेकिन हे, यदि आप एक-लाइन उत्तर प्रस्तुत करना चाहते हैं क्योंकि आपको लगता है कि ओपी के लिए बेहतर है, तो कृपया मेरे उत्तर के उस हिस्से का उपयोग करने के लिए स्वतंत्र महसूस करें, जिससे हम सभी सीख सकें।

— हारून बर्ट्रेंड

201

-- DON'T FORGET TO BACKUP THE DB :D (Check [here][1]) 


USE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO

प्रेषक: DBCC SHRINKFILE (लेनदेन-एसक्यूएल)

आप पहले बैकअप लेना चाह सकते हैं।

— रुई लीमा
स्रोत

धन्यवाद Maimonides, डॉक्स से, तो मैं कहूंगा कि यह सबसे अच्छा है: पी विशेष रूप से क्योंकि मेरे द्वारा आविष्कार नहीं किया गया था :)

— रुई लीमा

1

ऐसा करने के बाद, मेरा लॉग आकार थोड़ा नहीं बदला है। क्या मैंने कुछ गलत किया?

— chester89

1

यह दृष्टिकोण "फुल" के लिए पुनर्प्राप्ति प्रकार सेट करता है, भले ही पुनर्प्राप्ति प्रकार पहले कुछ और था

— विला

1

जादू की तरह काम किया! ध्यान दें कि लॉग फ़ाइल का नाम वास्तव में इसका तार्किक नाम है (जो db-> गुण-> फाइलों में पाया जा सकता है)

— बिशन

2

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

— सीजर

185

अस्वीकरण: कृपया नीचे टिप्पणी को ध्यान से पढ़ें, और मुझे लगता है कि आप पहले से ही स्वीकृत उत्तर पढ़ चुके हैं। जैसा कि मैंने लगभग 5 साल पहले कहा था:

अगर किसी के पास ऐसी स्थितियों के लिए जोड़ने के लिए कोई टिप्पणी है जब यह पर्याप्त या इष्टतम समाधान नहीं है तो कृपया नीचे टिप्पणी करें

डेटाबेस के नाम पर राइट क्लिक करें।
कार्य → → सिंक → डेटाबेस का चयन करें
फिर क्लिक करें OK!

मैं आमतौर पर डेटाबेस फ़ाइलों से युक्त विंडोज एक्सप्लोरर निर्देशिका को खोलता हूं, इसलिए मैं तुरंत प्रभाव देख सकता हूं।

मैं वास्तव में काफी आश्चर्यचकित था यह काम किया! आम तौर पर मैंने पहले डीबीसीसी का उपयोग किया है, लेकिन मैंने बस कोशिश की है और यह कुछ भी नहीं सिकुड़ता है, इसलिए मैंने जीयूआई (2005) की कोशिश की और इसने बहुत अच्छा काम किया - 10 सेकंड में 17 जीबी मुक्त करना

पूर्ण पुनर्प्राप्ति मोड में यह काम नहीं कर सकता है, इसलिए आपको या तो पहले लॉग का बैकअप लेना होगा, या सरल पुनर्प्राप्ति में बदलना होगा, फिर फ़ाइल को सिकोड़ना होगा। [इसके लिए धन्यवाद @onupdatecascade]

-

पुनश्च: मैं इस बात की सराहना करता हूं कि कुछ लोगों ने इसके खतरों के बारे में क्या टिप्पणी की है, लेकिन मेरे वातावरण में मुझे ऐसा करने में कोई समस्या नहीं है, खासकर जब से मैं हमेशा एक पूर्ण बैकअप लेता हूं। तो कृपया ध्यान रखें कि आपका पर्यावरण क्या है, और यह कैसे जारी रखने से पहले आपकी बैकअप रणनीति और नौकरी की सुरक्षा को प्रभावित करता है। मैं जो कुछ कर रहा था, वह लोगों को Microsoft द्वारा प्रदान की गई सुविधा की ओर इशारा कर रहा था!

— Simon_Weaver
स्रोत

50

पूर्ण पुनर्प्राप्ति मोड में यह काम नहीं कर सकता है, इसलिए आपको या तो पहले लॉग का बैकअप लेना होगा, या सरल पुनर्प्राप्ति में बदलना होगा, फिर फ़ाइल को सिकोड़ना होगा।

— onupdatecascade

7

@onupdatecascade - पूर्ण पुनर्प्राप्ति चाल पर अच्छा कॉल। एक विशाल लॉग के साथ एक और डेटाबेस था: सरल पर स्विच किया गया, फिर डेटाबेस को सिकोड़ें और वापस पूर्ण पर स्विच किया। 500kb पर लॉग इन करें फ़ाइल!

— साइमन_वेक

26

माफ़ करना। लेकिन यह जवाब केवल गलत नहीं हो सकता। डेटाबेस सिकुड़ने से आप लेनदेन लॉग फ़ाइल को विकसित करेंगे। जब भी आप SQL सर्वर डेटाबेस में डेटा स्थानांतरित करते हैं, तो आपको लॉग फ़ाइल को लॉगिंग - लॉगिंग की आवश्यकता होगी। लॉग साइज़ को कम करने के लिए, या तो डीबी को सिंपल रिकवरी में सेट करें या (यदि आपको लॉग इन डेटा की आवश्यकता है / है - और आप लगभग हमेशा उत्पादन में हैं) लॉग का बैकअप लें। इन सरल, मुफ्त, वीडियो में अधिक विवरण: sqlservervideos.com/video/logging-essentials sqlservervideos.com/video/sql2528-log-files

— माइकल के। कैंपबेल

30

वाह, इस जवाब के लिए 1300+ प्रतिनिधि पाने के लिए यश, लेकिन यह वास्तव में भयानक सलाह है।

— हारून बर्ट्रेंड

8

यहां यह प्रदर्शित करने के लिए एक अतिशयोक्ति है कि क्या हो रहा है और क्यों सिकुड़ रहा है आवधिक आधार पर बिल्कुल महत्वपूर्ण है: एक बैकअप करने से पहले रिकॉर्ड ए को 1 मिलियन बार बदल दिया जाता है। लॉग में क्या है? डेटा के 999,999 टुकड़े जो अप्रासंगिक हैं। यदि लॉग कभी सिकुड़ते नहीं हैं, तो आप कभी नहीं जान पाएंगे कि डेटाबेस का सही ऑपरेटिंग खर्च क्या है। इसके अलावा, आप एक सैन पर मूल्यवान संसाधनों को गले लगा रहे हैं, सबसे अधिक संभावना है। सिकुड़ना अच्छा रखरखाव है और आपको अपने पर्यावरण के संपर्क में रखता है। मुझे किसी ऐसे व्यक्ति को दिखाएं जो सोचता है कि आपको कभी नहीं हटना चाहिए और मैं आपको किसी को उनके पर्यावरण की अनदेखी करते हुए दिखाऊंगा।

— न्यूक्लिच

54

नीचे लेन-देन लॉग को सिकोड़ने के लिए एक स्क्रिप्ट है, लेकिन मैं इसे सिकोड़ने से पहले लेनदेन लॉग का बैकअप लेने की सलाह जरूर दूंगा।

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

लेन-देन लॉग भी एक समय पर पुनर्प्राप्ति में इंगित करने के लिए आता है, इसलिए इसे फेंक न दें, लेकिन सुनिश्चित करें कि आप इसे पहले ही वापस कर दें।

यहां कई पोस्ट हैं जहां लोगों ने पुनर्प्राप्ति को पूरा करने के लिए लेनदेन लॉग में संग्रहीत डेटा का उपयोग किया:

USE DATABASE_NAME;
GO

ALTER DATABASE DATABASE_NAME
SET RECOVERY SIMPLE;
GO
--First parameter is log file name and second is size in MB
DBCC SHRINKFILE (DATABASE_NAME_Log, 1);

ALTER DATABASE DATABASE_NAME
SET RECOVERY FULL;
GO

आपको एक त्रुटि मिल सकती है जो ऊपर दिए गए आदेशों को निष्पादित करते समय इस तरह दिखती है

"लॉग फ़ाइल (लॉग फ़ाइल का नाम) को छोटा नहीं कर सकता क्योंकि फ़ाइल के अंत में स्थित तार्किक लॉग फ़ाइल उपयोग में है"

इसका मतलब है कि TLOG उपयोग में है। इस मामले में कई बार इसे निष्पादित करने का प्रयास करें या डेटाबेस गतिविधियों को कम करने का तरीका खोजें।

— माइकल डाल्टन
स्रोत

30

यहाँ एक सरल और बहुत अशुभ और संभावित खतरनाक तरीका है।

बैकअप डीबी
डीबी को अलग करें
लॉग फ़ाइल का नाम बदलें
डीबी संलग्न करें
नई लॉग फ़ाइल को फिर से बनाया जाएगा
नाम बदलें लॉग फ़ाइल हटाएँ।

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

— जॉननो नोलन
स्रोत

15

सम्मानपूर्वक, लॉग को बदलना / नाम बदलना / फिर से भरना / बदलना बहुत बुरा विचार है। सिकुड़ना कम जोखिम भरा होना चाहिए, इसके अलावा यह करना बहुत आसान है।

— onupdatecascade

12

+1 - Inelegant या नहीं, इस विधि ने मुझे गर्म पानी से दो बार डेटाबेस लॉग के साथ पूरा डिस्क भर दिया है, जैसे कि एक हटना कमांड भी नहीं चल सकता है।

— शुल बेहार

3

क्या लॉग में मौजूद अनियंत्रित लेनदेन का जोखिम नहीं है?

— पॉल

यह छोटे डीबी के लिए भी ठीक हो सकता है, लेकिन अगर आपके पास 3 या 4 टीबी डीबी है, तो यह सबसे अच्छा समाधान नहीं हो सकता है।

— जायस

यह ठीक लगता है यदि आप लंबे समय से एक प्रणाली विकसित कर रहे हैं और देव अवधि के दौरान हजारों रिकॉर्ड लोड / डिलीट कर रहे हैं। फिर जब आप इस डेटाबेस का उपयोग जीवित रहने के लिए करना चाहते हैं, तो परीक्षण / विकास डेटा जो लॉग किया गया है, वह बेमानी है और इसलिए अगर यह खो जाए तो कोई फर्क नहीं पड़ता?

— JsonStatham 12

28

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

यदि आप SQL 7 या 2000 का उपयोग कर रहे हैं, तो आप डेटाबेस विकल्प टैब में "चेकपॉइंट लॉग ऑन करें" सक्षम कर सकते हैं। इसका एक ही प्रभाव है।

यह उत्पादन वातावरण में स्पष्ट रूप से शामिल नहीं है, क्योंकि आप समय में एक बिंदु पर बहाल नहीं कर पाएंगे।

— जोनाथन
स्रोत

1

पुनर्प्राप्ति मोड को सरल पर सेट करना, अपने आप ही, जादुई रूप से लेन-देन लॉग को छोटा नहीं करेगा।

— आरोन बर्ट्रेंड

@ ऐरन इस पर नहीं, खुद पर। मैंने मान लिया कि ओपी अपने परीक्षण डेटाबेस का उपयोग कर रहा होगा, और इसलिए "लेन-देन लॉग बहुत जल्द सिकुड़ जाएगा", लेकिन आप सही हैं कि यह एक साइड इफेक्ट का अधिक है: रिकवरी मोड ऑफ सिंपल शायद आपको एक सिकुड़ा हुआ अंत देगा। लेन-देन लॉग जल्द ही

— जोनाथन

" Simple... और फिर कभी नहीं भरना" - सच नहीं है। मैंने देखा है कि यह (पिछले 48 घंटों में) एक डेटाबेस पर होता है जहां रिकवरी मॉडल "SIMPLE" पर सेट किया गया था। लॉगफाइल की फाइलग्रोथ "प्रतिबंधित" करने के लिए सेट की गई थी, और हम इस पर कुछ अपार गतिविधि कर रहे थे ... मैं समझता हूं कि यह एक असामान्य स्थिति थी। (हमारी स्थिति में, जहां हमारे पास बहुत अधिक डिस्क स्थान था, हमने लॉगफ़ाइल आकार में वृद्धि की, और लॉगफ़ाइल फ़ाइलग्रॉथ को "अप्रतिबंधित" पर सेट किया ... जो कि वैसे भी --interface बग-- दिखाता है, परिवर्तन के बाद, जैसा कि प्रतिबंधित है "2,097,152 एमबी की अधिकतम सीमा के साथ।)

— डग_इज़न

2

@Doug_Ivison हां, लेन-देन लॉग में खुला लेनदेन होगा, लेकिन एक चेकपॉइंट लगने के बाद उन्हें सरल मोड में हटा दिया जाएगा। यह उत्तर केवल एक त्वरित के रूप में है "मेरे विकास / परीक्षण बॉक्स में एक बड़ा लेनदेन लॉग है, और मैं इसे दूर जाना चाहता हूं इसलिए मुझे इसके बारे में अक्सर चिंता करने की ज़रूरत नहीं है", बजाय उत्पादन में जाने के लिए। वातावरण। पुन: पुनरावृति करने के लिए: उत्पादन में ऐसा न करें ।

— जोनाथन

1

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

— डग_इवन जेल

9

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

— mrdenny
स्रोत

... लेकिन मैंने इसे बिना किसी मुद्दे के दर्जनों बार किया है। शायद आप समझा सकते हैं कि डीबी पुनः क्यों संलग्न नहीं हो सकता है।

— जॉननो नोलन

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

— मन्दिर

4

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

— हारून बर्ट्रेंड

2

बहुत, बहुत सच्चा हारून।

— मर्देनी

हां, यह सिर्फ हमारे साथ हुआ। हम लॉग फ़ाइल के 20G को खोद कर रखना चाहते थे क्योंकि हम डेटाबेस को ले जाने से पहले डेटा का बैकअप लेते थे। कोई रास्ता नहीं MSSQL हमें विनम्र लॉग फ़ाइल के बिना नए डेटाबेस को फिर से संलग्न करने की अनुमति देगा।

— जॉर्ज एम। मोनिका

9

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

लॉग फ़ाइल को खत्म करना (इसे काटकर, इसे त्यागकर, इसे मिटाकर, आदि) आपकी बैकअप श्रृंखला को तोड़ देगा, और अगले पूर्ण होने तक आपके अंतिम पूर्ण, अंतर या लेनदेन लॉग बैकअप के बाद से किसी भी समय आपको किसी भी समय बहाल करने से रोकेगा। या अंतर बैकअप किया जाता है।

से पर Microsoft लेखBACKUP

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

इससे बचने के लिए, अपनी लॉग फ़ाइल को सिकोड़ने से पहले बैकअप लें । वाक्य रचना कुछ इस तरह दिखाई देगी:

BACKUP LOG MyDatabaseName 
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)

— राहेल
स्रोत

3

मैं आपके उत्तर से सहमत हूँ, , 1)भाग को छोड़कर । समस्या यह है कि यदि आप इसे 1 एमबी तक सिकोड़ते हैं, तो वृद्धि की घटनाओं को सामान्य लॉग आकार में ले जाना काफी महंगा हो जाएगा, और उनमें से कई होंगे यदि विकास दर 10% के डिफ़ॉल्ट पर छोड़ दी जाती है।

— हारून बर्ट्रेंड

9

SQL सर्वर लेन-देन लॉग को ठीक से बनाए रखने की आवश्यकता है ताकि इसकी अवांछित वृद्धि को रोका जा सके। इसका मतलब है कि लेन-देन लॉग बैकअप अक्सर पर्याप्त होता है। ऐसा नहीं करने से, आप लेन-देन लॉग को पूर्ण होने का जोखिम उठाते हैं और बढ़ने लगते हैं।

इस प्रश्न के उत्तर के अलावा, मैं लेन-देन लॉग कॉमन मिथकों को पढ़ने और समझने की सलाह देता हूं। ये रीडिंग लेन-देन लॉग को समझने और यह तय करने में मदद कर सकती हैं कि इसे "स्पष्ट" करने के लिए किन तकनीकों का उपयोग करना है:

से 10 सबसे महत्वपूर्ण एसक्यूएल सर्वर लेनदेन लॉग मिथकों :

मिथक: मेरा SQL सर्वर बहुत व्यस्त है। मैं SQL सर्वर लेनदेन लॉग बैकअप नहीं बनाना चाहता

SQL सर्वर में सबसे बड़े प्रदर्शन गहन ऑपरेशनों में से एक ऑनलाइन लेनदेन लॉग फ़ाइल का ऑटो-ग्रो इवेंट है। लेन-देन लॉग बैकअप को अक्सर पर्याप्त नहीं बनाने से, ऑनलाइन लेनदेन लॉग पूर्ण हो जाएगा और विकसित करना होगा। डिफ़ॉल्ट वृद्धि का आकार 10% है। डेटाबेस जितना व्यस्त होगा, ऑनलाइन लेन-देन लॉग तेज होगा, अगर लेन-देन लॉग बैकअप नहीं बनते हैं, तो SQL सर्वर ट्रांजेक्शन लॉग बैकअप बनाना ऑनलाइन ट्रांजेक्शन लॉग को ब्लॉक नहीं करता है, लेकिन ऑटो-ग्रोथ इवेंट करता है। यह ऑनलाइन लेन-देन लॉग में सभी गतिविधि को ब्लॉक कर सकता है

से लेन-देन लॉग मिथकों :

मिथक: नियमित लॉग सिकुड़ना एक अच्छा रखरखाव अभ्यास है

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

— McRobert
स्रोत

5

पहले डेटाबेस रिकवरी मॉडल की जाँच करें। डिफ़ॉल्ट रूप से, SQL सर्वर एक्सप्रेस संस्करण सरल पुनर्प्राप्ति मॉडल के लिए एक डेटाबेस बनाता है (यदि मैं गलत नहीं हूं)।

बैकअप लॉग डेटाबेस के साथ Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile आपको तार्किक लॉग फ़ाइल नाम देगा।

को देखें:

SQL सर्वर डेटाबेस में पूर्ण हस्तांतरण लॉग से पुनर्प्राप्त करें

यदि आपका डेटाबेस फुल रिकवरी मॉडल में है और यदि आप टीएल बैकअप नहीं ले रहे हैं, तो इसे SIMPLE में बदल दें।

— पीटर मोर्टेंसन
स्रोत

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

— जून

TRUNCATE_ONLYSQL सर्वर के वर्तमान संस्करणों में अब कोई विकल्प नहीं है, और यह उन संस्करणों पर अनुशंसित नहीं है जो इसका समर्थन करते हैं ( राहेल का जवाब देखें )।

— आरोन बर्ट्रेंड

5

DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY)कमांड का उपयोग करें । यदि यह एक परीक्षण डेटाबेस है और आप अंतरिक्ष को बचाने / पुनः प्राप्त करने का प्रयास कर रहे हैं, तो इससे मदद मिलेगी।

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

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

लेन-देन लॉग को कभी न हटाएं - आप डेटा खो देंगे! आपके डेटा का एक हिस्सा TX लॉग (रिकवरी मॉडल की परवाह किए बिना) में है ... यदि आप TX लॉग फ़ाइल को अलग करते हैं और उसका नाम बदल देते हैं जो आपके डेटाबेस के हिस्से को प्रभावी ढंग से हटा देता है।

उन लोगों के लिए, जिन्होंने TX लॉग को हटा दिया है, आप कुछ डेटा कमांड खो सकते हैं और अधिक डेटा खो देने से पहले भ्रष्टाचार को ठीक कर सकते हैं।

पॉल रान्डल के ब्लॉग पोस्टों को इस विषय पर देखें, बुरी सलाह ।

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

पॉल की वेबसाइट देखें - वह इन सवालों को कवर करता है। पिछले महीने उन्होंने अपनी मिथक ए डे सीरीज़ में इनमें से कई मुद्दों पर बात की ।

— ripvlan
स्रोत

+1 यह उल्लेख करने के लिए पहला उत्तर होने के लिए कि यह एक अच्छा विचार नहीं हो सकता है! ओपी एक परीक्षण डेटाबेस निर्दिष्ट करता है, लेकिन यह अधिक सामान्य मामले के लिए बनाने लायक एक बिंदु है।

— मार्टिन स्मिथ

मुझे जोड़ना चाहिए था - यदि आप TX लॉग हटाते हैं - अपडेट फिर से शुरू करें!

— रिपव्लन

4

लॉग फ़ाइल को छोटा करने के लिए:

डेटाबेस बैकअप
डेटाबेस को एंटर करें, या तो एंटरप्राइज़ मैनेजर का उपयोग करके या निष्पादित करके: Sp_DetachDB [DBName]
ट्रांजेक्शन लॉग फाइल को डिलीट करें। (या फ़ाइल का नाम बदलें, बस मामले में)
डेटाबेस का फिर से उपयोग करके पुनः संलग्न करें: Sp_AttachDB [DBName]
जब डेटाबेस संलग्न होता है, तो एक नया लेनदेन लॉग फ़ाइल बनाई जाती है।

लॉग फ़ाइल को सिकोड़ें:

No_Log के साथ बैकअप लॉग [DBName]
डेटाबेस को या तो सिकोड़ें:

एंटरप्राइज़ मैनेजर का उपयोग करना: - डेटाबेस पर राइट क्लिक करें, सभी कार्य, डेटाबेस को सिकोड़ें, फ़ाइलें, लॉग फ़ाइल का चयन करें, ठीक है।

T-SQL का उपयोग करना: - Dbcc Shrinkfile ([Log_Logical_Name])

आप लॉग फ़ाइल का तार्किक नाम sp_helpdb चलाकर या एंटरप्राइज़ प्रबंधक में डेटाबेस के गुणों को देखकर पा सकते हैं।

— लियो मूर
स्रोत

कभी भी ट्रांजेक्शन लॉग को डिलीट न करें। आपके डेटा का एक हिस्सा लॉग में है। इसे हटा दें और डेटाबेस भ्रष्ट हो जाएगा। मुझे वोट देने से पीछे नहीं हटना है।

— रिप्लेन

4

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

डेटाबेस का एक बैकअप "tempdb" कोई मतलब नहीं रखता है, इसलिए इस db का पुनर्प्राप्ति मॉडल हमेशा "सरल" होना चाहिए।

— shmia
स्रोत

बस डेटाबेस को सरल पर सेट करना लॉग फ़ाइल को सिकोड़ नहीं पाएगा, जो भी वर्तमान में है। यह बस आगे बढ़ने से रोकने में मदद कर सकता है (लेकिन यह अभी भी हो सकता है)।

— आरोन बर्ट्रेंड

4

एमडीबी फ़ाइल का बैकअप लें।
SQL सेवाएँ बंद करें
लॉग फ़ाइल का नाम बदलें
सेवा शुरू करें

(सिस्टम एक नई लॉग फ़ाइल बनाएगा।)

हटाए गए लॉग फ़ाइल को हटाएं या स्थानांतरित करें।

— इब्राहिम
स्रोत

3

यह मेरे साथ हुआ जहां डेटाबेस लॉग फ़ाइल 28 जीबी की थी।

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

चरण 1: सबसे पहले डेटाबेस कमांड में इस कमांड को चलाएं, जो कि जांच चौकी है

चरण 2: डेटाबेस टास्क पर राइट क्लिक करें> बैक अप का चयन करें बैक अप टाइप करें ट्रांजेक्शन लॉग बैकअप डेटा (-bak) रखने के लिए एक गंतव्य पता और फ़ाइल का नाम जोड़ें।

इस चरण को दोबारा दोहराएं और इस समय एक और फ़ाइल नाम दें

स्टेप 3: अब डेटाबेस पर जाएं डेटाबेस पर राइट क्लिक करें

कार्य> सिकोड़ें> फ़ाइलें फ़ाइल प्रकार चुनें लॉग इन करें क्रिया को अप्रयुक्त स्थान के रूप में रिलीज़ करें

चरण 4:

SQL 2014 में सामान्य रूप से अपनी लॉग फ़ाइल की जाँच करें

C: \ Program Files \ Microsoft SQL Server \ MSSQL12.MSSQL2014EXPRESS \ MSSQL \ DATA

मेरे मामले में, यह 28 जीबी से घटकर 1 एमबी रह गया

— महेंद्र
स्रोत

2

इसे इस्तेमाल करे:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO

— मुहम्मद इमरान
स्रोत

TRUNCATE_ONLYSQL सर्वर के वर्तमान संस्करणों में अब कोई विकल्प नहीं है, और यह उन संस्करणों पर अनुशंसित नहीं है जो इसका समर्थन करते हैं ( राहेल का जवाब देखें )।

— हारून बर्ट्रेंड

यह मेरे लिए MSSQL सर्वर 2005 मानक संस्करण का उपयोग करके काम करता है

— bksi

2

डेटाबेस → राइट क्लिक गुण → फ़ाइल → एक अलग नाम के साथ एक और लॉग फ़ाइल जोड़ें और पथ को एक अलग फ़ाइल नाम के साथ पुरानी लॉग फ़ाइल के समान सेट करें।

डेटाबेस स्वचालित रूप से नव निर्मित लॉग फ़ाइल को उठाता है।

— Shashi3456643
स्रोत

1

बैकअप डीबी
डीबी को अलग करें
लॉग फ़ाइल का नाम बदलें
DB अटैच करें (नाम हटाते समय .ldf (लॉग फ़ाइल) संलग्न करें। इसे हटाएं और निकालें बटन दबाकर हटाएं)
नई लॉग फ़ाइल को फिर से बनाया जाएगा
नाम बदलें लॉग फ़ाइल हटाएँ।

यह काम करेगा लेकिन पहले आपके डेटाबेस का बैकअप लेने का सुझाव दिया गया है।

— गौतम सारस्वत
स्रोत

1

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

alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);

— हे
स्रोत

0

उदाहरण:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

— लक्ष्मण भारत से
स्रोत

TRUNCATE_ONLYSQL सर्वर के वर्तमान संस्करणों में अब कोई विकल्प नहीं है, और यह उन संस्करणों पर अनुशंसित नहीं है जो इसका समर्थन करते हैं ( राहेल का जवाब देखें )।

— आरोन बर्ट्रेंड

सहायता केंद्र में परिभाषित स्टैक ओवरफ्लो के लिए सवाल ऑन-टॉपिक नहीं है । कृपया ऐसे प्रश्नों का उत्तर न दें; इसके बजाय, आपको उन्हें ध्यान के लिए ध्वजांकित करना चाहिए और उन्हें उचित रूप से बंद या माइग्रेट किया जाएगा।

— टोबी स्पाइट

0

MSSQL 2017 के लिए, और SQL सर्वर प्रबंधन स्टूडियो का उपयोग करके थोड़ा अद्यतन उत्तर। मैं ज्यादातर इन निर्देशों से गया था https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/

मेरे पास हाल ही में डीबी बैकअप था, इसलिए मैंने लेनदेन लॉग का समर्थन किया। फिर मैंने इसे अच्छे उपाय के लिए फिर से बैकअप दिया। अंत में मैंने लॉग फ़ाइल को सिकोड़ लिया, और 20G से 7MB तक चला गया, मेरे डेटा के आकार के अनुरूप। मुझे नहीं लगता कि 2 साल पहले स्थापित किए गए लेन-देन लॉग का कभी बैकअप लिया गया था .. इसलिए उस कार्य को हाउसकीपिंग कैलेंडर पर डाल दिया।

— जॉर्ज एम। मोनिका को बहाल करें
स्रोत

-1

DB लेनदेन लॉग आकार में सिकोड़ें :

बैकअप: लेन-देन लॉग
फ़ाइलों को सिकोड़ें: लेन-देन लॉग
बैकअप: लेन-देन लॉग
फ़ाइलों को सिकोड़ें: लेन-देन लॉग

मैंने कई संख्या में DB पर परीक्षण किए: यह क्रम काम करता है ।

यह आमतौर पर 2MB तक सिकुड़ जाता है ।

या एक स्क्रिप्ट द्वारा:

DECLARE @DB_Name nvarchar(255);
DECLARE @DB_LogFileName nvarchar(255);
SET @DB_Name = '<Database Name>';               --Input Variable
SET @DB_LogFileName = '<LogFileEntryName>';         --Input Variable
EXEC 
(
'USE ['+@DB_Name+']; '+
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2) ' +
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2)'
)
GO

— पीटर नाज़रोव
स्रोत

1

TRUNCATE_ONLYSQL सर्वर के वर्तमान संस्करणों में अब कोई विकल्प नहीं है, और यह उन संस्करणों पर अनुशंसित नहीं है जो इसका समर्थन करते हैं ( राहेल का जवाब देखें )।

— हारून बर्ट्रेंड

SQL सर्वर लेन-देन लॉग को कैसे साफ़ करें?

सबसे पहले, एक पूर्ण बैकअप लें

अगर आप पॉइंट-इन-टाइम रिकवरी की परवाह करते हैं

यदि आप समय-समय पर पुनर्प्राप्ति के बारे में परवाह नहीं करते हैं

कुछ चीजें जो आप नहीं करना चाहते हैं

सक्रिय होना

आगे की पढाई

उदाहरण: