Dziennik transakcji bazy danych jest pełny

Mam długotrwały proces, który wstrzymuje otwartą transakcję przez cały czas.

Nie mam kontroli nad sposobem, w jaki to jest wykonywane.

Ponieważ transakcja jest otwarta przez cały czas, po wypełnieniu dziennika transakcji SQL Server nie może zwiększyć rozmiaru pliku dziennika.

Więc proces kończy się niepowodzeniem z powodu błędu "The transaction log for database 'xxx' is full".

Próbowałem temu zapobiec, zwiększając rozmiar pliku dziennika transakcji we właściwościach bazy danych, ale pojawia się ten sam błąd.

Nie jestem pewien, czego powinienem spróbować dalej. Proces trwa kilka godzin, więc nie jest łatwo grać metodą prób i błędów.

Jakieś pomysły?

Jeśli ktoś jest zainteresowany, procesem jest import organizacji Microsoft Dynamics CRM 4.0.

Jest dużo miejsca na dysku, logujemy się w prostym trybie logowania i utworzyliśmy kopię zapasową dziennika przed rozpoczęciem procesu.

- = - = - = - = - AKTUALIZACJA - = - = - = - = -

Dziękuję wszystkim za dotychczasowe komentarze. Oto, co skłoniło mnie do przekonania, że ​​dziennik nie wzrośnie z powodu otwartej transakcji:

Otrzymuję następujący błąd ...

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

Więc postępując zgodnie z tą radą poszedłem do „ log_reuse_wait_desc column in sys.databases” i to miało wartość „ ACTIVE_TRANSACTION”.

Według Microsoft: http://msdn.microsoft.com/en-us/library/ms345414(v=sql.105).aspx

To oznacza co następuje:

Transakcja jest aktywna (wszystkie modele odzyskiwania). • Na początku tworzenia kopii zapasowej dziennika może istnieć długoterminowa transakcja. W takim przypadku zwolnienie miejsca może wymagać kolejnej kopii zapasowej dziennika. Aby uzyskać więcej informacji, zobacz „Długoterminowe aktywne transakcje” w dalszej części tego tematu.

• Transakcja jest odroczona (tylko SQL Server 2005 Enterprise Edition i nowsze wersje). Transakcja odroczona jest faktycznie transakcją aktywną, której wycofanie jest zablokowane z powodu niedostępnego zasobu. Aby uzyskać informacje o przyczynach odroczonych transakcji i sposobach ich przenoszenia ze stanu odroczonego, zobacz Transakcje odroczone.

Czy coś źle zrozumiałem?

- = - = - = - AKTUALIZACJA 2 - = - = - = -

Właśnie rozpoczęto proces, ustawiając początkowy rozmiar pliku dziennika na 30 GB. To zajmie kilka godzin.

- = - = - = - Ostateczna AKTUALIZACJA - = - = - = -

Problem był faktycznie spowodowany tym, że plik dziennika zajmował całe dostępne miejsce na dysku. W ostatniej próbie zwolniłem 120 GB i nadal je wykorzystywałem i ostatecznie się nie udało.

Nie zdawałem sobie sprawy, że dzieje się to wcześniej, ponieważ gdy proces był wykonywany w nocy, wycofywał się po niepowodzeniu. Tym razem udało mi się sprawdzić rozmiar pliku dziennika przed wycofaniem.

Dziękuję wszystkim za wkład.

Czy to jednorazowy skrypt, czy regularnie występująca praca?

W przeszłości do specjalnych projektów, które tymczasowo wymagały dużej ilości miejsca na plik dziennika, utworzyłem drugi plik dziennika i uczyniłem go ogromnym. Po zakończeniu projektu usunęliśmy dodatkowy plik dziennika.

Aby rozwiązać ten problem, zmień Model odzyskiwania na Prosty, a następnie zmniejsz dziennik plików

1. Właściwości bazy danych> Opcje> Model odzyskiwania> Proste

2. Zadania bazy danych> Zmniejsz> Pliki> Dziennik

