डेटाबेस के लिए लेन-देन लॉग भरा हुआ है

Question

मेरे पास एक लंबी चलने वाली प्रक्रिया है जो पूर्ण अवधि के लिए एक लेनदेन खोलती है।

इसे निष्पादित करने के तरीके पर मेरा कोई नियंत्रण नहीं है।

क्योंकि लेन-देन पूर्ण अवधि के लिए खुला रखा जाता है, जब लेन-देन लॉग भरता है, तो SQL सर्वर लॉग फ़ाइल का आकार नहीं बढ़ा सकता है।

तो त्रुटि के साथ प्रक्रिया विफल हो जाती है "The transaction log for database 'xxx' is full"।

मैंने डेटाबेस गुणों में लेन-देन लॉग फ़ाइल का आकार बढ़ाकर इसे रोकने का प्रयास किया है, लेकिन मुझे वही त्रुटि मिलती है।

निश्चित नहीं कि मुझे आगे क्या प्रयास करना चाहिए। प्रक्रिया कई घंटों तक चलती है इसलिए परीक्षण और त्रुटि खेलना आसान नहीं है।

कोई विचार?

अगर किसी को दिलचस्पी है, तो प्रक्रिया एक संगठन आयात है Microsoft Dynamics CRM 4.0.

डिस्क स्थान बहुत है, हमारे पास लॉग इन सिंपल लॉगिंग मोड है और प्रक्रिया को किक करने से पहले लॉग का बैकअप लिया है।

- = - = - = - = - अद्यतन - = - = - = - = -

अब तक की टिप्पणियों के लिए सभी का धन्यवाद। निम्नलिखित है जो मुझे विश्वास दिलाता है कि खुले लेनदेन के कारण लॉग नहीं बढ़ेगा:

मुझे निम्नलिखित त्रुटि प्राप्त हो रही है...

Import Organization (Name=xxx, Id=560d04e7-98ed-e211-9759-0050569d6d39) failed with Exception:
System.Data.SqlClient.SqlException: The transaction log for database 'xxx' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

तो उस सलाह का पालन करते हुए मैं " log_reuse_wait_desc column in sys.databases" गया और इसने " ACTIVE_TRANSACTION" मान रखा ।

Microsoft के अनुसार: http://msdn.microsoft.com/en-us/library/ms345414(v=sql.105).aspx

इसका मतलब है कि निम्नलिखित:

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

• एक लेन-देन स्थगित है (SQL Server 2005 एंटरप्राइज़ संस्करण और बाद के संस्करण केवल)। आस्थगित लेनदेन प्रभावी रूप से एक सक्रिय लेनदेन है जिसका रोलबैक कुछ अनुपलब्ध संसाधन के कारण अवरुद्ध है। आस्थगित लेनदेन के कारणों के बारे में जानकारी के लिए और उन्हें स्थगित राज्य से बाहर कैसे स्थानांतरित किया जाए, आस्थगित लेनदेन देखें।

क्या मैंने कुछ गलत समझा है?

- = - = - = - अद्यतन 2 - = - = - = -

बस प्रारंभिक लॉग फ़ाइल आकार को 30GB करने के लिए सेट के साथ प्रक्रिया को किक किया। इसे पूरा करने में कुछ घंटे लगेंगे।

- = - = - = - अंतिम अद्यतन - = - = - = -

समस्या वास्तव में लॉग फ़ाइल के कारण सभी उपलब्ध डिस्क स्थान की खपत के कारण थी। आखिरी प्रयास में मैंने 120GB तक फ्रीज कर लिया और इसने अभी भी इसका इस्तेमाल किया और आखिरकार असफल रहा।

मुझे यह महसूस नहीं हुआ कि यह पहले हो रहा था क्योंकि जब प्रक्रिया रात भर चल रही थी, तो यह विफलता पर वापस चल रही थी। इस बार मैं रोलबैक से पहले लॉग फ़ाइल का आकार जांचने में सक्षम था।

