Журнал транзакций базы 1С занял весь диск: что делать в MS SQL и PostgreSQL

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

Типичная картина: утром бухгалтерия не может провести документ , 1С пишет об ошибке СУБД, а на диске с базами ноль байт. Администратор открывает папку с данными и видит файл buh_log.ldf на 180 ГБ при самой базе на 25 ГБ. Ниже — как почистить журнал безопасно и сделать так, чтобы он больше не разрастался.

Почему журнал SQL у базы 1С растёт и когда его чистить

Под словами «лог SQL» обычно понимают одно из трёх. Разберитесь, что именно занимает место, — от этого зависит способ.

Журнал транзакций MS SQL растёт по понятным причинам:

• 📈 база в модели восстановления FULL, а резервные копии журнала никто не делает. Записи копятся бесконечно;
• ⏳ открыта долгая транзакция: закрытие месяца, перепроведение документов за год, обновление конфигурации с реструктуризацией;
• 🔁 настроена репликация или группа доступности, и реплика отстала;
• 📦 ночное обслуживание перестраивает индексы, и каждая перестройка пишет в журнал гигабайты.

Когда 1С создаёт базу на MS SQL, модель восстановления наследуется от системной базы model. По умолчанию там стоит FULL. Поэтому база, которую никто не настраивал, почти всегда в FULL и без копий журнала — самый частый сценарий разросшегося .ldf.

Чистить журнал пора, когда диск заполнен больше чем на 85–90%, либо когда .ldf в разы больше файла данных и не уменьшается после резервного копирования.

Подготовка: резервная копия и диагностика

Перед любыми действиями выясните, почему сервер не может переиспользовать журнал. Эти запросы ничего не меняют, их можно выполнять в рабочее время.

Размер и заполненность журналов всех баз:

DBCC SQLPERF(LOGSPACE);

Модель восстановления и причина, по которой журнал не освобождается:

SELECT name,
       recovery_model_desc,
       log_reuse_wait_desc
FROM sys.databases
ORDER BY name;

Значение log_reuse_wait_desc подскажет следующий шаг:

Долгую транзакцию ищут так:

DBCC OPENTRAN('buh');

Команда покажет номер сеанса (SPID) и время начала самой старой транзакции. Дальше по SPID в мониторе активности SQL Server или в консоли кластера 1С видно, какой пользователь или регламентное задание её держит.

Перед сжатием сделайте полную резервную копию базы средствами SQL Server или выгрузку .dt. Если диск уже заполнен до нуля, копию кладите на другой диск или сетевую папку — иначе резервирование упадёт с той же ошибкой нехватки места.

Очистка журнала транзакций MS SQL Server для 1С

Логическое имя файла журнала понадобится для сжатия. Оно не совпадает с именем файла на диске:

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

Строка с type_desc = LOG — нужный файл, например buh_log.

Способ 1. База в модели FULL, резервные копии журнала нужны

Этот способ сохраняет возможность восстановить базу на любой момент времени. Подходит, если у вас настроено полноценное резервирование.

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

BACKUP LOG [buh]
TO DISK = N'E:\Backup\buh_log_20261007.trn';

2. Проверьте, что журнал внутри освободился: DBCC SQLPERF(LOGSPACE) покажет низкий процент использования.
3. Сожмите файл до разумного размера. Второй параметр — целевой размер в мегабайтах:

USE [buh];
DBCC SHRINKFILE (N'buh_log', 2048);

Если файл почти не уменьшился, активная часть журнала оказалась в его конце. Повторите BACKUP LOG и DBCC SHRINKFILE ещё раз.

Способ 2. Восстановление на момент времени не нужно

Большинству небольших компаний хватает ежедневной полной копии базы. Тогда модель FULL не нужна вовсе, и журнал проще перевести в режим, где он очищается сам.

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

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

Через SQL Server Management Studio

Если команды писать не хочется, то же самое делается мышью:

1. В обозревателе объектов щёлкните по базе правой кнопкой → Свойства → страница Параметры → поле «Модель восстановления». Здесь меняют Полная на Простая.
2. Снова правой кнопкой по базе → Задачи → Сжать → Файлы.
3. В поле «Тип файла» выберите Журнал, отметьте сжатие до заданного размера и укажите число в мегабайтах.

В английской версии SSMS это Tasks → Shrink → Files, тип файла Log.

Сравнение способов

Старый приём BACKUP LOG ... WITH TRUNCATE_ONLY из статей десятилетней давности не работает : его убрали в SQL Server 2008.

Если растёт ERRORLOG

Текстовый журнал ошибок SQL Server лежит в папке Log экземпляра. Раздувается он, когда сервер долго не перезапускается или пишет одну и ту же ошибку. Начать новый файл без перезапуска службы можно так:

EXEC sp_cycle_errorlog;

Число хранимых архивных файлов задают в SSMS: Управление → правой кнопкой по «Журналы SQL Server» → Настроить.

Очистка журналов PostgreSQL для 1С

У PostgreSQL нет файла журнала, который можно «сжать». Журнал предзаписи (WAL) лежит в каталоге pg_wal (до версии 10 он назывался pg_xlog) и состоит из сегментов по 16 МБ. Ненужные сегменты сервер удаляет или переиспользует сам после контрольной точки.

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

