Логи 1С в SQL Server — это не просто служебные файлы, а критическая часть системы, которая может как спасти данные при сбоях, так и парализовать работу базы при бесконтрольном росте. Если вы столкнулись с переполнением дискового пространства, замедлением запросов или ошибками типа "Transaction log is full", значит пришло время разобраться с очисткой. Но тут важно не наделать ошибок: неправильное удаление логов может привести к потере данных или нарушению целостности базы.

В этой статье мы разберём все актуальные способы удаления логов 1С в SQL Server — от стандартных инструментов управления базой до скриптов и настроек 1С:Предприятия. Особое внимание уделим безопасности: какие действия можно выполнять на рабочей базе, а какие только в тестовом окружении. Также вы узнаете, как настроить автоматическую очистку, чтобы больше не возвращаться к этой проблеме.

Материал ориентирован на администраторов 1С, разработчиков и ИТ-специалистов, работающих с SQL Server 2012–2022 и платформой 1С:Предприятие 8.3. Если вы не уверены в своих навыках работы с SQL, лучше сначала опробовать методы на тестовой копии базы.

Почему логи 1С в SQL разрастаются и когда их нужно чистить

Логи транзакций в SQL Server — это журнал всех изменений в базе данных. В 1С они накапливаются особенно активно из-за:

  • 📊 Регулярных операций — проведение документов, пересчёт итогов, обмен данными между узлами распределённой базы.
  • 🔄 Длительных транзакций — например, при массовом изменении справочников или закрытии месяца в бухгалтерии.
  • ⚙️ Неправильных настроек модели восстановления — если база работает в режиме FULL без резервного копирования логов.
  • 🚨 Ошибок в коде 1С — незакрытые транзакции, бесконечные циклы или"тяжёлые" запросы.

Когда логи разрастаются, вы можете столкнуться с:

  • 🛑 Остановкой базы — ошибка "The transaction log for database is full" блокирует все операции.
  • 🐢 Замедлением работы — даже простые операции начинают выполняться в разы дольше.
  • 💾 Нехваткой места на диске — логи могут занимать сотни гигабайт, если их не контролировать.
⚠️ Внимание: Если база работает в режиме SIMPLE, логи очищаются автоматически при чекпоинтах. Но в FULL или BULK_LOGGED требуется ручное управление. Проверьте текущий режим командой: 
SELECT name, recovery_model_desc FROM sys.databases

WHERE name ='ВашаБаза1С'

Чистить логи нужно в следующих случаях:

  • 📉 Лог занял более 80% от выделенного пространства (проверяется через DBCC SQLPERF(LOGSPACE)).
  • 🔴 Появились ошибки, связанные с переполнением лога.
  • 📅 Перед крупными операциями (обновлением платформы, реструктуризацией базы).
📊 Как часто вы чистите логи 1С в SQL?
Раз в неделю
Раз в месяц
Только при ошибках
Никогда не чистил
Автоматически по расписанию

Способ 1: Очистка логов через SQL Server Management Studio (SSMS)

Самый безопасный и визуально понятный метод — использование SQL Server Management Studio (SSMS). Он подходит для администраторов, которые не хотят работать с командами T-SQL.

Пошаговая инструкция:

  1. Откройте SSMS и подключитесь к серверу с базой 1С.
  2. В Обозревателе объектов найдите вашу базу (например, Base1C_v8) и кликните по ней правой кнопкой → Задачи → Усечь журнал (Shrink → Files).
  3. В открывшемся окне выберите тип файла Журнал (Log).
  4. В поле Усечь до укажите размер, до которого нужно сократить лог (рекомендуется оставить хотя бы 10–20% от текущего размера).
  5. Нажмите ОК и дождитесь завершения операции.

Если опция Усечь журнал неактивна, значит:

  • 🔹 База работает в режиме FULL, но не было сделано резервной копии лога.
  • 🔹 Есть активные транзакции (проверьте через DBCC OPENTRAN).
⚠️ Внимание: Усечение лога не заменяет резервное копирование! После этой операции вы не сможете восстановить базу до состояния на момент усечения. Всегда делайте бэкап перед очисткой.

Альтернативный путь в SSMS:

  1. Правый клик по базе → Свойства → вкладка Файлы.
  2. Найдите файл лога (обычно имеет расширение .ldf) и нажмите Усечь.

Сделать резервную копию базы|Проверить активные транзакции|Убедиться в режиме восстановления|Запустить усечение в нерабочее время-->