आपके निवेश - सहयोग के लिए धन्यवाद।

Comments

पुनः "... और लॉग का बैकअप ले लिया है" .... यदि डेटाबेस सरल मोड में है, तो आप लॉग बैकअप नहीं कर पाएंगे, लॉग बैकअप सरल मोड के लिए लागू नहीं हैं। क्या यह थोक-लॉग है?

— स्क्लैकिड

मैंने पूरे डीबी का समर्थन किया और इसे सिकोड़ दिया जिसके परिणामस्वरूप लॉग 1MB तक सिकुड़ गया। मैंने शुरुआत में लॉग फ़ाइल का आकार बढ़ाकर 20GB और अब 30 GB कर दिया है।

— जिम्बो

संबंधित पोस्ट - TempDB लॉग स्पेस और ACTIVE_TRANSACTION

— RBT

Answer 1

क्या यह एक बार की स्क्रिप्ट है, या नियमित रूप से होने वाली नौकरी है?

अतीत में, विशेष परियोजनाओं के लिए जो अस्थायी रूप से लॉग फ़ाइल के लिए बहुत सारे स्थान की आवश्यकता होती है, मैंने एक दूसरी लॉग फ़ाइल बनाई और इसे विशाल बना दिया। एक बार प्रोजेक्ट पूरा होने के बाद हमने अतिरिक्त लॉग फ़ाइल को हटा दिया।

Comments

मैं यह नहीं कहूंगा कि यह एक बार का काम है, लेकिन यह दुर्लभ है कि हमें यह करना होगा। मैंने दूसरी लॉग फ़ाइल नहीं बनाई, लेकिन मैंने अपनी वर्तमान लॉग फ़ाइल के प्रारंभिक आकार को बढ़ाकर 30GB कर दिया। मेरे आखिरी रन के दौरान इसे 20GB पर सेट किया गया था और यह अभी भी विफल रहा है।

— जिम्बो

क्या दूसरी लॉग फ़ाइल होने से बेहतर होगा कि किसी एक को दिए जाने से बेहतर है कि मेरे पास काम करने के लिए केवल एक ड्राइव है?

— जिम्बो

जैसा कि मैंने अभी याद किया, अतिरिक्त फ़ाइल ने हमें एक और बड़ी ड्राइव का उपयोग करने में सक्षम बनाया।

— माइक हेंडरसन

डेटा कितना बड़ा आयात किया जा रहा है? यदि आप 30 जीबी डेटा आयात कर रहे हैं, तो आप लॉग फ़ाइल को कम से कम उतना बड़ा होना चाहिए।

— माइक हेंडरसन

लॉग आकार कुंजी है। वर्तमान कार्य फिर से विफल हो गया और मैं अपनी आँखों पर विश्वास नहीं कर सका जब मैंने उस बिंदु पर लॉग फ़ाइल का आकार देखा, जो विफल रही। इसने केवल आधे खातों को संसाधित किया और पहले से ही 53GB पर था। ऐसा लगता है कि मुझे इस प्रक्रिया को पूरा करने में सक्षम होने के लिए 60-70GB के आसपास के क्षेत्र में कहीं और साफ़ करना होगा।

— जिम्बो

Answer 2

इस समस्या को ठीक करने के लिए, पुनर्प्राप्ति मॉडल को सरल और फिर सिकोड़ें फ़ाइल लॉग में बदलें

1. डेटाबेस गुण> विकल्प> रिकवरी मॉडल> ​​सरल

2। डेटाबेस कार्य> हटना> फ़ाइलें> लॉग

किया हुआ।

इसके बाद अपने db लॉग फाइल साइज की जाँच करें डेटाबेस गुणों> फ़ाइलें> डेटाबेस फ़ाइलों> पथ

पूर्ण SQL सर्वर लॉग की जाँच करने के लिए: SSMS> डेटाबेस> प्रबंधन> SQL सर्वर लॉग> करंट में लॉग फाइल व्यूअर खोलें

