Ситуация, когда после удаления значительного объема документов (например, 3/4 базы) размер файла выгрузки .dt или самого файла базы данных остается прежним, является классической проблемой для администраторов и разработчиков 1С. На первый взгляд это кажется нелогичным: данных стало меньше, а занимаемое место не изменилось. В этой статье мы подробно разберем внутренние механизмы платформы «1С:Предприятие 8.3», работу MS SQL Server и файловой СУБД, чтобы понять, как эффективно управлять объемом данных.
Для начала разберем, что представляет собой файл .dt. Это не физическая копия базы данных, а логическая выгрузка. Процесс создания .dt можно сравнить с последовательным чтением всех таблиц базы и упаковкой их содержимого в специализированный архив. Рассмотрим, почему его размер может не меняться после удаления объектов.
Во-первых, проанализируем объем метаданных. В любой конфигурации 1С существует так называемый «неснижаемый остаток». Сюда входят описания таблиц, экранные формы, макеты, картинки интерфейса и сама логика программы (код модулей). В современных решениях этот объем может достигать нескольких сотен мегабайт. Если ваша база «самописная» и содержит много тяжелых макетов или картинок в самой конфигурации, размер .dt будет значительным даже при абсолютно пустых таблицах документов.
Во-вторых, важно понимать алгоритм сжатия. Платформа 1С при выгрузке в .dt автоматически применяет мощные алгоритмы сжатия. Рассмотрим ситуацию: у вас в базе хранились сканы документов (PDF или JPEG). Эти форматы уже сжаты. Попытка сжать их повторно при выгрузке в .dt практически не дает эффекта. Более того, если вы программно сжали данные внутри ХранилищаЗначений, используя метод СжатиеДанных(9), а затем запустили выгрузку, размер файла может даже незначительно вырасти из-за добавления служебных заголовков архивации к каждому объекту. Это эффект «архива в архиве».
Если ваша база работает в клиент-серверном варианте под управлением MS SQL Server, простое удаление строк из таблиц (через Удалить() или даже прямой DELETE) никогда не приведет к мгновенному уменьшению файла .mdf на диске. Выясним причину такого поведения.
SQL Server резервирует место под будущие операции. Когда вы удаляете 75% документов, записи помечаются как Ghost Records (призрачные записи). Они физически остаются на страницах данных, но помечаются как удаленные, чтобы не блокировать работу других пользователей. Специальный фоновый процесс Ghost Cleanup со временем очистит их, но место в файле базы данных останется зарезервированным за этой базой.
Проанализируем ситуацию с помощью инструментов управления. Чтобы увидеть реальное положение дел, выполните следующие шаги:
Если Space Available составляет значительную часть от общего размера, значит, удаление прошло успешно, но SQL Server просто не отдал это место операционной системе. Чтобы физически уменьшить файл, необходимо выполнить операцию Shrink (Сжатие), однако для постоянной работы это не рекомендуется из-за последующей фрагментации индексов.
Часто основной объем базы занимают не текстовые данные документов, а прикрепленные файлы, хранящиеся в реквизитах с типом ХранилищеЗначений. Посмотрим на примере, как правильно обрабатывать такие данные. Если вы решили сжать их программно, рассмотрите следующий алгоритм работы:
// Извлечение и пережатие данных для экономии места
ДвоичныеДанныеФайла = Объект.РеквизитХранилище.Получить();
Если ТипЗнч(ДвоичныеДанныеФайла) = Тип("ДвоичныеДанные") Тогда
СжатыеДанные = Новый СжатиеДанных(9);
// Помещаем обратно с максимальной степенью сжатия
Объект.РеквизитХранилище = Новый ХранилищеЗначений(ДвоичныеДанныеФайла, СжатыеДанные);
Объект.Записать();
КонецЕсли;
Однако помните: если платформа при выгрузке в .dt видит, что данные в ХранилищеЗначений уже сжаты, она не сможет упаковать их сильнее. Поэтому размер .dt после такой обработки может не измениться. Реальный эффект вы увидите только в размере таблиц внутри SQL или файловой базы.
В файловом варианте работы 1С данные хранятся в одном файле .1cd. Структура этого файла такова, что при удалении записей страницы данных просто помечаются как «свободные» и помещаются в специальный список. При создании новых записей 1С в первую очередь будет использовать эти свободные страницы, и только если их не хватит, файл начнет расти дальше.
Чтобы физически «схлопнуть» файл .1cd и удалить из него пустые страницы, необходимо запустить Тестирование и исправление с установленной галочкой «Сжатие таблиц информационной базы». Если после этой процедуры размер файла не изменился, проанализируем возможные причины:
_InfoRg...). Пока вы не очистите историю версий, база не уменьшится.Разберем, как точно определить, «куда уходит место». Для этого нам нужно проанализировать размер каждой таблицы в базе данных. Для этой задачи можно использовать инструмент для анализа распределения объёма базы по внутренним таблицам.
Для SQL-версии: в SSMS воспользуйтесь стандартным отчетом: нажмите правой кнопкой на базу -> Reports -> Standard Reports -> Disk Usage by Top Tables. Вы увидите список таблиц, отсортированный по размеру. Ищите таблицы с именами типа _Document123 (данные документов) или _InfoRg456 (регистры). Если после удаления документов в топе висят таблицы _InfoRg, значит, место занимают движения или доп. сведения.
Для файловой версии: воспользуйтесь специализированными утилитами для анализа структуры .1cd (например, Tool1CD). Они позволяют увидеть размер каждой внутренней таблицы и количество записей в них. Это поможет выяснить, что именно не «ужалось».
Выясним причину, почему .dt может даже увеличиться после программного сжатия файлов в базе. Платформа 1С использует свои заголовки для сжатых данных. Если в базе тысячи маленьких файлов по 1-2 КБ, то добавление служебной информации о сжатии к каждому такому файлу может суммарно занять больше места, чем экономия от самого сжатия.
Подводя итог, проанализируем основные тезисы:
Shrink в SQL или Сжатие таблиц в ТиИ для файловой базы.Рассмотренные механизмы показывают, что управление размером базы — это комплексная задача, требующая понимания структуры хранения данных 1С. Если ваша цель — максимально компактное хранение, рассмотрите вариант выноса файлов из базы в тома хранения в файловой системе. Это позволит держать базу данных (и файл .dt) в минимальном размере, оставив тяжелые данные за ее пределами.