Способ 2: Команды T-SQL для ручной очистки логов

Если вам нужно автоматизировать процесс или работать на сервере без графического интерфейса, используйте команды T-SQL. Этот метод требует прав sysadmin или db_owner.

Базовый скрипт для усечения лога:

USE [ВашаБаза1С];

GO


DBCC SHRINKFILE (N'ВашаБаза1С_log', 100); -- Уменьшает лог до 100 МБ


GO

Но перед этим необходимо:

  1. Сделать резервную копию лога (если база в режиме FULL): 
    BACKUP LOG [ВашаБаза1С] TO DISK = N'C:\Backup\Base1C_log.trn';
  2. Переключить модель восстановления на SIMPLE (опционально, если не нужна точка восстановления): 
    ALTER DATABASE [ВашаБаза1С] SET RECOVERY SIMPLE;

    DBCC SHRINKFILE (N'ВашаБаза1С_log', 1);
    

    ALTER DATABASE [ВашаБаза1С] SET RECOVERY FULL;

Если лог не усекается, попробуйте принудительно освободить место:

USE [ВашаБаза1С];

GO


CHECKPOINT;


GO


DBCC SHRINKFILE (N'ВашаБаза1С_log', TRUNCATEONLY);


GO

Команда Описание Когда использовать
DBCC SHRINKFILE Уменьшает размер файла лога до указанного значения После резервного копирования лога
BACKUP LOG Создаёт резервную копию лога транзакций Обязательно для баз в режиме FULL
CHECKPOINT Принудительно записывает все изменения на диск Если лог не уменьшается после SHRINKFILE
TRUNCATEONLY Очищает лог без физического уменьшения файла Для быстрого освобождения места
⚠️ Внимание: Команда TRUNCATEONLY не уменьшает физический размер файла .ldf, а только освобождает место внутри него. Чтобы файл реально"похудел", используйте DBCC SHRINKFILE после TRUNCATEONLY.

Для баз 1С с большим количеством транзакций рекомендуется использовать скрипт с явным указанием виртуальных файлов лога:

USE [ВашаБаза1С];

GO


-- Узнаём количество виртуальных лог-файлов (VLF)


DBCC LOGINFO;


GO


-- Если VLF > 50, стоит реорганизовать лог


DBCC SHRINKFILE (N'ВашаБаза1С_log', 1024, TRUNCATEONLY);


DBCC SHRINKFILE (N'ВашаБаза1С_log', 1024);


GO

SELECT session_id, login_name, host_name, program_name

FROM sys.dm_exec_sessions


WHERE program_name LIKE'%1C%';

Если есть активные сессии, завершите их командой KILL {session_id} или дождитесь их завершения.-->

Способ 3: Настройка автоматической очистки логов

Чтобы не чистить логи вручную, настройте автоматическое управление через планы обслуживания (Maintenance Plans) или SQL Agent.

Инструкция для SQL Server Agent:

  1. Откройте SSMS → SQL Server Agent → Jobs → New Job.
  2. Создайте шаг с командой: 
    BACKUP LOG [ВашаБаза1С] TO DISK = N'C:\Backup\Base1C_log.trn' WITH COMPRESSION;

    DBCC SHRINKFILE (N'ВашаБаза1С_log', 1024);

  3. Настройте расписание (например, ежедневно в 2:00 ночи).
  4. Убедитесь, что у агента есть права на запись в папку C:\Backup.

Для баз 1С в режиме FULL критически важно:

  • 📌 Регулярно делать бэкапы лога — иначе он будет расти бесконтрольно.
  • 📌 Хранить бэкапы не на системном диске — при сбое вы потеряете и базу, и резервные копии.
  • 📌 Проверять целостность бэкапов командой RESTORE VERIFYONLY.

Пример скрипта для автоматической очистки с учётом размера лога:

DECLARE @LogSizeMB FLOAT;

DECLARE @MaxLogSizeMB FLOAT = 1024; -- Максимальный размер лога в МБ



SELECT @LogSizeMB = CAST(size/128.0 AS DECIMAL(10,2))


FROM sys.master_files


WHERE database_id = DB_ID('ВашаБаза1С') AND type_desc ='LOG';



IF @LogSizeMB > @MaxLogSizeMB


BEGIN


BACKUP LOG [ВашаБаза1С] TO DISK = N'C:\Backup\Base1C_log.trn' WITH COMPRESSION;


