Каждый системный администратор и специалист по СУБД рано или поздно сталкивается с парадоксальной ситуацией: пользователи 1С начинают жаловаться на критическую ошибку Журнал транзакций заполнен 80040E14, транзакции откатываются, работа встает. При этом вы заходите на сервер и видите, что на физическом диске, где расположены файлы базы данных, свободны сотни гигабайт или даже терабайты пространства. Особое удивление эта ситуация вызывает после миграции базы данных на новый мощный сервер, где дисковая подсистема была выделена с огромным запасом.
В этой статье мы подробно разберем причины возникновения этой проблемы на примере СУБД MS SQL Server, работающей в связке с тяжелой конфигурацией 1С:ERP Управление предприятием. Мы рассмотрим диагностические шаги, изучим механизмы работы журнала транзакций в разных моделях восстановления и научимся правильно настраивать параметры авторасширения файлов базы данных.
Первое, что необходимо понять при анализе этой ошибки: SQL Server оперирует не только свободным местом на физическом носителе, но и внутренними настройками лимитов каждого конкретного файла. Файловая структура базы данных MS SQL состоит как минимум из двух ключевых файлов:
.mdf (или .ndf), в котором хранятся сами таблицы, индексы и метаданные 1С..ldf, куда записываются все изменения до их физической фиксации в файле данных.При переносе базы данных со старого сервера на новый (например, через механизм создания резервной копии Backup/Restore или операцию отсоединения/присоединения Detach/Attach) SQL Server полностью копирует внутренние свойства конфигурации файлов. Если на старом сервере свободного места было мало, администраторы часто устанавливали жесткий лимит на максимальный размер файла лога. Этот лимит переезжает вместе с базой на новый сервер.
Проанализируем типичный сценарий: на новом сервере свободного места "хоть отбавляй", но для файла лога erp_pm.log в настройках MS SQL Server по-прежнему жестко прописан параметр MAXSIZE (например, ограничение в 10 ГБ). Как только объем записанных и еще не очищенных транзакций достигает этой границы, СУБД блокирует дальнейшую запись и возвращает ошибку переполнения журнала, игнорируя терабайты свободного пространства на диске.
Рассмотрим, как быстро локализовать и устранить это ограничение с помощью графической консоли SQL Server Management Studio (SSMS):
File Type будет указано Log).В открывшемся диалоговом окне мы увидим настройки изменения размера файла. Если в блоке Maximum File Size установлен переключатель Limited to... (Ограничить до...), это и есть наша проблема. Нам необходимо:
256 MB, 512 MB или 1024 MB) в зависимости от интенсивности работы пользователей в вашей 1С:ERP. Это позволит избежать сильной фрагментации виртуальных файлов журнала (VLF).В ходе обсуждения подобных проблем часто возникает закономерный вопрос: почему файл журнала транзакций увеличивается в размерах и забивает диск (или упирается в лимит), если для базы данных установлена простая модель восстановления (SIMPLE)? Ведь бытует мнение, что в режиме SIMPLE лог вообще не должен расти.
Разберем этот механизм подробнее. Действительно, в простой модели восстановления неактивная часть журнала транзакций автоматически усекается (помечается как свободная для повторной записи) при достижении контрольной точки — операции Checkpoint. Однако SQL Server физически не может очистить ту часть журнала, которая относится к активным (незавершенным) транзакциям. Журнал будет непрерывно расти в следующих случаях:
COMMIT или ROLLBACK), SQL Server обязан хранить всю историю изменений в логе, и размер файла .ldf будет расти пропорционально объему изменений.ALTER INDEX REBUILD), которые регулярно запускаются ночью, генерируют колоссальный объем транзакционной информации. Даже в модели SIMPLE процесс перестроения индексов крупных таблиц 1С (размером в десятки и сотни гигабайт) пишется в лог-файл в полном объеме, что приводит к его моментальному раздуванию.Если лог продолжает расти и не усекается, мы можем точно выяснить, что именно мешает СУБД очистить его внутреннее пространство. Для этого выполним системный T-SQL запрос к метаданным:
SELECT name AS DatabaseName,
recovery_model_desc AS RecoveryModel,
log_reuse_wait_desc AS ReasonForWaiting
FROM sys.databases;
Проанализируем значение в столбце ReasonForWaiting (или log_reuse_wait_desc) для нашей проблемной базы данных. Оно указывает на конкретное препятствие для очистки лога:
ACTIVE_TRANSACTION: В базе выполняется долгая транзакция. Выясним ее подробности, запустив команду:
DBCC OPENTRAN;
С помощью полученного идентификатора процесса (SPID) мы сможем определить в мониторе активности СУБД, какой именно сеанс 1С держит транзакцию, и при необходимости прервать его командой KILL [Номер_SPID].
LOG_BACKUP: База находится в модели восстановления FULL, и лог не очистится, пока мы не сделаем бэкап журнала транзакций. Если бэкапы логов не настроены, файл .ldf будет расти бесконечно, пока не займет все доступное пространство.REPLICATION: Транзакции ожидают отправки в репликацию. Это часто случается, если базу развернули из копии, где репликация использовалась, а на новом сервере она не настроена. В таком случае выполним команду принудительного удаления репликации:
EXEC sp_removedbreplication 'Имя_Вашей_Базы';
Рассмотрим ситуацию, когда лог транзакций сильно раздулся в результате разовой тяжелой операции (например, при первоначальном обновлении конфигурации ERP до нового релиза), лимит мы уже увеличили, но теперь хотим вернуть дисковое пространство операционной системе.
Важное предостережение: Регулярное сжатие файлов базы данных (Shrink) в рамках ежедневных планов обслуживания — это крайне вредная практика! Постоянное уменьшение и последующее неизбежное увеличение файлов в течение рабочего дня приводят к катастрофической физической фрагментации файлов на диске и падению производительности дисковой подсистемы. В моменты авторасширения лога транзакции пользователей будут "подвисать". Сжатие лога должно быть разовой, исключительной операцией.
Для выполнения безопасного аварийного сжатия журнала транзакций выполним следующий скрипт в SSMS:
-- Переводим базу данных в простую модель восстановления (если она была FULL)
USE [master];
ALTER DATABASE [erp_pm] SET RECOVERY SIMPLE WITH NO_WAIT;
GO
-- Переходим в контекст нашей базы данных
USE [erp_pm];
GO
-- Выполняем сжатие файла лога до целевого размера (например, до 1024 МБ)
-- Обратите внимание: 'erp_pm_log' — это логическое имя файла лога, а не физическое!
DBCC SHRINKFILE (N'erp_pm_log' , 1024);
GO
-- Возвращаем модель восстановления FULL (если это требуется по регламенту бэкапов)
USE [master];
ALTER DATABASE [erp_pm] SET RECOVERY FULL WITH NO_WAIT;
GO
Важный нюанс: Если мы перевели базу обратно в модель восстановления FULL после выполнения этой процедуры, цепочка последовательных номеров транзакций (LSN) оказывается нарушенной. СУБД больше не сможет восстановить базу "на точку во времени" (Point-in-Time) с использованием старых бэкапов логов. Поэтому сразу же после возврата в режим FULL необходимо сделать полный бэкап базы данных (Full Backup) для инициализации новой цепочки резервного копирования.
Проанализируем, как правильно администрировать базу данных 1С:ERP, если специфика бизнеса требует обеспечения отказоустойчивости и возможности восстановления данных на любую секунду времени (модель восстановления FULL):
.ldf:
BACKUP LOG [erp_pm] TO DISK = 'NUL:';
Эта команда сбросит лог без записи на диск, очистит активную часть и позволит выполнить процедуру SHRINKFILE. Помните, что после этого также необходимо незамедлительно запустить полный бэкап базы данных.
Подводя итог нашему разбору, отметим: при переносе баз данных 1С на новые серверы всегда проводите аудит настроек авторасширения и жестких ограничений (Maxsize) для файлов данных и логов. Это убережет вас от неожиданных сбоев посреди рабочего дня и обеспечит стабильную производительность системы автоматизации бизнеса.