लेन-देन लॉग रात के बैकअप के साथ सरल पुनर्प्राप्ति मोड में क्यों बढ़ता रहता है

Question

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

विवरण: मेरे पास SQL ​​Server 2008 R2 पर ~ 500MB डेटाबेस, सभी SIMPLE रिकवरी मोड (मेरी पसंद नहीं), रात में पूर्ण बैकअप, ~ 200MB डेटा फ़ाइलों और ~ 300MB लॉग फ़ाइलों के साथ है। लॉग तुरंत 300 एमबी तक नहीं बढ़ता है, लेकिन धीरे-धीरे कुछ महीनों के दौरान। उनमें से किसी पर कोई खुला लेनदेन नहीं है, कम से कम sp_who2 और गतिविधि की निगरानी के अनुसार। अगर मैं डेटाबेस पर राइट-क्लिक करता हूं और संपत्तियों का चयन करता हूं, तो यह मुझे बताता है कि ~ 50 एमबी मुफ्त है। विशेष रूप से एक बैकअप के ठीक बाद, पूरे लॉग को मुफ्त नहीं होना चाहिए? जब तक कोई खुला लेन-देन न हो, तब तक SIMPLE मोड में लॉग फ्री नहीं होना चाहिए?

log_reuse_wait_descसे sys.databasesकहते हैं कहते हैं, "कुछ नहीं" है, जो सवाल पर आधारित है और ऊपर संदर्भित जवाब यह अंतरिक्ष का पुन: उपयोग करने के लिए कुछ पर प्रतीक्षा नहीं करना चाहिए।

अगर मैं 'DBCC SHRINKFILE' करता हूं, तो लॉग फ़ाइल 1MB तक सिकुड़ जाती है, इसलिए यह स्थान को पुनः प्राप्त करने के लिए तैयार है। मैं कुछ सेट कर सकता हूं जो लॉग को साप्ताहिक रूप से सिकोड़ता है और चीजों को नियंत्रण से बाहर रखता है, लेकिन मैं उलझन में हूं कि एसक्यूएल सर्वर मुझे ऐसा क्यों बना देगा।

मैं समझ सकता हूं कि क्या कुछ पागल लेनदेन था जिसे इसे लॉग करने के लिए 300MB की आवश्यकता थी, लेकिन हम कुछ भी चरम नहीं कर रहे हैं, बस मूल OLTP। माइक के सवाल / जवाब से:

सिंपल रिकवरी मॉडल - तो उपरोक्त परिचय के साथ, पहले सिंपल रिकवरी मॉडल के बारे में बात करना सबसे आसान है। इस मॉडल में, आप SQL सर्वर को बता रहे हैं - क्रैश और रिस्टार्ट रिकवरी के लिए अपनी ट्रांजेक्शन लॉग फाइल का उपयोग करके मैं आपके साथ ठीक हूं (आपके पास वास्तव में कोई विकल्प नहीं है .. ACID प्रॉपर्टीज देखें और यह समझ में जल्दी आना चाहिए), लेकिन एक बार आप नहीं उस क्रैश / पुनर्प्राप्ति उद्देश्य को पुन: प्रारंभ करने के लिए इसकी आवश्यकता है, आगे बढ़ें और लॉग फ़ाइल का पुन: उपयोग करें।

SQL सर्वर सिंपल रिकवरी में इस रिक्वेस्ट को सुनता है और यह केवल उन जानकारियों को रखता है जिन्हें क्रैश / रिस्टार्ट रिकवरी करने की आवश्यकता होती है। एक बार SQL सर्वर सुनिश्चित हो जाता है कि यह पुनर्प्राप्त हो सकता है क्योंकि डेटा को डेटा फ़ाइल (अधिक या कम) तक कठोर किया जाता है, जो डेटा कठोर किया गया है वह लॉग में अब आवश्यक नहीं है और ट्रंकेशन के लिए चिह्नित है - जिसका अर्थ है कि इसका पुनः उपयोग किया जाता है।

यह कहता है कि लॉग स्पेस का पुन: उपयोग किया जाना चाहिए, लेकिन महीनों के दौरान इस धीमी वृद्धि के साथ, ऐसा नहीं लगता है कि यह है।

मुझे किसकी याद आ रही है? क्या SQL सर्वर डेटा को "हार्ड" के रूप में पहचानने और लॉग को मुक्त करने से कुछ रखता है?

(संपादित करें) एक्शन रिपोर्ट के बाद - AKA थोड़ा ज्ञान खतरनाक है

यह पता लगाने के बाद कि यह एक "लोकप्रिय प्रश्न" है, मुझे ऐसा लगा जैसे मैंने 7 महीने पहले जो कुछ भी किया था, उस पर स्पष्टीकरण दिया और जो मैंने कुछ अन्य लोगों को कुछ दुःखों से बचाने के लिए उम्मीद की थी।

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

