Журнал транзакций для базы данных заполнен
у меня есть длительный процесс, который держит открытую транзакцию на полную продолжительность.
Я не имею никакого контроля над тем, как это выполняется.
поскольку транзакция остается открытой в течение всего времени, при заполнении журнала транзакций 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 ГБ. Это займет пару часов.
-=-=-=- окончательное обновление -= -= -= -
проблема была вызвана файлом журнала занять все доступное дисковое пространство. В последней попытке я освободил 120GB, И он все еще использовал все это и в конечном итоге потерпел неудачу.
Я не понимал, что это происходит раньше, потому что, когда процесс работал в одночасье, он откатывался на неудачу. На этот раз я смог проверить размер файла журнала перед откатом.
спасибо всем за Ваш вклад.
8 ответов:
это одноразовый скрипт или регулярно возникающая работа?
в прошлом, для специальных проектов, которые временно требуют много места для файла журнала, я создал второй файл журнала и сделал огромный. После завершения проекта мы удалили дополнительный файл журнала.
чтобы устранить эту проблему, измените Модель Восстановления до простой затем Shrink Files Log
1. Свойства Базы Данных > Параметры > Модель Восстановления > Простой
2. Задачи Базы Данных > Сжатие > Файлы > Журнал
сделано.
затем проверьте размер файла журнала БД на Свойства Базы Данных > Файлы > Файлы Базы Данных > Путь
чтобы проверить полный журнал sql server: откройте журнал Просмотра файлов в 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 Database Engine вызовет ошибку 9002.
чтобы преодолеть это поведение я советую вам изучить этот журнал транзакций для базы данных 'SharePoint_Config' заполнен из-за LOG_BACKUP что показывает подробные шаги для решения этой проблемы.
Я встретил ошибку: "журнал транзакций для базы данных '...'заполняется из-за' ACTIVE_TRANSACTION ' при удалении старых строк из таблиц моей базы данных для освобождения места на диске. Я понял, что эта ошибка произойдет, если количество строк, которые будут удалены, будет больше 1000000 в моем случае. Поэтому вместо использования инструкции 1 DELETE я разделил задачу delete с помощью DELETE TOP (1000000).... заявление.
например:
вместо этого заявление:
DELETE FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())многократно используя следующее утверждение:
DELETE TOP(1000000) FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())
Comments