Transaction Log Full 1С:Предприятие и СУБД

Модель восстановления MS SQL для 1С: Простая (Simple) или Полная (Full)?

Обновлено: 10.09.2026 · Официальная документация ↗

Архитектура Transaction Log (LDF) и симптомы переполнения

Системы 1С:Предприятие генерируют колоссальный объем транзакций в СУБД (Microsoft SQL Server). Каждая операция (проведение документа, реструктуризация) сначала пишется в журнал транзакций (файл .ldf). Если выбрана модель восстановления Полная (Full), SQL Server не очищает лог транзакций до тех пор, пока администратор не сделает резервную копию этого лога (Transaction Log Backup). Симптомы: файл лога (LDF) разрастается до сотен гигабайт, занимая всё место на диске. 1С зависает, выдавая ошибку SQL Server: «The transaction log for database '1C_Base' is full due to 'LOG_BACKUP'». Бизнес-риски: аварийная остановка СУБД (Downtime), потеря данных при падении диска, если бэкапы настроены неверно.

Сравнение моделей восстановления (Recovery Models)

Модель	Поведение лога (LDF)	Возможность восстановления	Сфера применения в 1С
Простая (Simple)	Автоматически очищается (Truncate) после завершения транзакции (CheckPoint). LDF не растет бесконечно.	Только на момент последнего полного бэкапа (Full Backup).	Тестовые базы, ЗУП (иногда), базы с ночными бэкапами, где допустима потеря данных за 1 день.
Полная (Full)	Растет постоянно. Очищается ТОЛЬКО после бэкапа лога.	Point-in-Time Recovery (Восстановление на любую секунду до сбоя).	Production-базы (ERP, УТ). Критичные данные, транзакции 24/7.

Алгоритм устранения проблемы и настройка бэкапов

Сценарий 1: Экстренное сжатие лога (Shrink) и перевод в Simple

Если диск уже забит на 100%, базу нужно перевести в Simple, сжать лог, а затем вернуть обратно (или оставить в Simple, если Point-in-Time не нужен). Выполните в SQL Server Management Studio (SSMS):

 USE [master]
 Перевод базы в простую модель (Очистка лога)
ALTER DATABASE [1C_Base_Name] SET RECOVERY SIMPLE WITH NO_WAIT
GO

 Сжатие физического файла LDF до минимального размера (например, 10 МБ)
USE [1C_Base_Name]
DBCC SHRINKFILE (N'1C_Base_Name_log', 10)
GO

 Возврат в полную модель (Если требуется)
ALTER DATABASE [1C_Base_Name] SET RECOVERY FULL WITH NO_WAIT
GO

Сценарий 2: Правильная настройка Плана Обслуживания (Maintenance Plan) для Full Model

Если база работает в Full Mode, LDF не будет расти, если его регулярно бекапить.

Откройте SSMS -> Management -> Maintenance Plans.
Создайте план (или скрипт SQL Agent).
Настройте Back Up Database (Full) — 1 раз в сутки (ночью).
Добавьте Back Up Database (Transaction Log) — каждые 30 или 60 минут в течение дня.
При успешном выполнении лог-бэкапа SQL Server сам пометит внутренние VLF (Virtual Log Files) как свободные, и LDF перестанет пухнуть (файл не уменьшится в ОС, но внутри будет перезаписываться).

Типовые ошибки администраторов

Регулярный Shrink (Сжатие) в скриптах: Настройка авто-шринка (Auto Shrink) или выполнение DBCC SHRINKFILE каждую ночь — это катастрофическая ошибка (Best Practice Violation). Шринк вызывает фрагментацию файловой системы и индексов SQL, убивая производительность 1С. Размер LDF должен быть стабильным (обычно 20-30% от размера MDF).
Полная модель без лог-бэкапов: Оставить базу в Full Recovery и делать только ночные Full Backups. В этом случае лог не усекается, что гарантированно приведет к исчерпанию места на диске через пару дней/недель.

SQL Server 'съедает' ОЗУ, а перепроведение за месяц длится сутками?
Производительность 1С на 80% зависит от правильной настройки СУБД (MAXDOP, Cost Threshold, флаги трассировки, TempDB). Администраторы баз данных ITSTM проведут комплексный аудит вашего MS SQL / PostgreSQL и настроят отказоустойчивые планы обслуживания (AlwaysOn / Репликация).

💡 Практика специалистов: Практика ITSTM: Мы часто сталкиваемся с тем, что базы 1С разворачиваются администраторами по принципу 'Next-Next-Finish'. По умолчанию SQL Server ставит модель Full для новых баз. В 90% небольших компаний никто не настраивает бэкапы Transaction Log. Первое, что мы делаем на аудите — проверяем лог-бэкапы и переводим некритичные базы (ЗУП, Тестовые) в Simple.

Частые вопросы (FAQ)

Почему после перевода в Simple файл LDF не уменьшился на диске?

Смена модели на Simple или выполнение бэкапа лога делает внутреннее пространство файла (VLF) 'свободным' для новых записей, но физически операционной системе (ОС) место не отдается. Чтобы отдать место ОС, нужно выполнить DBCC SHRINKFILE, но делать это нужно разово, только при ЧП.

Какую модель выбрать при реструктуризации или обновлении конфигурации 1С?

Обновление конфигурации (применение .cf) генерирует гигантские транзакции (создание новых таблиц, переливка данных). Если база в Full модели, LDF может вырасти в 2-3 раза. Рекомендуется перед крупным обновлением временно перевести базу в Simple, обновить, а затем вернуть в Full и СРАЗУ сделать Full Backup.

Как восстановить базу на конкретное время (например, на 14:15)?

Если база была в Full модели и лог-бэкапы делались, вы восстанавливаете последний ночной Full Backup (с параметром NORECOVERY), а затем накатываете все Transaction Log Backups по цепочке до нужного времени (с параметром STOPAT = '2023-10-25 14:15:00').

Поможет ли модель Simple ускорить работу 1С?

Незначительно. SQL Server в модели Simple все равно пишет транзакции в лог (LDF) для обеспечения целостности (ACID), просто он усекает их быстрее. На скорость проведения документов (Insert/Update) больше влияет скорость дисков (IOPS/Latency), где лежит LDF, а не модель восстановления.