Comments

नहीं, यह समस्या को ठीक नहीं करता है। समस्या यह थी कि लॉग फ़ाइल लंबे समय तक चलने की प्रक्रिया के दौरान बढ़ी जब तक कि यह डिस्क स्थान से बाहर नहीं निकल गई। यह लॉग फ़ाइल को अस्थायी रूप से किसी अन्य ड्राइव पर ले जाने के द्वारा सही किया गया था जिसमें 1TB स्थान उपलब्ध था। लंबे समय से चल रही प्रक्रिया के दौरान आप लॉग फ़ाइल को सिकोड़ नहीं सकते हैं - जो एक लेन-देन को खोल रहा है - प्रगति पर है। यह प्रक्रिया फ़ाइल विकास के लिए पूरी तरह से जिम्मेदार थी।

— जिम्बो

जैसा कि @ जिंबो ने पहले ही कहा, यह ओपी की समस्या को ठीक नहीं करता है। यह कुछ वर्तमान में अप्रयुक्त स्थान को मुक्त कर सकता है, लेकिन जैसे ही एक लंबा लेनदेन फिर से चल रहा है, अंतरिक्ष को फिर से लिया जाएगा (और शायद पहले भी विफल)

— मार्सेल

उत्तम! धन्यवाद!

— यूरी मोंटेइरो

यह समस्या ठीक नहीं हुई। मेरे लॉग में केवल 500 बाइट्स हैं। मुझे लगता है कि मैंने कल एक बैकअप करने के बाद इस समस्या को शुरू किया।

— रिकार्डो फ्रांसा

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

— स्टीव बॉमन

Answer 3

मुझे एक बार यह त्रुटि हुई थी और यह सर्वर की हार्ड ड्राइव से समाप्त हो गया था जो डिस्क स्थान से बाहर चला गया था।

Comments

ओपी के अपडेट पढ़ें। यह मुद्दा बन गया।

— Colm

Answer 4

क्या आपके पास लॉग फ़ाइल के लिए सक्षम ऑटोग्रॉथ और अप्रतिबंधित फ़ाइल विकास है ? आप "डेटाबेस गुण> फ़ाइलें" में SSMS के माध्यम से इन्हें संपादित कर सकते हैं

Comments

हाँ। यह अप्रतिबंधित 10% ऑटोग्रॉ करने के लिए सेट है। मुद्दा यह है कि एक खुला लेनदेन होने पर ऑटोग्रो काम नहीं करेगा।

— जिमबो

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

— लुइस एलएल

SQL सर्वर किसी हस्तांतरण के दौरान लॉग को ऑटोग्रॉफ़ करेगा यदि उसे उस लेनदेन को पूरा करने के लिए अधिक स्थान की आवश्यकता है।

— रॉस मैकनाब

हाय रॉस, मैंने अपना तर्क दिया है कि खुले लेन-देन के बारे में सोचने से सवाल के अपडेट में वृद्धि को रोका जा सकता है। क्या मैं अपने तर्क में गलत हूँ?

— जिम्बो

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

— लुइस एलएल

Answer 5

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

Comments

दुर्भाग्य से जिस तरह से प्रक्रिया की जाती है, उस पर मेरा कोई नियंत्रण नहीं है। Dynamics CRM एक Microsoft अनुप्रयोग है और संगठन आयात प्रक्रिया उस अनुप्रयोग का हिस्सा है।

— जिम्बो

Answer 6

निम्नलिखित लॉग को छोटा कर देगा।

USE [yourdbname] 
GO

-- TRUNCATE TRANSACTION LOG --
DBCC SHRINKFILE(yourdbname_log, 1)
BACKUP LOG yourdbname WITH TRUNCATE_ONLY
DBCC SHRINKFILE(yourdbname_log, 1)
GO

-- CHECK DATABASE HEALTH --
ALTER FUNCTION [dbo].[checker]() RETURNS int AS BEGIN  RETURN 0 END
GO

