Почему база 1С весит много и что с этим делать

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

Понимание, что именно «съедает» место, важно ещё и потому, что методы борьбы разные. Удаление старых документов не поможет, если 60% объёма занимают сканы договоров, а очистка журнала регистрации бесполезна, если раздуты итоги по регистрам накопления. Ниже разберём основные источники роста, способы диагностики и безопасные методы уменьшения базы.

Отдельно учитывайте формат работы. В файловой базе весь объём виден напрямую — это размер файла 1Cv8.1CD. В клиент-серверном варианте (MS SQL, PostgreSQL) размер данных и размер файлов СУБД могут заметно отличаться: освобождённое место внутри базы не всегда возвращается операционной системе без дополнительных действий.

Из чего на самом деле состоит объём базы

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

Ещё один скрытый потребитель места — «пустое пространство» внутри файла. При удалении объектов физическое место в файловой базе не освобождается автоматически: страницы помечаются свободными и переиспользуются позже. Поэтому файл может весить 20 ГБ, хотя реальных данных в нём на 12 ГБ. В клиент-серверном варианте аналогичная ситуация возникает с файлами СУБД и журналом транзакций.

Основные причины большого размера базы

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

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

Присоединенные файлы и хранилища

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

Регистры, итоги и индексы

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

Как выяснить, что именно занимает место

Первый шаг — получить карту размеров таблиц. Для файловой базы используются внешние обработки анализа структуры хранения: они показывают, сколько места занимает каждая таблица в терминах конфигурации (документы, регистры, журналы). Для клиент-серверной базы в MS SQL аналогичную информацию дают стандартные отчёты Management Studio «Disk Usage by Table» или запросы к системным представлениям.

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

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

Безопасные способы уменьшить размер базы

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

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

Для файловой базы сжатие выполняется через конфигуратор: «Администрирование → Тестирование и исправление» с установленным флагом «Сжатие таблиц информационной базы». Это перестраивает файл и возвращает неиспользуемое место. Для MS SQL после массового удаления данных применяют shrink файлов данных и настраивают модель восстановления, чтобы журнал транзакций не разрастался.

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

Свёртка базы и архивация старых периодов

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

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

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

Сравнение вариантов

Точечная очистка (журнал, файлы, помеченные)

Подходит при умеренном росте. Быстро и безопасно, но не решает проблему многолетнего объёма документов

Свёртка базы

Для баз с историей за много лет. Радикально уменьшает объём, но требует тщательной проверки остатков и тестирования

Архивная копия + чистая рабочая база

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

Перенос файлов в тома

Когда основной объём — присоединенные файлы. Не уменьшает общий занимаемый диск, но разгружает саму базу

Профилактика: как не дать базе разрастись снова

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

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

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

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

Почему после удаления документов размер файла базы не уменьшился?

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

Можно ли просто удалить старый журнал регистрации?

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

Что безопаснее: свёртка базы или создание новой базы с вводом остатков?

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

Как понять, что база выросла из-за присоединенных файлов?

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

Опасно ли делать сжатие базы при работающих пользователях?

Да. Тестирование и исправление со сжатием требует монопольного доступа к файловой базе, а shrink в СУБД сильно нагружает дисковую подсистему и замедляет работу. Планируйте такие операции на нерабочее время и всегда после резервного копирования.

База весит 50 ГБ — это много и пора ли что-то делать?

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