Журнал транзакцій для бази даних заповнений

У мене тривалий процес, який відкриває транзакцію на повну тривалість.

Я не маю контролю над тим, як це виконується.

Оскільки транзакція залишається відкритою протягом усієї тривалості, коли журнал транзакцій заповнюється, SQL Server не може збільшити розмір файлу журналу.

Тож процес виходить з ладу з помилкою "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 Enterprise Edition та новіших версій). Відкладена транзакція - це фактично активна транзакція, відкат якої блокується через деякий недоступний ресурс. Інформацію про причини відкладених транзакцій та про те, як вивести їх із відкладеного стану див. У розділі Відкладені транзакції.

Я щось неправильно зрозумів?

- = - = - = - ОНОВЛЕННЯ 2 - = - = - = -

Просто розпочали процес із початковим розміром файлу журналу, встановленим на 30 Гб. На це піде кілька годин.

- = - = - = - Остаточне ОНОВЛЕННЯ - = - = - = -

Проблема була насправді викликана тим, що файл журналу поглинав увесь доступний дисковий простір. В останній спробі я випустив 120 Гб, і він все-таки використав усе, і в кінцевому рахунку зазнав невдачі.

Я не усвідомлював, що це відбувається раніше, тому що, коли процес працював протягом ночі, він відкидався на провал. Цього разу мені вдалося перевірити розмір файлу журналу перед відкатом.

Дякую всім за ваш внесок.

Це одноразовий сценарій чи робота, що регулярно відбувається?

Раніше для спеціальних проектів, які тимчасово вимагають багато місця для файлу журналу, я створив другий файл журналу і зробив його величезним. Після завершення проекту ми видалили додатковий файл журналу.

Щоб виправити цю проблему, змініть модель відновлення на просту, а потім зменшити журнал файлів

1. Властивості бази даних> Параметри> Модель відновлення> Просте

2. Завдання бази даних> Зменшити> Файли> Журнал

Зроблено.

Потім перевірте розмір файлу журналу db у розділі Властивості бази даних> Файли> Файли баз даних> Шлях

Щоб перевірити повний журнал сервера sql: відкрийте програму перегляду файлів журналу в SSMS> База даних> Управління> Журнали SQL Server> Поточні

У мене була помилка один раз, і в кінцевому підсумку це був жорсткий диск сервера, у якого не вистачає місця на диску.

Чи увімкнено функцію автоматичного зростання та необмежене зростання файлів для файлу журналу? Ви можете редагувати їх через SSMS у розділі "Властивості бази даних> Файли"

Це підхід до старої школи, але якщо ви виконуєте ітераційне оновлення або вставку операцій у SQL, що працює тривалий час, корисно періодично (програмно) викликати "контрольну точку". Виклик "контрольної точки" призводить до того, що SQL записує на диск всі ті зміни, що стосуються лише пам'яті (брудні сторінки, вони називаються) та елементи, що зберігаються в журналі транзакцій. Це призводить до періодичного очищення журналу транзакцій, запобігаючи таким чином проблеми, як описана.

Далі буде усічено журнал.

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

Якщо модель відновлення вашої бази даних повна і у вас не було плану обслуговування резервного копіювання журналу, ви отримаєте цю помилку, оскільки журнал транзакцій стає повним через LOG_BACKUP.

Це запобіжить будь-які дії з цією базою даних (наприклад, зменшення), і двигун бази даних SQL Server призведе до помилки 9002.

Щоб подолати таку поведінку, радимо перевірити цей журнал транзакцій для бази даних "SharePoint_Config" заповнений завдяки LOG_BACKUP, який показує детальні кроки для вирішення проблеми.

Я зіткнувся з помилкою: "Журнал транзакцій для бази даних" ... "заповнений завдяки" 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())

Мою проблему вирішили з кількома виконанням обмежених видалень, як-от

До цього

DELETE FROM TableName WHERE Condition

Після

DELETE TOP(1000) FROM TableName WHERECondition

Відповідь на питання - це не видалення рядків з таблиці, але саме простір tempDB займає активна транзакція. це відбувається в основному, коли відбувається злиття (upsert), де ми намагаємося вставити оновлення та видалити транзакції. Єдиний варіант полягає в тому, щоб переконатися, що БД встановлено на просту модель відновлення, а також збільшити файл до максимального простору (Додати іншу групу файлів). Хоча це має свої переваги і недоліки, це єдині варіанти.

Інший варіант, який у вас є, - це розділити злиття (upsert) на дві операції. той, що робить вставку, і інший, який робить оновлення та видалення.

Спробуйте це:

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 

Я сподіваюся, що це допомагає.

Ось мій код героя. Я зіткнувся з цією проблемою. І використовуйте цей код, щоб виправити це.

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

Спробуйте це:

Якщо можливо, перезапустіть служби MSSQLSERVER і SQLSERVERAGENT .