Чистим журнал регистрации, журнал транзакций и разросшиеся таблицы базы 1С на SQL

Чтобы почистить логи 1С на SQL, сначала определите, что именно выросло. Журнал регистрации 1С сокращают в конфигураторе: Администрирование → Настройка журнала регистрации → Сократить. Разросшийся файл журнала транзакций MS SQL (.ldf) уменьшают командой DBCC SHRINKFILE после резервной копии журнала или перевода базы в простую модель восстановления. Таблицы версий объектов и истории данных чистят средствами самой конфигурации, а прямой DELETE в SQL оставляют на крайний случай.

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

1. Находим, что занимает место: замер журналов и таблиц

Не начинайте чистку вслепую. За пять минут можно понять, куда ушли гигабайты.

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

Журнал каждой базы лежит в каталоге кластера: <каталог srvinfo>\reg_1541\<GUID базы>\1Cv8Log. На Windows по умолчанию это C:\Program Files\1cv8\srvinfo\reg_1541\. GUID базы виден в консоли администрирования серверов 1С в свойствах информационной базы или по дате изменения папок.

Форматы файлов:

• 📄 .lgf + .lgp — последовательный формат, по файлу на период;
• 🗃 1Cv8.lgd — формат SQLite, один файл на всю базу.

Если в папке файл .lgd на 30 ГБ — проблема именно в журнале регистрации, и SQL Server тут ни при чём.

Размер файлов базы в MS SQL

Откройте SQL Server Management Studio и выполните запрос в контексте нужной базы:

-- размер файлов данных и журнала, МБ
SELECT name, type_desc, size * 8 / 1024 AS size_mb
FROM sys.database_files;

-- сколько занято в журнале транзакций по всем базам
DBCC SQLPERF(LOGSPACE);

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

Значение LOG_BACKUP в колонке log_reuse_wait_desc значит: база в полной модели восстановления, а резервные копии журнала никто не делает. Это самая частая причина файла .ldf размером больше самой базы.

Самые большие таблицы

SELECT TOP 20
    t.name AS table_name,
    SUM(p.row_count) AS rows_cnt,
    SUM(p.reserved_page_count) * 8 / 1024 AS reserved_mb
FROM sys.dm_db_partition_stats p
JOIN sys.tables t ON t.object_id = p.object_id
GROUP BY t.name
ORDER BY reserved_mb DESC;

Имена вида _InfoRg1234 или _DataHistoryVersions ничего не скажут бухгалтеру. Чтобы понять, какой объект 1С стоит за таблицей, выполните в 1С (например, в консоли запросов или внешней обработке) метод ПолучитьСтруктуруХраненияБазыДанных(). Он вернёт соответствие метаданных и имён таблиц СУБД.

💡 Таблицы _DataHistory... относятся к механизму истории данных платформы, _UsersWorkHistory — к истории работы пользователей. Регистр «Версии объектов» из БСП выглядит как обычная таблица _InfoRg с большим числом.

2. Подготовка: копии, окно работ и пользователи

Очистка удаляет данные безвозвратно. Перед ней:

1. Сделайте полную резервную копию базы средствами SQL (BACKUP DATABASE), а не только выгрузку .dt.
2. Скопируйте папку 1Cv8Log нужной базы в архив.
3. Проверьте свободное место: перестройка индексов и сам бэкап требуют места на диске, иногда сопоставимого с размером крупнейшей таблицы.
4. Выберите окно работ — вечер или выходные.
5. Предупредите пользователей. Сжатие файлов и перестройка индексов замедляют работу базы, а для конфигуратора нужен вход под администратором.

Без проверенной резервной копии прямую очистку таблиц через SQL не запускайте.

3. Сокращение журнала регистрации средствами платформы

Это штатный и безопасный способ. Монопольный режим не нужен.

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

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

💡 Уровень «Все события» в рабочей базе с десятками пользователей раздувает журнал на гигабайты в месяц. Для повседневной работы обычно хватает уровня с ошибками и предупреждениями, а «все события» включают на время расследования.

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

Если журнал в формате SQLite (.lgd)

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

4. Очистка журнала транзакций MS SQL (.ldf)

Журнал транзакций нужен СУБД для отката и восстановления. Удалять файл .ldf вручную нельзя: база перестанет открываться.

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

Если вы восстанавливаетесь «на момент времени» и делаете бэкапы журнала, проблема в том, что они перестали выполняться. Порядок:

BACKUP LOG [buh] TO DISK = N'D:\Backup\buh_log.trn';
USE [buh];
DBCC SHRINKFILE (N'buh_log', 2048);  -- целевой размер в МБ

Логическое имя файла журнала (buh_log в примере) берите из запроса к sys.database_files в первом разделе. Затем восстановите задание резервного копирования журнала, иначе через месяц всё повторится.

Вариант Б: восстановление на момент времени не нужно

Для большинства баз малого и среднего бизнеса хватает ежедневного полного бэкапа. Тогда переводите базу в простую модель:

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

После этого журнал будет переиспользоваться сам, и без бэкапов журнала он не разрастётся.

