Как почистить логи в 1С 8.3 на SQL-сервере

Логи в связке «1С:Предприятие 8.3 + MS SQL Server» растут с двух сторон: журнал регистрации самой 1С (файлы формата .lgd или старый .lgp/.lgf) и журнал транзакций SQL Server (файл .ldf базы данных). Когда место на диске заканчивается, администраторы часто путают эти сущности и удаляют не то — в лучшем случае теряется история действий пользователей, в худшем — база переходит в состояние suspect.

Чистка логов 1С на SQL-развёртывании — штатная операция обслуживания, но она требует понимания, где именно накопился объём. Обычно проблема выглядит так: диск с данными заполнен, база работает медленно, а в свойствах видно, что файл журнала транзакций разросся до десятков гигабайт при модели восстановления Full без регулярного бэкапа журнала.

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

Где именно хранятся логи 1С 8.3 и что в них накапливается

Журнал регистрации 1С фиксирует действия пользователей, ошибки, фоновые задания и изменения данных. В клиент-серверном варианте он хранится в каталоге srvinfo на сервере 1С, в подпапке reg_1541 (или другом порту кластера), внутри — папка с GUID информационной базы. В новых версиях платформы используется формат .lgd (SQLite-подобный), в старых — связка файлов .lgp и .lgf.

Журнал транзакций SQL Server (.ldf) — это уже не «лог 1С», а внутренний механизм СУБД, обеспечивающий целостность и восстановление. Он растёт при любом изменении данных, а при модели восстановления Full не очищается сам, пока не выполнен бэкап журнала. Именно этот файл чаще всего «съедает» диск.

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

Подготовка: что сделать до очистки

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

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

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

Сокращение журнала регистрации через конфигуратор

Штатный способ почистить журнал регистрации 1С 8.3 — встроенная функция сокращения. Она удаляет события старше указанной даты и переписывает журнал заново. Алгоритм одинаков для файлового и клиент-серверного вариантов, меняется только расположение файлов.

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

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

1. 1
   Сделайте резервную копию базы и скопируйте каталог журнала регистрации
2. 2
   Откройте Конфигуратор → Администрирование → Обслуживание → Настройка журнала регистрации
3. 3
   Нажмите «Сократить», укажите дату отсечки и каталог для сохранения копии
4. 4
   Дождитесь завершения, не закрывая конфигуратор
5. 5
   Проверьте журнал в режиме предприятия и размер файлов .lgd

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

Если разросся файл .ldf, действовать нужно средствами SQL Server. Сначала выясните модель восстановления базы: правый клик по базе в SSMS → Properties → Options → Recovery model. При модели Full журнал урезается только после бэкапа журнала транзакций; при Simple — усекается автоматически по чекпоинтам, и достаточно выполнить сжатие файла.

Для модели Full последовательность такая: выполните бэкап журнала транзакций (Tasks → Back Up → Transaction Log), затем сожмите файл через Tasks → Shrink → Files, выбрав тип файла Log. Если сжатие не даёт эффекта, повторите бэкап журнала ещё раз — активная часть журнала могла находиться в конце файла.

Для баз, где восстановление на произвольный момент времени не требуется, допустимо переключить модель восстановления на Simple: тогда журнал перестанет расти бесконтрольно. Это осознанный компромисс: вы теряете возможность point-in-time recovery и должны компенсировать её регулярными полными и разностными бэкапами.

-- Проверить модель восстановления и размер журнала
SELECT name, recovery_model_desc FROM sys.databases WHERE name = 'MyBase';
DBCC SQLPERF(LOGSPACE);
-- Бэкап журнала (для модели Full)
BACKUP LOG MyBase TO DISK = 'D:\Backup\MyBase_log.trn';
-- Сжатие файла журнала до 1024 МБ
USE MyBase;
DBCC SHRINKFILE (N'MyBase_log', 1024);

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

Настройка журнала регистрации, чтобы он не разрастался снова

Одноразовая чистка не решает проблему, если журнал пишет всё подряд. В той же форме «Настройка журнала регистрации» можно снизить детализацию: оставить регистрацию ошибок, предупреждений и ключевых событий, отключив информационные сообщения и детальные записи о доступе к данным. Для большинства баз этого достаточно и для аудита, и для диагностики.

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

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

Типичные ошибки и чем они опасны

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

Вторая частая ошибка — сжатие файла журнала SQL Server без бэкапа при модели Full. Команда SHRINKFILE в этом случае просто не освобождает место, потому что виртуальные файлы журнала не усекаются. Администратор повторяет сжатие, не понимая причины, а проблема решается одним бэкапом журнала.

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

Проверка результата после чистки

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

После работ с журналом транзакций выполните DBCC SQLPERF(LOGSPACE) и убедитесь, что использование журнала вашей базы снизилось до разумных значений. Проверьте, что приложение 1С работает штатно: авторизация пользователей, проведение документов, регламентные задания. Наконец, убедитесь, что задания бэкапа журнала созданы и выполняются по расписанию — иначе чистка была разовой.

Если после всех операций база ведёт себя нестабильно — появились ошибки чтения журнала регистрации или SQL Server сообщает о проблемах с файлами — не пытайтесь «дочистить» дальше. Восстановите резервную копию на тестовом сервере, разберитесь в причине и только потом повторяйте процедуру на рабочей базе.

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