Gotowe.

Następnie sprawdź rozmiar pliku dziennika db w Właściwości bazy danych> Pliki> Pliki bazy danych> Ścieżka

Aby sprawdzić pełny dziennik serwera sql: otwórz przeglądarkę plików dziennika w SSMS> Baza danych> Zarządzanie> Dzienniki SQL Server> Bieżące

Kiedyś miałem ten błąd i okazało się, że na dysku twardym serwera zabrakło miejsca.

Czy dla pliku dziennika włączono opcję Włącz automatyczne i nieograniczony wzrost plików? Możesz je edytować przez SSMS w „Właściwości bazy danych> Pliki”

Jest to podejście starej szkoły, ale jeśli wykonujesz iteracyjną aktualizację lub operację wstawiania w SQL, coś, co działa przez długi czas, dobrym pomysłem jest okresowe (programowe) wywoływanie „punktu kontrolnego”. Wywołanie „punktu kontrolnego” powoduje, że SQL zapisuje na dysku wszystkie te zmiany tylko w pamięci (nazywane są brudnymi stronami) i elementy przechowywane w dzienniku transakcji. Powoduje to okresowe czyszczenie dziennika transakcji, zapobiegając w ten sposób problemom takim jak ten opisany.

Poniższe czynności spowodują obcięcie dziennika.

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

Jeśli model odzyskiwania bazy danych jest pełny i nie masz planu konserwacji kopii zapasowej dziennika, zostanie wyświetlony ten błąd, ponieważ dziennik transakcji zostanie zapełniony z powodu LOG_BACKUP.

Zapobiegnie to wszelkim działaniom na tej bazie danych (np. Zmniejszeniu), a aparat bazy danych programu SQL Server zgłosi błąd 9002.

Aby przezwyciężyć to zachowanie, radzę sprawdzić to. Dziennik transakcji dla bazy danych „SharePoint_Config” jest pełny ze względu na LOG_BACKUP, który zawiera szczegółowe instrukcje rozwiązania problemu.

Napotkałem błąd: „Dziennik transakcji bazy danych '...' jest pełny z powodu 'ACTIVE_TRANSACTION' podczas usuwania starych wierszy z tabel mojej bazy danych w celu zwolnienia miejsca na dysku. Zrozumiałem, że ten błąd wystąpiłby, gdyby liczba wierszy była w moim przypadku wartość do usunięcia była większa niż 1000000. Zamiast używać 1 instrukcji DELETE, podzieliłem zadanie usuwania za pomocą instrukcji DELETE TOP (1000000) ....

Na przykład:

zamiast używać tego stwierdzenia:

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

używając wielokrotnie następującego oświadczenia:

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

Mój problem został rozwiązany dzięki wielokrotnemu wykonywaniu ograniczonych operacji usuwania, takich jak

Przed

DELETE FROM TableName WHERE Condition

Po

DELETE TOP(1000) FROM TableName WHERECondition

Odpowiedzią na pytanie nie jest usuwanie wierszy z tabeli, ale miejsce zajmowane w tempDB z powodu aktywnej transakcji. zdarza się to głównie wtedy, gdy jest uruchamiane scalanie (upsert), w którym próbujemy wstawić aktualizację i usunąć transakcje. Jedyną opcją jest upewnienie się, że DB jest ustawiony na prosty model odzyskiwania, a także zwiększenie pliku do maksymalnej przestrzeni (Dodaj inną grupę plików). Chociaż ma to swoje zalety i wady, są to jedyne opcje.

Inną opcją, którą masz, jest podzielenie scalania (upsert) na dwie operacje. jeden, który wstawia, a drugi aktualizuje i usuwa.

Spróbuj tego:

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 

Mam nadzieję, że to pomoże.

Oto mój kod bohatera. Zmierzyłem się z tym problemem. I użyj tego kodu, aby to naprawić.

 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);

Spróbuj tego:

Jeśli to możliwe, uruchom ponownie usługi MSSQLSERVER i SQLSERVERAGENT .