SELECT
    DB.name,
    MF.physical_name,
    MF.type_desc AS FileType,
    MF.size * 8 / 1024 AS FileSizeMB,
    fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB,
    mf.name LogicalName
FROM
    sys.master_files MF
    JOIN sys.databases DB ON DB.database_id = MF.database_id
WHERE   DB.name = 'yourdatabasename'

यह पुष्टि करता है कि सामान्य परिस्थितियों में हम बहुत कम लॉग स्पेस (20MB या उससे कम) का उपयोग कर रहे थे, लेकिन यह दूसरी वस्तु में ले जाता है ...

दूसरा, लॉग्स बढ़ने की मेरी धारणा धीरे-धीरे समय के साथ बढ़ती गई। हालांकि, वास्तव में रातों में लॉग तेजी से बढ़ रहे थे, इस 3 पार्टी एप्लिकेशन के लिए पैच लगाने के लिए जिम्मेदार व्यक्ति पैच लागू कर रहा था। पैच को एकल लेनदेन के रूप में किया गया था, इसलिए पैच के आधार पर 200MB डेटा को 300MB लॉग की आवश्यकता थी। ट्रैकिंग में महत्वपूर्ण यह है कि नीचे हारून बर्ट्रेंड से https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace पर क्वेरी थी

DECLARE @path NVARCHAR(260);

