Чистка и сжатие информационной базы 1С 8.3

База разрослась до десятков гигабайт, файловая версия тормозит, а резервная копия уже не влезает на флешку? Объём сокращают в три приёма: удаляют помеченные на удаление объекты, обрезают журнал регистрации и физически сжимают таблицы через «Тестирование и исправление». Для файловой базы этого хватает почти всегда; для клиент-серверной добавляется работа с самой СУБД — журналом транзакций и сжатием на уровне SQL Server или PostgreSQL.

Начните с безопасного и обратимого — чистки журнала и удаления помеченных записей. Физическое сжатие файла 1Cv8.1CD делайте последним шагом и только из резервной копии: операция требует монопольного доступа и выключает всех пользователей из базы.

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

Почему информационная база растёт

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

Основные причины разбухания:

• 🗑️ Помеченные на удаление объекты. Документы и справочники с пометкой физически остаются в таблицах, пока их не удалит специальная обработка. За годы работы их накапливаются десятки тысяч.
• 📓 Журнал регистрации. Пишет каждое действие каждого пользователя: вход, проведение, изменение настроек. В активной базе за год журнал легко набирает несколько гигабайт.
• 🖼️ Присоединённые файлы. Сканы, договоры и картинки, которые хранятся внутри базы, а не в отдельном томе на диске.
• 📊 Регистры и временные данные. Остатки расчётов, записи регистров сведений, которые дублируют уже неактуальные периоды.
• 🧩 Фрагментация таблиц. После массовых удалений место в файле освобождается внутри, но сам файл не уменьшается — внутри остаются «дыры».

Удаление помеченных на удаление объектов

Это первый и самый безопасный способ сократить базу. Обработка проверяет, что на удаляемый объект никто не ссылается, и только потом физически стирает запись.

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

• 1С:Бухгалтерия 3.0, ЗУП 3.1: Администрирование → Обслуживание → Удаление помеченных объектов.
• 1С:Управление торговлей 11, ERP: НСИ и администрирование → Сервис → Удаление помеченных объектов (в части релизов пункт лежит в разделе Администрирование).

Порядок действий:

1. Закройте документы и справочники, которые собираетесь удалить, — пометьте их на удаление (клавиша Delete или команда в списке).
2. Откройте обработку и выберите режим «Автоматическое» — программа сама найдёт все помеченные объекты.
3. Дождитесь контроля ссылок. Если на объект ссылается другой документ, 1С покажет его в списке — удаление по такой записи не пройдёт.
4. Снимите пометку или удалите мешающие ссылки, затем повторите.

Удалённые таким образом объекты восстановить штатными средствами нельзя — только из резервной копии. Перед массовым удалением сделайте бэкап.

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

Как обрезать журнал регистрации

Журнал регистрации — частый скрытый пожиратель места. Он не влияет на учётные данные, поэтому его можно смело сокращать.

С платформы 8.3.5 журнал по умолчанию хранится в одном файле 1Cv8.lgd формата SQLite (в каталоге базы). В более старых базах встречается папка 1Cv8Log с множеством мелких файлов.

Сокращение из Конфигуратора:

1. Откройте базу в Конфигураторе.
2. Меню Администрирование → Настройка журнала регистрации.
3. В поле выбора даты укажите, записи до какой даты удалить, и нажмите сокращение. Можно предварительно выгрузить старые записи в файл, если история нужна для аудита.

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

После обрезки файл 1Cv8.lgd уменьшается сразу — отдельного сжатия журналу не требуется.

Физическое сжатие таблиц информационной базы

Это тот самый шаг, который реально уменьшает файл на диске. Выполняется в Конфигураторе через встроенный инструмент обслуживания.

Путь: Администрирование → Тестирование и исправление. В открывшемся окне:

• включите флаг «Сжатие таблиц информационной базы»;
• при сильной фрагментации добавьте «Реструктуризация таблиц информационной базы»;
• в блоке проверок режим можно оставить «только тестирование» выключенным, чтобы изменения применились.

Нажмите «Выполнить». Платформа пересоберёт таблицы, вернув в файловой базе освободившееся после удалений место.

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

Обязательные условия перед запуском:

