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

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

У меня нет контроля над тем, как это выполняется.

Поскольку транзакция остается открытой в течение всего времени, когда журнал транзакций заполняется, SQL Server не может увеличить размер файла журнала.

Таким образом, процесс выходит из строя с ошибкой "The transaction log for database 'xxx' is full".

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

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

Любые идеи?

Если кому-то интересно, процесс представляет собой импорт организации в Microsoft Dynamics CRM 4.0.

Существует много места на диске, у нас есть журнал в режиме простого ведения журнала и резервное копирование журнала до начала процесса.

- = - = - = - = - UPDATE - = - = - = - = -

Спасибо всем за комментарии. Следующее - это привело меня к мысли, что журнал не будет расти из-за открытой транзакции:

Я получаю следующую ошибку...

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 ГБ. Это займет пару часов.

- = - = - = - Final UPDATE - = - = - = -

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

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

Спасибо всем за ваш вклад.

Ответ 1

Это одно время script или регулярно выполняющееся задание?

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

Ответ 2

Чтобы устранить эту проблему, измените Модель восстановления на Простой, затем Журнал сжимающихся файлов

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

2. Задачи базы данных > Усадкa > Файлы > Журнал

Готово.

Затем проверьте размер файла журнала db на Свойства базы данных > Файлы > Файлы базы данных > Путь

Чтобы проверить полный журнал сервера sql: откройте средство просмотра файлов журнала в SSMS > База данных > Управление > Журналы SQL Server > Текущие

Ответ 3

У меня была эта ошибка один раз, и в итоге это был жесткий диск сервера, на котором не было свободного места на диске.

Ответ 4

У вас есть Включить авторазмах и Неограниченный рост файлов, которые включены для файла журнала? Вы можете редактировать их через SSMS в разделе "Свойства базы данных > Файлы"

Ответ 5

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

Ответ 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

Ответ 7

Если ваша модель восстановления базы данных заполнена и у вас не было плана обслуживания резервного копирования журнала, вы получите эту ошибку, потому что журнал транзакций будет заполнен из-за LOG_BACKUP.

Это предотвратит любые действия в этой базе данных (например, сжимается), а SQL Server Database Engine вызовет ошибку 9002.

Чтобы преодолеть это поведение, я советую вам проверить это Журнал транзакций для базы данных" SharePoint_Config заполнен из-за LOG_BACKUP, в котором показаны подробные шаги для решения проблема.

Ответ 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())

Ответ 9

Моя проблема решена с множественным выполнением ограниченного удаления, как

До

DELETE FROM TableName WHERE Condition

После

DELETE TOP(1000) FROM TableName WHERECondition

Ответ 10

Ответом на вопрос является не удаление строк из таблицы, а использование пространства tempDB из-за активной транзакции. это происходит в основном, когда выполняется слияние (upsert), когда мы пытаемся вставить обновление и удалить транзакции. Единственный вариант - убедиться, что для БД установлена простая модель восстановления, а также увеличить размер файла до максимального (Добавить другую группу файлов). Хотя это имеет свои преимущества и недостатки, это единственные варианты.

Другой вариант - разделить слияние (upsert) на две операции. один, который выполняет вставку, а другой - обновление и удаление.

Ответ 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

Я надеюсь, что это помогает.