SELECT 
    @path = REVERSE(SUBSTRING(REVERSE([path]), 
    CHARINDEX('\', REVERSE([path])), 260)) + N'log.trc'
FROM    sys.traces
WHERE   is_default = 1;

SELECT 
   DatabaseName,
   [FileName],
    SPID,
    Duration,
    StartTime,
    EndTime,
    FileType = CASE EventClass 
       WHEN 92 THEN 'Data'
       WHEN 93 THEN 'Log'
    END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE
    EventClass IN (92,93)
ORDER BY
    StartTime DESC;

इससे पता चला कि लॉग कुछ शाम को बढ़ रहा था, जब ग्राहक डेटाबेस का उपयोग नहीं कर रहा था। जिसके कारण पैच लगाने वाले व्यक्ति से बातचीत हुई और रहस्य का जवाब मिला।

उन लोगों के लिए फिर से धन्यवाद जिन्होंने मुझे उत्तर देने के लिए सहायता प्रदान की।

Comments

दरअसल, मैंने अपने ग्राहकों की साइटों के डेटाबेस में एक समान घटना को SIMPLE रिकवरी मॉडल के साथ देखा है। लॉग (अभी तक, वैसे भी) हो जाना नहीं है, लेकिन लॉग फ़ाइलों में उपयोग किए गए अंतरिक्ष करता है हर रात एक छोटा सा से बढ़ता है। और ऐसा तब होता है जब डेटाबेस बैकअप चलता है। मुझे अभी तक यह पता नहीं चला है कि यह क्या कारण है और न ही इसकी समस्या है या नहीं।

— RBarryYoung

Answer 1

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

वैसे भी, आपको क्यों लगता है कि 300 एमबी तक पहुँचने के बाद आपको लॉग फ़ाइल को सिकोड़ना होगा? क्या आपने वास्तव में माइक के सवाल पर सभी उत्तरों को अच्छी तरह से पढ़ा था ? लॉग फ़ाइल अपने आप सिकुड़ने वाली नहीं है, क्योंकि लॉग फ़ाइल को 1MB तक सिकोड़ना - बस इसलिए यह आपके सबसे बड़े लेनदेन के दौरान फिर से बढ़ सकता है - समय की कुल बर्बादी है। आप इस बीच में उस खाली जगह के साथ क्या करने जा रहे हैं?

Comments

मुझे नहीं लगता कि हम ऐसा कुछ भी कर रहे हैं जिसके लिए 300MB लॉग की आवश्यकता होगी, लेकिन अगर हमने ऐसा किया, तो एक बार ऐसा करने के बाद, क्या यह डेटाबेस पर मुक्त स्थान के रूप में दिखाई नहीं देगा? जब SQL सर्वर प्रबंधन स्टूडियो में डेटाबेस पर गुणों को देखते हैं, तो आकार डेटा और लॉग का आकार होता है, और मुझे डेटा और लॉग पर मुक्त स्थान होने की उम्मीद होगी। क्या लॉग में खाली स्थान दिखाई नहीं देता है? यह दिखावा नहीं था क्योंकि यह ऐसा लगता था जैसे यह अभी भी उपयोग में है, लेकिन डेटाबेस पर कोई गतिविधि नहीं थी।

— डेरेककेट

नहीं, एक बार जब यह किया जाता है, तो यह स्वचालित रूप से मुक्त स्थान नहीं बन जाता है। प्रतिबद्ध लेनदेन शून्य नहीं हैं, उनका स्थान केवल पुन: उपयोग के लिए उपलब्ध है।

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

@DerekCate "मुझे नहीं लगता कि हम ऐसा कुछ भी कर रहे हैं जिसके लिए 300MB लॉग की आवश्यकता होगी" ... आपको आश्चर्य होगा, यह लेन-देन लॉग के पुन: उपयोग के लिए बाध्य करने के लिए ज्यादा नहीं है। इसे वर्कलोड की मात्रा के संदर्भ में मत समझिए, क्योंकि यह हमेशा कारण नहीं होता है।

— थॉमस स्ट्रिंगर

ठीक है, इसलिए यह पुष्टि करने के लिए कि मैं इसे सही ढंग से समझ रहा हूं, 300MB लॉग, भले ही वर्तमान में आवश्यक नहीं है, मुफ्त स्थान के रूप में नहीं दिखाएगा, लेकिन पुन: उपयोग किया जाएगा। और कुछ बिंदु पर, कुछ लेनदेन को संभालने के लिए इसे 300 एमबी की आवश्यकता थी। ठीक है, नई चीजों को देखने के लिए। धन्यवाद!

— डेरेककेट

विचार करने के लिए एक और बात: एक सरल रिकवरी डेटाबेस के लिए एक स्वचालित चेकपॉइंट केवल कतार में होता है जब लॉग पहले से ही 70% भरा हो। इसलिए, आपको समय पर निर्भर करते हुए वृद्धि में परिणाम के लिए सभी लॉग गतिविधि की आवश्यकता नहीं हो सकती है।

— पॉल व्हाइट GoFundMonica कहते

Answer 2

आपके सभी वर्तमान परीक्षण ( DBCC SHRINKFILE, log_reuse_wait_desc) केवल यह साबित कर रहे हैं कि अभी आप लेन-देन लॉग की वर्चुअल लॉग फ़ाइलों का उचित उपयोग कर रहे हैं। लेकिन जब आपकी ऑटो वृद्धि की घटनाएं आपके लेन-देन लॉग फ़ाइल पर होती हैं तो यह लॉग की प्रतिक्रिया होती है जो पुन: उपयोग नहीं की जा सकती है।

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

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

यह कहता है कि लॉग स्पेस का पुन: उपयोग किया जाना चाहिए, लेकिन महीनों के दौरान इस धीमी वृद्धि के साथ, ऐसा नहीं लगता है कि यह है।

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

Comments

यदि वह 50MB मुक्त देख रहा है और 300MB लॉग fn_DBLOG () उसे कुछ जानकारी देगा तो उसके लॉग का आकार बढ़ा रहा है?

— केनेथ फिशर

Answer 3

क्या आपके पास DB पर ऑटो-सिक्योर सक्षम है? और / या क्या आपके पास अनुरक्षण की योजना अनुक्रमणिका का प्रदर्शन कर रही है?

इंडेक्स मेंटेनेंस के बाद एक ऑटो-सिकुड़न महत्वपूर्ण लॉग वॉल्यूम पैदा करेगा।

यदि GUID पर अनुक्रमित अनुक्रमित जैसे DB डिज़ाइन समस्याएँ हैं, तो अनुक्रमणिका अनुरक्षण स्वयं भी महत्वपूर्ण लॉग वॉल्यूम उत्पाद करेगा।

Comments

DB पर ऑटो हटना सक्षम नहीं है, हम सूचकांक विखंडन brentozar.com/archive/2009/08/ से बचने के लिए देख रहे हैं । हमारे पास साप्ताहिक अखंडता की जांच है, लेकिन मुझे नहीं लगता कि उस हिस्से के रूप में कोई भी सूचकांक पुनर्निर्माण है, मुझे उस पर गौर करना होगा। इसके अलावा, कोई GUID नहीं, प्रत्येक तालिका में एक पहचान स्तंभ होता है जो प्राथमिक कुंजी है।

— डेरेककेट

Answer 4

 create table #dblog (Databasename varchar(100),
                     logsize float,
                     logspace%] float,
                     [Status] int)

 insert into #dblog
 EXEC ('DBCC sqlperf(logspace)') 

 select * from #dblog

 alter table #dblog 
 add [lgspace used GB] float;

 update #dblog 
 set [lgspace used GB ] = (logsize*[logspace%]/1024)

 update #dblog 
 set [logsize] =([logsize]/1024)

 alter table #dblog 
 drop column [Status];

 select * from #dblog

 drop table #dblog