💡 Не сжимайте журнал до 1 МБ. При следующей большой операции (закрытие месяца , обновление конфигурации ) он снова вырастет, а рост кусками тормозит базу. Оставьте запас, равный пиковому размеру за обычную неделю.

Если база на PostgreSQL

Аналога .ldf там нет, но растёт каталог WAL (pg_wal). Обычно причина — неработающая архивация WAL или забытый слот репликации. Файлы из pg_wal вручную не удаляют: проверьте настройки archive_command и список слотов в pg_replication_slots.

5. Очистка разросшихся таблиц 1С: сначала программой, потом SQL

Чаще всего базу раздувают три вещи: версии объектов, история данных и служебные регистры вроде протоколов обмена.

Версии объектов (БСП)

В БП 3.0, ЗУП 3.1, УТ 11 версионирование настраивается в разделе Администрирование → Общие настройки, блок «Версионирование объектов». В настройках задают срок хранения версий и запускают удаление устаревших. После удаления строки из регистра уходят, но место в файле данных SQL освобождается только для повторного использования.

История данных платформы

Если в конфигурации включена история данных для документов или справочников, таблицы _DataHistory... растут с каждым изменением. Отключите историю для объектов, где она не нужна, и удалите старые версии средствами конфигурации или обработкой, которая использует методы объекта ИсторияДанных.

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

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

<log location="D:\1C_TechLog" history="24">

После этого старые каталоги удаляются автоматически. Для разовой очистки удалите старые подкаталоги в папке location — это безопасно для базы. Если журнал больше не нужен, удалите блок <log> из logcfg.xml целиком.

Прямая очистка через SQL: когда и как

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

Порядок:

1. Остановите работу пользователей с базой и сеансы фоновых заданий. Активные сеансы оборвутся — делайте это в окно работ.
2. Точно определите таблицу через ПолучитьСтруктуруХраненияБазыДанных().
3. Удаляйте порциями, чтобы журнал транзакций не вырос на десятки гигабайт:

-- пример: удаление порциями по 50 000 строк
WHILE 1 = 1
BEGIN
    DELETE TOP (50000) FROM dbo._InfoRg1234
    WHERE _Period < '4024-01-01';   -- со смещением дат, см. ниже
    IF @@ROWCOUNT = 0 BREAK;
    CHECKPOINT;  -- в простой модели освобождает журнал
END;

4. После очистки запустите в конфигураторе Администрирование → Тестирование и исправление с проверкой логической целостности на тестовой копии.

Номер таблицы _InfoRg1234 в примере условный. У вас он свой, и колонка периода может называться иначе.

6. Автоочистка: регламентные задания и планы обслуживания

Разовая очистка без автоматики даёт эффект на 2–3 месяца.

План обслуживания создают в SSMS: Management → Maintenance Plans → Maintenance Plan Wizard. Мастер сам предложит задачи резервного копирования, проверки целостности, перестройки индексов и удаления старых файлов бэкапов. Для SQL Server Express агента нет — используйте планировщик Windows и sqlcmd со скриптом.

Состояние регламентных заданий 1С смотрите в Администрирование → Обслуживание → Регламентные и фоновые задания. Если задание удаления устаревших версий выключено или падает с ошибкой, версии копятся годами.

Для журнала регистрации в последовательном формате с разделением по дням можно настроить архивацию старых файлов .lgp скриптом. Файл текущего периода трогать нельзя — он открыт сервером.

# перенос файлов журнала старше 180 дней в архив
$log = "C:\Program Files\1cv8\srvinfo\reg_1541\<GUID>\1Cv8Log"
Get-ChildItem $log -Filter *.lgp |
  Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-180) } |
  Move-Item -Destination "E:\Archive\1Cv8Log"

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

7. Индексы и статистика после чистки

Массовое удаление оставляет индексы фрагментированными, а статистику устаревшей. Запросы 1С после этого могут работать медленнее, чем до чистки.

Проверка фрагментации крупных индексов:

SELECT OBJECT_NAME(ips.object_id) AS table_name,
       i.name AS index_name,
       ips.avg_fragmentation_in_percent,
       ips.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ips
JOIN sys.indexes i ON i.object_id = ips.object_id AND i.index_id = ips.index_id
WHERE ips.page_count > 1000
ORDER BY ips.avg_fragmentation_in_percent DESC;

Типовое правило администраторов: фрагментация 5–30% — REORGANIZE, больше 30% — REBUILD.

ALTER INDEX ALL ON dbo._InfoRg1234 REBUILD;
UPDATE STATISTICS dbo._InfoRg1234 WITH FULLSCAN;
-- или статистика по всей базе
EXEC sp_updatestats;

На PostgreSQL после массового удаления выполняют VACUUM ANALYZE для таблицы, а VACUUM FULL — только в окно работ: он блокирует таблицу на время перестройки.

Нужно ли сжимать файл данных

После удаления файл .mdf остаётся прежнего размера, место внутри просто помечено свободным. DBCC SHRINKFILE для файла данных сильно фрагментирует индексы. Сжимайте .mdf, только если диск действительно заканчивается, и после сжатия снова перестройте индексы.

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