Как почистить логи 1С в SQL Server

База 1С на SQL Server растёт не только за счёт данных документов. Журнал транзакций (файл .ldf) при полной модели восстановления может раздуваться до десятков и сотен гигабайт, а журнал регистрации 1С копит миллионы записей о действиях пользователей. Когда диск заполняется, сервер 1С начинает тормозить, а в худшем случае база останавливается с ошибкой нехватки места.

Чистка логов — штатная задача администратора, но выполнять её нужно в правильном порядке: сначала понять, какой именно лог разросся и почему, затем выбрать безопасный способ сокращения. Простое удаление файла журнала транзакций или грубое сжатие без бэкапа может привести к потере данных или невозможности восстановить базу на нужный момент времени.

Ниже разобраны практические сценарии: диагностика размеров, сжатие журнала транзакций, смена модели восстановления, очистка журнала регистрации 1С и настройка профилактики, чтобы проблема не возвращалась.

Какие логи есть у 1С на SQL Server и почему они растут

Под «логами 1С» обычно понимают три разных сущности, и путать их нельзя — чистятся они по-разному. Первая — журнал транзакций SQL Server (файл .ldf), в который записываются все изменения данных. Вторая — журнал регистрации 1С, внутренний механизм платформы, фиксирующий входы пользователей, проведение документов и ошибки. Третья — технологический журнал и логи кластера серверов 1С, которые пишутся в файлы на диске сервера приложений.

Чаще всего проблему создаёт именно журнал транзакций. Если база работает в полной модели восстановления (Full), журнал очищается только после резервного копирования журнала. Если бэкапы лога не настроены — а это типичная ситуация, когда базу развернули «по умолчанию» — файл .ldf растёт бесконечно, даже если самих данных немного.

Журнал регистрации 1С растёт медленнее, но в крупных базах с сотнями пользователей за несколько лет накапливает гигабайты записей. Технологический журнал, если его включили для диагностики и забыли выключить, способен заполнить диск за считанные дни.

Диагностика: определяем, что именно заняло место

Прежде чем что-то чистить, выясните размеры файлов базы. В SQL Server Management Studio (SSMS) это делается через свойства базы данных на вкладке Files, либо запросом к системным представлениям. Обратите внимание на соотношение размеров .mdf (данные) и .ldf (журнал): если журнал сопоставим с данными или больше — это и есть источник проблемы.

Дополнительно проверьте модель восстановления: правый клик по базе → Properties → Options → Recovery model. Значение Full без регулярных бэкапов журнала — гарантированный рост .ldf. Также полезно выполнить запрос DBCC SQLPERF(LOGSPACE), который покажет размер и процент использования журнала по всем базам.

DBCC SQLPERF(LOGSPACE);
GO
SELECT name, recovery_model_desc FROM sys.databases WHERE name = 'MyBase1C';

Для журнала регистрации 1С оцените размер каталога 1Cv8Log внутри папки информационной базы (в клиент-серверном варианте — в каталоге базы на сервере 1С, а не на SQL-сервере). Если папка весит гигабайты, а отборы в журнале регистрации работают медленно — пора сокращать.

Чистка журнала транзакций SQL Server

Главное правило: журнал транзакций нельзя просто удалить как файл. Он очищается штатными средствами — сначала освобождается место внутри журнала (усечение), затем при необходимости сжимается сам файл. Пропуск первого шага — самая частая причина, почему «shrink не работает».

Вариант 1: перевод в простую модель восстановления

Если вам не требуется восстановление базы на произвольный момент времени (для большинства баз 1С достаточно ежедневного полного бэкапа), самый простой путь — переключить базу в модель Simple. В этой модели SQL Server автоматически усекает журнал после контрольных точек.

1. 1
   Сделайте полную резервную копию базы средствами SQL Server
2. 2
   В SSMS: правый клик по базе → Properties → Options → Recovery model → Simple → OK
3. 3
   Правый клик по базе → Tasks → Shrink → Files → выберите тип файла Log
4. 4
   Укажите целевой размер (например, 1024 МБ) и подтвердите сжатие
5. 5
   Проверьте размер файла .ldf на диске и свободное место

Вариант 2: сжатие без смены модели восстановления

Если полная модель нужна (например, требуется восстановление на момент времени или настроена репликация), сначала выполните резервное копирование журнала транзакций, и только потом сжимайте файл. Без бэкапа журнала усечение не произойдёт, и shrink вернёт файл практически без изменений.

BACKUP LOG [MyBase1C] TO DISK = 'D:\Backup\MyBase1C_log.trn';
GO
USE [MyBase1C];
DBCC SHRINKFILE (N'MyBase1C_log', 1024);
GO

Учтите, что сжатие журнала — разовая мера. Если причина роста не устранена, файл раздуется снова. Поэтому после сжатия обязательно настройте либо регулярные бэкапы журнала (для Full), либо простую модель восстановления.

Выбор модели восстановления для баз 1С

Модель восстановления определяет, как ведётся журнал транзакций и какие варианты восстановления доступны. Для типовых баз 1С выбор обычно сводится к двум вариантам.

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

Очистка журнала регистрации 1С

Журнал регистрации не лежит в SQL-базе как обычная таблица — платформа хранит его в отдельных файлах. Чистить его запросами к SQL Server нельзя: это нарушит целостность. Используйте штатный механизм сокращения.

Откройте конфигуратор, перейдите в меню «Администрирование» → «Настройка журнала регистрации». Там же доступна кнопка «Сократить»: укажите дату, старше которой события нужно удалить, и подтвердите операцию. Платформа создаст новый файл журнала без старых записей, а старый можно будет удалить или архивировать.

Полезные меры на будущее: ограничьте состав регистрируемых событий (не нужно писать все информационные сообщения, если достаточно ошибок и действий с данными), а также настройте разделение журнала по периодам — по дням или месяцам. Тогда старые фрагменты можно удалять файлами, не запуская сокращение всего журнала.

Технологический журнал и логи кластера 1С

Технологический журнал включается файлом logcfg.xml в каталоге conf сервера 1С и предназначен для диагностики. Если его включили для расследования проблемы и не выключили, он будет писать гигабайты дампов и событий. Проверьте наличие logcfg.xml: если диагностика завершена, удалите или переименуйте файл и перезапустите агент сервера.

Служебные файлы кластера (каталог srvinfo, подкаталоги reg_1541 и подобные) содержат журналы регистрации кластера и списки сеансов. Их старые файлы можно удалять вручную при остановленном агенте сервера 1С, но делать это стоит аккуратно и только для заведомо устаревших данных.

Профилактика: как не допустить повторного переполнения

Разовая чистка решает симптом, но не причину. Чтобы логи не разрастались снова, настройте регулярное обслуживание. Для SQL Server это план обслуживания (Maintenance Plan) или задания агента SQL Server: полный бэкап ежедневно, бэкапы журнала каждые 15–60 минут при модели Full, контроль свободного места на дисках.

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

Частые вопросы