Раздутый лог базы 1С: как освободить место на диске и не потерять данные

Почистить журнал транзакций 1С в MS SQL Server можно двумя путями: сделать резервную копию лога (BACKUP LOG) и затем сжать файл .ldf командой DBCC SHRINKFILE, либо перевести базу в простую модель восстановления (SIMPLE), если копии лога вам не нужны. В PostgreSQL удалять логи транзакций вручную нельзя: папка pg_wal очищается сама, а если она растёт, ищут причину — сломанный архив, забытый слот репликации или завышенные параметры.

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

Почему лог транзакций базы 1С разрастается

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

Основные причины роста:

• 📌 Модель восстановления FULL без копий лога. База 1С, созданная через консоль кластера, наследует модель восстановления от системной базы model, а там часто стоит FULL. В этом режиме SQL Server хранит лог до тех пор, пока его не скопируют. Нет копий лога — файл растёт бесконечно.
• 📌 Долгая транзакция. Закрытие месяца , перепроведение документов за год, свёртка базы, загрузка большого .dt — всё это идёт одной или несколькими крупными транзакциями. Пока транзакция не завершена, освободить место в логе нельзя.
• 📌 Обновление конфигурации с реструктуризацией. При изменении структуры таблиц СУБД переписывает гигабайты данных, и лог за час может вырасти в размер всей базы.
• 📌 Сломанная репликация или архивирование. Для PostgreSQL это главная причина: если archive_command возвращает ошибку или реплика отстала, файлы WAL копятся.
• 📌 Неудачные настройки автоприроста. Прирост лога в процентах на большой базе даёт огромные скачки и тысячи мелких виртуальных сегментов (VLF), из-за чего база дольше стартует и восстанавливается.

Подготовка к очистке журнала транзакций

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

Что проверить в SQL Server

Откройте SQL Server Management Studio, подключитесь к серверу и выполните:

-- заполненность логов всех баз, в процентах
DBCC SQLPERF(LOGSPACE);

-- модель восстановления и причина, по которой лог не освобождается
SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases;

Столбец log_reuse_wait_desc — главная подсказка:

Общие правила подготовки

1. Сделайте полную резервную копию базы средствами СУБД. Без свежей полной копии смену модели восстановления и сжатие не начинайте.
2. Узнайте логическое имя файла лога — оно нужно для команды сжатия:

USE [buh_base];
SELECT name, type_desc, size * 8 / 1024 AS size_mb
FROM sys.database_files;

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

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

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

Сценарий 1: модель FULL — копия лога и сжатие

1. Сделайте резервную копию журнала транзакций:

BACKUP LOG [buh_base]
TO DISK = N'D:\Backup\buh_base_log.trn';

2. Проверьте log_reuse_wait_desc ещё раз. Должно стать NOTHING. Если осталось LOG_BACKUP, повторите копию: иногда активная часть лога находится в конце файла и освобождается со второго раза.
3. Сожмите файл до разумного размера. Второй параметр — целевой размер в мегабайтах:

USE [buh_base];
DBCC SHRINKFILE (N'buh_base_log', 2048);

4. Сохраните файл .trn вместе с последней полной копией. Без цепочки копий лога восстановление на момент времени невозможно.

Сценарий 2: модель SIMPLE — однократная очистка

ALTER DATABASE [buh_base] SET RECOVERY SIMPLE;
GO
USE [buh_base];
CHECKPOINT;
DBCC SHRINKFILE (N'buh_base_log', 2048);

В простой модели SQL Server сам освобождает место в логе после каждой контрольной точки. Файл перестанет расти, если только не случится одна огромная транзакция.

Какой размер оставить

Не сжимайте лог до нуля. После сжатия он снова вырастет на первой же крупной операции, и каждый прирост останавливает запись до заполнения нового куска файла.

Практический ориентир: 20–30% от размера файла данных для базы с ежедневной работой, либо размер, до которого лог дорастает за неделю при регулярных копиях. Для базы на 50 ГБ это примерно 10–15 ГБ.

Автоприрост задайте фиксированным шагом в мегабайтах, а не в процентах:

ALTER DATABASE [buh_base]
MODIFY FILE (NAME = N'buh_base_log', FILEGROWTH = 512MB);

Управление логами транзакций в PostgreSQL

В PostgreSQL журнал транзакций называется WAL и лежит в папке pg_wal внутри каталога данных (в версиях до 10 — pg_xlog). Сервер сам удаляет и переиспользует старые сегменты после контрольной точки. Удалять файлы из pg_wal вручную нельзя: кластер после этого может не запуститься, а данные — повредиться.

Как посмотреть размер WAL

-- суммарный объём pg_wal (PostgreSQL 10+, нужны права суперпользователя или роль pg_monitor)
SELECT pg_size_pretty(sum(size)) FROM pg_ls_waldir();