DBCC SHRINKFILE (N'ВашаБаза1С_log', @MaxLogSizeMB);


END

⚠️ Внимание: Автоматическая очистка не отменяет необходимость мониторинга! Настройте оповещения о росте лога через SQL Alerts или внешние системы (например, Zabbix).
Что делать, если автоматическая очистка не работает?

Если скрипт в SQL Agent не выполняется, проверьте:

1. Запущен ли служба SQL Server Agent (в services.msc).

2. Есть ли у учётной записи агента права на папку бэкапов.

3. Нет ли ошибок в журнале агентов (SQL Server Agent → Error Logs).

4. Достаточно ли места на диске для создания бэкапа лога.

Если проблема сохраняется, попробуйте запустить скрипт вручную через SSMS для диагностики.

Способ 4: Очистка логов через конфигуратор 1С

Если у вас нет доступа к SQL Server, но есть права администратора 1С, можно попробовать очистить логи через Конфигуратор. Этот метод менее эффективен, но иногда помогает при небольших засорах.

Инструкция:

  1. Запустите 1С:Предприятие в режиме Конфигуратор.
  2. Выберите вашу базу и войдите под пользователем с правами Администратор.
  3. Перейдите в меню Администрирование → Тестирование и исправление.
  4. В открывшемся окне поставьте галочки:
    • 🔹 Проверять логическую целостность
    • 🔹 Проверять ссылочную целостность
    • 🔹 Реиндексировать таблицы
    • 🔹 Сжать таблицы базы данных
  • Нажмите Выполнить и дождитесь завершения операции.

    • Этот метод косвенно влияет на логи, так как:

    • 🔄 Перестраивает индексы, что может освободить место в файле базы (.mdf).
    • 🗑️ Удаляет"мусорные" записи, уменьшая нагрузку на транзакции.
    • 📉 Сжимает таблицы, что снижает объём изменений, записываемых в лог.

    Однако это не заменит полноценную очистку лога SQL! Если проблема в переполнении файла .ldf, используйте методы из предыдущих разделов.

    Для баз на PostgreSQL (реже используется в 1С) очистка логов выполняется через:

    -- Усечение лога (требует прав суперпользователя)

    CHECKPOINT;
    

    -- Или через pg_archivecleanup (для архивных логов)
    

    pg_archivecleanup /path/to/archive/location X log

    💡

    Тестирование и исправление в Конфигураторе 1С помогает при некритичном росте логов, но не решает проблему переполнения .ldf-файла. Для этого нужны инструменты SQL Server.

    Способ 5: Очистка логов для распределённых баз 1С (РИБ)

    Если вы работаете с распределённой информационной базой (РИБ), очистка логов имеет свои нюансы. В таких системах логи накапливаются активнее из-за постоянного обмена данными между узлами.

    Особенности очистки для РИБ:

    • 🔄 Сначала очищайте логи на главном узле, затем на подчинённых.
    • 📡 Приостановите обмен данными на время очистки (через Администрирование → Обмен данными).
    • 📊 Проверьте очередь обмена — если есть неотправленные пакеты, они могут блокировать лог.

    Пошаговая инструкция:

    1. Остановите обмен данными на всех узлах РИБ.
    2. На главном узле выполните резервное копирование лога и его усечение (как в Способе 2).
    3. Проверьте очередь обмена на подчинённых узлах: 
      SELECT * FROM _1SExchange WHERE _Status = 0;

      Если есть записи, дождитесь их обработки или удалите вручную (осторожно!).

    4. Повторите очистку логов на подчинённых узлах.
    5. Возобновите обмен данными.

    Для РИБ с большим количеством узлов рекомендуется:

    • 📅 Настроить разное время очистки на каждом узле, чтобы не перегружать сеть.
    • 📈 Мониторить размер логов на всех узлах централизованно (например, через Zabbix или Grafana).
    • 🔧 Использовать скрипты для автоматической очистки с учётом статуса обмена.
    ⚠️ Внимание: В РИБ не рекомендуется использовать режим SIMPLE для модели восстановления, так как это может привести к потере данных при сбоях обмена. Лучше настроить регулярное резервное копирование логов в режиме FULL.

    Ошибки при очистке логов 1С и как их избежать

    Даже опытные администраторы иногда сталкиваются с проблемами при работе с логами. Рассмотримчные ошибки и способы их решения.

    Ошибка Причина Решение
    Cannot shrink log file Активные транзакции или не сделан бэкап лога Выполните BACKUP LOG или завершите транзакции
    Log backup is terminating abnormally Файл лога повреждён или недостаточно места на диске Проверьте целостность лога (DBCC CHECKDB) и освободите место
    The database is in single-user mode База переведена в однопользовательский режим Выполните ALTER DATABASE [Base] SET MULTI_USER;
    Лог не уменьшается после SHRINKFILE Виртуальные файлы лога фрагментированы Пересоздайте лог или используйте DBCC SHRINKFILE с параметром TRUNCATEONLY

    Другие распространённые проблемы:

    • 🔴 Ошибка 9002 ("Log full") — возникает, когда лог заполнен на 100%. Решение:
      1. Освободите место на диске.
      2. Увеличьте размер файла лога временно: 
        ALTER DATABASE [ВашаБаза1С] MODIFY FILE (NAME ='ВашаБаза1С_log', SIZE = 2048MB);
      3. Сделайте бэкап лога и усеките его.
  • 🔴 Медленная очистка — если SHRINKFILE работает слишком долго, прервите операцию и выполните её в нерабочее время. Используйте флаг NOTRUNCATE для поэтапного уменьшения.
  • 🔴 Потерянные транзакции — если после очистки пропадут данные, восстановите базу из последнего бэкапа.

    • Чтобы избежать ошибок:

    • 🔹 Всегда делайте бэкап перед очисткой.
    • 🔹 Проверяйте активные соединения с базой (sp_who2).
    • 🔹 Не уменьшайте лог до минимального размера — оставляйте запас 10–20%.
    • 🔹 Используйте тестовое окружение для отработки скриптов.
    Что делать, если после очистки лог снова быстро растёт?

    Это признак того, что в базе есть проблема:

    1. Длительные транзакции — проверьте код 1С на незакрытые транзакции (используйте BEGIN TRANSACTION/COMMIT явно).

    2. Массовые операции — например, обмен данными или пересчёт итогов. Распределите их по времени.

    3. Неправильная модель восстановления — если база в режиме FULL, но бэкапы лога не делаются, он будет расти бесконтрольно.

    4. Фрагментация лога — проверьте количество VLF (виртуальных лог-файлов). Если их больше 50, реорганизуйте лог.

    FAQ: Частые вопросы по очистке логов 1С в SQL

    Можно ли полностью удалить файл лога .ldf?

    Нет, это приведёт к повреждению базы. Файл лога обязателен для работы SQL Server. Вместо удаления используйте усечение (DBCC SHRINKFILE) или пересоздайте лог через резервное копирование и восстановление базы.

    Как часто нужно чистить логи в базе 1С?

    Это зависит от интенсивности работы:

    • 📌 Для небольших баз (до 50 ГБ) — раз в 1–2 месяца.
    • 📌 Для активных баз (с частыми транзакциями) — еженедельно.
    • 📌 Для РИБ — после каждого крупного обмена данными.

      • Главное — следить за размером лога и чистить его при превышении 70–80% от выделенного пространства.

    Что будет, если не чистить логи?

    Последствия могут быть критичными:

    • 🛑 Остановка базы — при заполнении лога на 100% все операции блокируются.
    • 🐢 Замедление работы — даже простые запросы будут выполняться в разы дольше.
    • 💥 Потеря данных — если лог переполнится во время транзакции, она может откатиться некорректно.
    • 💾 Нехватка места на диске — логи могут занимать сотни гигабайт.

      • В худшем случае придётся восстанавливать базу из бэкапа с потерей актуальных данных.

    Как очистить логи, если нет доступа к SQL Server?

    Если у вас нет прав на SQL Server, но есть доступ к 1С:Предприятию, попробуйте:

    1. Выполнить тестирование и исправление через Конфигуратор (как в Способе 4).
    2. Обратиться к администратору SQL с просьбой очистить логи.
    3. Если база небольшая — сделать выгрузку/загрузку через dt/cf (но это не очистит лог, а создаст новую базу).

      4. Без доступа к SQL полноценная очистка логов невозможна.

    Можно ли отключить ведение логов в 1С?

    Нет, логи транзакций — это часть механизма SQL Server, и их нельзя отключить полностью. Однако можно:

    • 🔹 Перевести базу в режим SIMPLE (но это отключит возможность точечного восстановления).
    • 🔹 Настроить автоматическую очистку логов (как в Способе 3).
    • 🔹 Уменьшить уровень логирования в 1С (например, отключить Журнал регистрации для ненужных событий).