Как сделать базу 1С меньше: пошаговое руководство

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

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

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

Почему база 1С разрастается

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

Третий источник — данные, которые формально удалены, но физически остались: помеченные документы, старые версии объектов при включённом версионировании, результаты обменов, история синхронизаций, служебные таблицы полнотекстового поиска. Наконец, сам файл базы (1Cv8.1CD или файлы .mdf в SQL Server) не уменьшается сам по себе: удалённые записи лишь помечаются как свободное место внутри файла.

Шаг 1. Удалите помеченные объекты и мусор

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

Удаление бывает выборочным или полным. Полное быстрее, но выборочное безопаснее: можно оставить объекты, на которые ссылаются действующие документы. Если система сообщает, что объект удалить нельзя из-за ссылок, не обходите это принудительно — разберитесь, кто на него ссылается, иначе получите битые ссылки вида «Объект не найден».

Дополнительно проверьте служебные данные: историю обменов (регистрацию изменений по уже неиспользуемым узлам планов обмена), очереди сообщений, устаревшие сеансы обмена данными. Очистка регистрации изменений по неиспользуемым узлам иногда освобождает заметный объём в базах с активной синхронизацией.

Шаг 2. Сократите журнал регистрации

Журнал регистрации хранится отдельно от основных данных (в файловой базе — в папке 1Cv8Log внутри каталога базы, в клиент-серверной — на сервере), но напрямую влияет на скорость работы и объём бэкапов каталога. Откройте в конфигураторе «Администрирование» → «Журнал регистрации» → «Сократить» и укажите дату, до которой удалить события.

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

Шаг 3. Разберитесь с присоединёнными файлами

Если в конфигурации ведётся хранение файлов (договоры, акты, изображения номенклатуры), проверьте, где они лежат. Хранение внутри базы удобно для бэкапов, но быстро раздувает файл. Альтернатива — тома хранения файлов: файлы выносятся на диск или сетевое хранилище, а в базе остаются только ссылки. В типовых конфигурациях это настраивается в разделе «Администрирование» → «Файлы».

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

Отдельно проверьте версионирование файлов и объектов: если включено хранение всех версий без ограничения срока, задайте срок хранения, например, 6–12 месяцев, и очистите старые версии.

Шаг 4. Свёртка базы: когда она нужна

Удаление и чистка освобождают место от мусора, но многолетняя история документов остаётся. Если актуальная работа ведётся только в последних 1–2 годах, а старые периоды нужны лишь для справок, применяется свёртка: обработка формирует документы ввода остатков на дату свёртки и удаляет все документы раньше этой даты.

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

Шаг 5. Физическое сжатие базы

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

Файловая база (1Cv8.1CD)

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

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

Клиент-серверная база (MS SQL, PostgreSQL)

В клиент-серверном варианте сжатие делается средствами СУБД. Для MS SQL Server это операции SHRINKDATABASE/SHRINKFILE или перестроение индексов (ALTER INDEX REBUILD), для PostgreSQL — VACUUM FULL или pg_repack. Важно понимать: регулярный SHRINK в SQL Server считается вредной практикой, так как фрагментирует индексы; его делают разово после массового удаления, а затем перестраивают индексы.

1. 1
   Сделайте резервную копию (выгрузка .dt или бэкап СУБД)
2. 2
   Удалите помеченные объекты, очистите версии и регистрацию изменений по неиспользуемым узлам
3. 3
   Сократите журнал регистрации до разумного срока
4. 4
   При необходимости выполните свёртку (сначала в копии, с проверкой остатков)
5. 5
   Выполните сжатие: Тестирование и исправление для файловой базы или shrink/rebuild на уровне СУБД
6. 6
   Сравните размер файлов до и после, проверьте работоспособность ключевых отчётов

Как проверить результат и не допустить повторного роста

Контролируйте результат по двум параметрам: физический размер файлов (1Cv8.1CD, .mdf/.ldf или каталог PostgreSQL) и работоспособность. После сжатия откройте основные отчёты — оборотно-сальдовую ведомость, остатки склада, взаиморасчёты — и сверьте итоги с копией. Проверьте также, что открываются типовые документы и проходят обмены.

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

Контрольные точки

Как проверить результат

Размер файла базы

Норма

Файл заметно меньше исходного после сжатия

Тревожный признак

Размер не изменился — удалённые данные остались внутри файла, сжатие не выполнено

Остатки по отчётам

Норма

ОСВ и остатки склада совпадают с копией

Тревожный признак

Расхождения — проверяйте свёртку и удалённые объекты

Обмены и фоновые задания

Норма

Синхронизации проходят без ошибок

Тревожный признак

Ошибки ссылок на удалённые объекты — восстановите из копии и повторите аккуратнее

Часто задаваемые вопросы

Удалил документы, но файл базы не уменьшился. Почему?

Удалённые записи лишь помечаются как свободное место внутри файла. Чтобы вернуть место диску, выполните сжатие: «Тестирование и исправление» с пунктом «Сжатие таблиц» для файловой базы или shrink на уровне СУБД для клиент-серверной.

Можно ли уменьшить базу без монопольного режима?

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

Что безопаснее: свёртка или перенос остатков в новую базу?

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

Опасно ли делать shrink базы в SQL Server?

Разовый shrink после массового удаления данных допустим, но он сильно фрагментирует индексы — сразу после него выполните перестроение индексов. Делать shrink регулярно по расписанию не рекомендуется: файл будет снова расти, а производительность деградирует.

Как часто нужно чистить базу?

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