Если pg_wal вырос до десятков гигабайт, сервер держит сегменты по одной из причин.

Сломанное архивирование WAL

Если в postgresql.conf включён archive_mode = on, сегмент удаляется только после успешного выполнения archive_command. Сетевая папка недоступна — сегменты копятся. Проверка:

SELECT archived_count, failed_count,
       last_failed_wal, last_failed_time
FROM pg_stat_archiver;

Растущий failed_count и свежая last_failed_time — ваш случай. Почините путь или права в archive_command и перечитайте конфигурацию через SELECT pg_reload_conf();. Сегменты уйдут в архив, и pg_wal очистится.

Сам каталог архива WAL тоже растёт. Старые файлы из него, которые уже не нужны после свежей полной копии, удаляют утилитой pg_archivecleanup, а не вручную по дате.

Брошенный слот репликации

Слот репликации заставляет сервер хранить WAL, пока реплика его не заберёт. Реплику выключили, а слот остался — сегменты копятся без ограничения.

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

Слот с active = f и большим значением retained больше не нужен — удалите его:

SELECT pg_drop_replication_slot('old_replica');

Слишком щедрые настройки

Параметры max_wal_size и wal_keep_size (в старых версиях wal_keep_segments) задают, сколько WAL сервер держит намеренно. Если там стоят сотни гигабайт, уменьшите их до размера, который диск выдерживает с запасом.

После исправления причины выполните CHECKPOINT; от суперпользователя. Лишние сегменты будут удалены при этой или следующей контрольной точке.

Текстовые журналы сервера PostgreSQL

Журнал ошибок и медленных запросов при logging_collector = on пишется в каталог из параметра log_directory, по умолчанию log внутри каталога данных. В пакетах для Linux журналы часто лежат в /var/log/postgresql. Эти файлы можно удалять — сервер их не читает.

Чтобы не чистить их руками, включите ротацию:

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

С такими настройками хранится неделя файлов по дням недели, каждый перезаписывается через семь дней. Частая причина раздутого журнала в базах 1С — log_min_duration_statement = 0, который пишет каждый запрос. Для постоянной работы ставьте порог в секундах, например 5s.

Журналы на стороне 1С: журнал регистрации и технологический журнал

Иногда «лог SQL» на деле оказывается журналом самой 1С.

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

В клиент-серверном варианте он лежит на сервере 1С в каталоге srvinfo\reg_1541\<GUID базы>\1Cv8Log, в файловом — в папке 1Cv8Log внутри каталога базы. Журнал за несколько лет у активной базы занимает десятки гигабайт.

Правильный способ уменьшить журнал регистрации:

1. Откройте базу в конфигураторе.
2. Меню Администрирование → Журнал регистрации.
3. В открывшемся окне выберите команду сокращения журнала (Действия → Сократить).
4. Укажите дату, до которой удалить записи, и при необходимости путь для сохранения удалённой части в файл.

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

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

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

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1c_techlog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

Когда расследование закончено, удалите logcfg.xml или переименуйте его. Платформа перечитывает файл примерно раз в минуту, перезапуск службы не нужен.

Как настроить автоматическую очистку логов

Разовая чистка решает проблему на месяц. Чтобы журнал не возвращался, настройте регламент под выбранную модель.

MS SQL в модели FULL. В SSMS создайте план обслуживания: Управление → Планы обслуживания → Мастер планов обслуживания. Добавьте задачу «Резервное копирование базы данных (журнал транзакций)» каждые 30–60 минут и задачу «Очистка после обслуживания», которая удаляет файлы .trn старше 7–14 дней. План выполняет агент SQL Server — служба SQL Server Agent должна работать и запускаться автоматически.

MS SQL в модели SIMPLE. Регулярно сжимать журнал не нужно — это лишняя нагрузка. Достаточно один раз задать начальный размер с запасом и шаг роста в мегабайтах, а не в процентах.

PostgreSQL. Настройте ротацию текстовых журналов параметрами из раздела выше. Для WAL поставьте мониторинг: запрос к pg_stat_archiver и pg_replication_slots раз в час с уведомлением, если failed_count растёт или слот неактивен.

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

Ошибки при очистке журнала, которые дорого обходятся

• 🗑️ Удаление .ldf при отключённой базе. Совет «отсоедините базу, удалите журнал и присоедините с созданием нового» иногда срабатывает. Но если в журнале были незавершённые транзакции, база окажется в статусе SUSPECT или с нарушенной целостностью.
• 🔄 Ежедневный SHRINKFILE в плане обслуживания. Журнал сжимается ночью, днём снова растёт, файл фрагментируется. Сжимают только после разового аномального роста.
• 🧹 Сжатие файла данных .mdf «заодно». DBCC SHRINKDATABASE и сжатие файла данных сильно фрагментируют индексы. Отчёты в 1С начинают формироваться медленнее. Сжимайте только журнал.
• 🔀 Переключение FULL → SIMPLE → FULL ради чистки. После возврата в FULL без новой полной копии журнал всё равно не освобождается копиями, а восстановление на момент времени невозможно.
• 🐘 Удаление сегментов из pg_wal по дате. Самая разрушительная ошибка из списка. Только через устранение причины и CHECKPOINT.

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