1. Сделайте резервную копию (выгрузку .dt или копию файла 1Cv8.1CD).
2. Убедитесь, что из базы вышли все пользователи.
3. Запаситесь свободным местом на диске — во время реструктуризации платформе нужно временное пространство, сравнимое с размером базы.

Для файловой базы есть ещё утилита проверки физической целостности chdbfl.exe (лежит в каталоге bin установленной платформы). Она находит и чинит нарушения структуры файла, но её задача — целостность, а не сжатие; для уменьшения объёма используйте именно «Тестирование и исправление».

Чем отличается чистка файловой и серверной базы

Способы частично общие, но клиент-серверный вариант добавляет работу с самой СУБД. Разница — в таблице.

Главная засада клиент-серверной базы — журнал транзакций. На Microsoft SQL Server при модели восстановления «Полная» (Full) лог растёт, пока его не забэкапят, и может превысить саму базу в разы.

Что с этим делают:

• Настраивают регулярное резервное копирование журнала транзакций (backup log) — после бэкапа место в логе переиспользуется.
• Для баз, где достаточно ночного бэкапа, переключают модель восстановления на «Простая» (Simple) — тогда лог не копит транзакции. Решение согласуйте с теми, кто отвечает за восстановление: при простой модели нельзя откатиться на произвольный момент времени.

Физическое сжатие на стороне СУБД (команда DBCC SHRINKFILE в SQL Server, VACUUM FULL в PostgreSQL) возвращает место операционной системе. Это тяжёлая операция, которая блокирует таблицы и усиливает фрагментацию индексов, поэтому её делают разово после крупной чистки, а не по расписанию, и обязательно силами администратора СУБД. После shrink индексы обычно перестраивают заново — иначе выигрыш в размере обернётся замедлением выборок.

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

Автоматическая чистка через регламентные задания

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

Что имеет смысл автоматизировать:

• Удаление помеченных объектов. В типовых конфигурациях есть регламентное задание или настройка автоматического удаления по расписанию: Администрирование → Обслуживание → Удаление помеченных объектов → Настроить расписание.
• Сокращение журнала регистрации. Настраивается глубина хранения — старые записи обрезаются автоматически по заданному периоду.
• Резервное копирование журнала транзакций (для SQL) — задание на стороне СУБД, а не 1С.

Настройка расписания в режиме «Предприятие»:

1. Откройте форму регламентных заданий — в большинстве типовых это Администрирование → Обслуживание или через раздел поддержки.
2. Выберите нужное задание и откройте его расписание.
3. Поставьте запуск на ночь или выходные, когда база свободна.

Физическое сжатие таблиц (Тестирование и исправление) на расписание не ставят — оно требует монопольного доступа и ручного контроля.

Что ещё помогает держать базу компактной

Когда основные приёмы отработаны, остаются точечные меры — особенно для баз с большим объёмом вложений и историей.

• 📎 Вынесите присоединённые файлы в тома на диске. В типовых конфигурациях хранилище файлов настраивается так, чтобы сканы и документы лежали в каталоге на сервере, а не внутри базы: Администрирование → Настройки работы с файлами → Тома хранения файлов. Базу это облегчает радикально.
• 📤 Перенесите уже накопленные вложения. Если файлы годами копились внутри базы, одной настройки томов мало — она действует только на новые. Для переноса ранее сохранённых файлов в тома в типовых конфигурациях есть отдельная обработка; найдите её в том же разделе настроек работы с файлами и запустите после того, как тома созданы.
• 🗂️ Свёртка базы. Если учёт ведётся много лет, старые периоды сворачивают: обороты закрываются, остаются только входящие остатки на начало периода. Это уменьшает число проводок и записей регистров — а значит, и размер таблиц. Свёртку выполняет штатная обработка «Свёртка информационной базы»; делают её строго из резервной копии, только после того как закрыты все периоды и сданы отчёты, потому что операция необратима и затрагивает учётные данные.
• 🔄 Регулярная дефрагментация индексов (для SQL) силами администратора СУБД — ускоряет работу и косвенно экономит место.
• 🧹 Чистка устаревших настроек и временных данных через штатные обработки обслуживания конфигурации.

Если после всех чисток база всё равно огромна и тормозит, причина обычно не в «мусоре», а в объёме рабочих данных и слабом железе. Тогда помогает уже не чистка, а перевод на клиент-серверный вариант и оптимизация СУБД.

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