-- ключевые параметры
SHOW max_wal_size;
SHOW archive_mode;
SHOW archive_command;

Три типичные причины роста pg_wal

1. Ошибка архивирования. Если archive_mode = on, сервер хранит каждый сегмент, пока archive_command не отработает успешно. Проверьте счётчики:

SELECT archived_count, failed_count, last_failed_wal, last_failed_time
FROM pg_stat_archiver;

Растёт failed_count — смотрите текстовый лог PostgreSQL: обычно там видно, что кончилось место в папке архива или сменился путь. После починки команды накопленные сегменты уйдут в архив и удалятся сами.

2. Забытый слот репликации. Слот держит WAL, пока реплика его не прочитает. Если реплику выключили, а слот остался, файлы копятся бесконечно:

SELECT slot_name, active,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained
FROM pg_replication_slots;

Неактивный слот с десятками гигабайт в столбце retained — причина найдена. Если реплика точно больше не нужна, удалите слот:

SELECT pg_drop_replication_slot('имя_слота');

3. Завышенные параметры. max_wal_size в десятки гигабайт или большой wal_keep_size (PostgreSQL 13+) означают, что сервер держит столько WAL намеренно. Уменьшите значения в postgresql.conf и перечитайте конфигурацию через SELECT pg_reload_conf();. После следующих контрольных точек лишние сегменты удалятся.

Текстовые логи PostgreSQL

Иногда «логами» называют не WAL, а текстовые файлы событий сервера в папке log (или pg_log). Их удалять можно, но лучше настроить ротацию в postgresql.conf:

logging_collector = on
log_filename = 'postgresql-%a.log'
log_rotation_age = 1d
log_truncate_on_rotation = on

Такая схема хранит ровно семь файлов — по одному на день недели — и перезаписывает их по кругу.

Что ускорит базу на самом деле

Размер WAL почти не влияет на скорость работы пользователей 1С. Если цель — ускорение, смотрите на работу autovacuum и актуальность статистики: раздутые таблицы и устаревшая статистика тормозят запросы гораздо сильнее.

Особенности файлового варианта 1С

В файловой базе нет отдельной СУБД, а значит нет и журнала транзакций в привычном смысле. Чистить там приходится другое.

Сам файл 1Cv8.1CD

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

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

Журнал регистрации

Журнал регистрации платформы хранится в папке 1Cv8Log: в файловой базе — рядом с 1Cv8.1CD, в клиент-серверной — в каталоге кластера srvinfo\reg_1541\<идентификатор базы>\1Cv8Log. За несколько лет он вырастает до десятков гигабайт.

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

Автоматизация обслуживания базы данных 1С

Разовая очистка лога решает симптом. Чтобы проблема не вернулась, настройте регулярное обслуживание средствами СУБД — сама 1С этого не делает.

SQL Server: план обслуживания

В редакциях Standard и Enterprise используйте агент SQL Server (SQL Server Agent → Jobs) или мастер планов обслуживания (Management → Maintenance Plans). Типовой набор для базы 1С:

В редакции Express агента нет. Там копию лога запускают через sqlcmd из Планировщика заданий Windows:

sqlcmd -S .\SQLEXPRESS -E -Q "BACKUP LOG [buh_base] TO DISK = N'D:\Backup\buh_base_log.trn' WITH INIT"

WITH INIT перезаписывает файл, поэтому так годится только хранить последнюю копию. Для полноценной цепочки добавляйте в имя файла дату и время.

PostgreSQL: настройки вместо заданий

Для PostgreSQL отдельного задания на очистку WAL не нужно. Достаточно:

• ✅ разумного max_wal_size — например, 2–8 ГБ для типичной базы 1С;
• ✅ мониторинга pg_stat_archiver и pg_replication_slots, если включены архив или реплики;
• ✅ ротации текстовых логов;
• ✅ включённого autovacuum.

Контроль заполнения диска

Самая полезная автоматизация — оповещение о свободном месте. Если на диске с логами остаётся меньше 15–20%, администратор должен узнать об этом до того, как база остановится.

Частые ошибки при очистке журнала транзакций

Ещё несколько ошибок, которые встречаются у администраторов баз 1С:

• ❌ Удалить файл .ldf при остановленной службе. База после этого переходит в подозрительное состояние, и восстановление без потерь не гарантировано.
• ❌ Перевести на SIMPLE базу, для которой настроены копии лога. План обслуживания начнёт падать с ошибкой, а точек восстановления станет меньше, чем ожидает бухгалтерия.
• ❌ Сжать файл данных .mdf вместе с логом. Сжатие файла данных сильно фрагментирует индексы, и база 1С начинает работать медленнее.
• ❌ Чистить лог во время обновления конфигурации. Реструктуризация идёт крупной транзакцией — место всё равно не освободится, а нагрузка вырастет.

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