Comments

हे मीनल, यह कार्यक्षमता SQL Server 2008 और इसके बाद के संस्करण से पूरी तरह से हटा दी गई थी: brentozar.com/archive/2009/08/…

— Conor

बाद के संस्करणों के साथ, BACKUP LOG <myDB> TO DISK = N'NUL: '

— हंसलिन्ग्रेंगन

Answer 7

यदि आपका डेटाबेस रिकवरी मॉडल भरा हुआ है और आपके पास लॉग बैकअप रखरखाव योजना नहीं है, तो आपको यह त्रुटि मिलेगी क्योंकि लेन-देन लॉग पूर्ण हो जाता है LOG_BACKUP।

यह इस डेटाबेस (जैसे हटना) पर किसी भी कार्रवाई को रोक देगा, और SQL सर्वर डेटाबेस इंजन 9002 त्रुटि बढ़ाएगा।

इस व्यवहार को दूर करने के लिए मैं आपको यह जांचने की सलाह देता हूं कि डेटाबेस 'SharePoint_Config' के लिए लेनदेन लॉग LOG_BACKUP के कारण भरा हुआ है, जो समस्या को हल करने के लिए विस्तृत कदम दिखाता है।

Answer 8

मुझे त्रुटि मिली: "डिस्क के लिए लेन-देन लॉग '...' डिस्क स्थान खाली करने के लिए मेरे डेटाबेस की तालिकाओं से पुरानी पंक्तियों को हटाने के दौरान 'ACTIVE_TRANSACTION' के कारण भरा हुआ है। मुझे एहसास हुआ कि पंक्तियों की संख्या होने पर यह त्रुटि होगी। डिलीट किया जाना मेरे मामले में 1000000 से बड़ा था। इसलिए 1 DELETE स्टेटमेंट का उपयोग करने के बजाय, मैंने डिलीट टास्क को DELETE TOP (1000000) .... स्टेटमेंट का उपयोग करके विभाजित किया।

उदाहरण के लिए:

इस कथन का उपयोग करने के बजाय:

DELETE FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())

निम्नलिखित कथन का बार-बार उपयोग करना:

DELETE TOP(1000000) FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())

Answer 9

मेरी समस्या के साथ हल कई सीमित हटाता का अमल की तरह

इससे पहले

DELETE FROM TableName WHERE Condition

उपरांत

DELETE TOP(1000) FROM TableName WHERECondition

Answer 10

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

आपके पास जो दूसरा विकल्प है, वह है मर्ज (अपग्रेड) को दो ऑपरेशन में विभाजित करना। एक जो इन्सर्ट करता है और दूसरा जो अपडेट और डिलीट करता है।

Comments

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

— जिमबो

Answer 11

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

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

मुझे उम्मीद है यह मदद करेगा।

Comments

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

— जिम्बो

Answer 12

यहाँ मेरा हीरो कोड है। मैंने इस समस्या का सामना किया है। और इसे ठीक करने के लिए इस कोड का उपयोग करें।

 USE master;

    SELECT 
        name, log_reuse_wait, log_reuse_wait_desc, is_cdc_enabled 
    FROM 
        sys.databases 
    WHERE 
        name = 'XX_System';

    SELECT DATABASEPROPERTYEX('XX_System', 'IsPublished');


    USE XX_System;
    EXEC sp_repldone null, null, 0,0,1;
    EXEC sp_removedbreplication XX_System;


    DBCC OPENTRAN;
    DBCC SQLPERF(LOGSPACE);
    EXEC sp_replcounters;



    DBCC SQLPERF(LOGSPACE);

Comments

कृपया अपना उत्तर हमेशा केवल कोड चिपकाने के बजाय संदर्भ में रखें। अधिक जानकारी के लिए यहां देखें ।

— गेहबीस्सुमिस

Answer 13

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

यदि संभव हो तो सेवाओं को पुनरारंभ करें MSSQLSERVER और SQLSERVERAGENT ।