Ситуация, когда база данных 1С внезапно увеличивается в объеме в несколько раз (например, с 20 Гб до 60 Гб) и при этом категорически отказывается сжиматься стандартными средствами SQL Server Management Studio (SSMS), является довольно распространенной. Особенно часто это происходит после миграции базы между серверами или после выполнения массовых операций с данными. Рассмотрим подробно, почему это происходит и какими методами можно вернуть базе нормальный размер.
Прежде чем приступать к активным действиям по сжатию, проанализируем ситуацию. Если выгрузка базы в формат .dt и последующая загрузка в новую пустую базу не меняют размер файла .mdf, значит, проблема не в «дырках» (пустых страницах) внутри файла, а в том, что 1С считает эти данные полезными (в этом случае поможет универсальное сжатие базы). Выясним, что именно занимает место в базе.
Разберем основные шаги по диагностике, используя отчеты, показывающие размер базы 1С:
_InfoReg... (регистры сведений) или _AccumReg... (регистры накопления), значит, в базу действительно записано много данных. Если лидируют системные таблицы Config или Files, проблема в раздутом кэше конфигурации или истории расширений.Data Space и сколько из него реально свободно.Рассмотрим парадоксальный, но эффективный метод, который помогает в случаях, когда SQL Server «зацикливается» на текущем распределении страниц. Суть метода заключается в том, чтобы сначала вручную увеличить логический размер файла до значения, превышающего текущий физический размер, а затем запустить процедуру SHRINKFILE с параметром 0.
Выполним следующие шаги в окне запросов SQL:
Сначала определим логическое имя файла базы (это не путь к файлу, а имя внутри SQL). Обычно оно совпадает с именем базы, но лучше проверить в свойствах. Далее выполним скрипт:
-- Устанавливаем размер файла чуть больше текущего (например, до 70 Гб, если база 60 Гб)
ALTER DATABASE [ИмяВашейБазы]
MODIFY FILE ( NAME = 'Логическое_Имя_Файла' , SIZE = 70000 MB );
GO
-- Сразу после этого выполняем сжатие до минимально возможного размера
DBCC SHRINKFILE (N'Логическое_Имя_Файла' , 0);
GO
Этот алгоритм заставляет SQL Server пересчитать карту распределения страниц (IAM) и часто позволяет «сдвинуть» процесс сжатия с мертвой точки.
Если один файл базы данных поврежден на логическом уровне или сильно фрагментирован в части LOB-данных (хранилищ значений), проанализируем вариант с добавлением второго файла в ту же файловую группу. Рассмотрим пошагово, как это сделать:
PRIMARY).Этот метод считается радикальным, так как он фактически пересобирает базу на физическом уровне, исключая влияние фрагментированных цепочек страниц в старом файле.
В 1С многие данные (картинки, файлы, версии конфигураций) хранятся в полях типа VARBINARY(MAX) или NTEXT. Обычный REBUILD индекса может не освобождать место, которое было зарезервировано под эти объекты. Выясним, поможет ли нам принудительное сжатие больших объектов.
Рассмотрим команду для реорганизации индексов с параметром сжатия LOB:
-- Применяем ко всем индексам таблицы, которая занимает больше всего места
ALTER INDEX ALL ON [Имя_Таблицы_1С]
REORGANIZE WITH (LOB_COMPACTION = ON);
GO
Важно: В отличие от REBUILD, команда REORGANIZE выполняется в режиме онлайн и не блокирует таблицу целиком, но требует больше времени для завершения. Она эффективно «схлопывает» пустое место внутри страниц, занятых двоичными данными.
Иногда место не освобождается из-за того, что транзакционный лог или механизмы обеспечения целостности (например, ADR — Accelerated Database Recovery в SQL 2019+) держат старые версии строк. Проанализируем алгоритм переключения режима восстановления:
DBCC SHRINKDATABASE или DBCC SHRINKFILE.Также стоит проверить наличие зависших транзакций, которые мешают очистке Ghost Records (записей-призраков). Посмотрим на результат выполнения команды:
DBCC OPENTRAN;
Если команда показывает транзакцию, которая висит уже несколько дней, ее необходимо завершить (или «убить» процесс через KILL), иначе SQL не сможет физически удалить помеченные к удалению данные из файла.
Если после всех манипуляций в SQL база все еще огромная, а .dt тоже получается подозрительно большим, разберем ситуацию внутри 1С. Часто причиной является таблица Files, где хранятся временные данные обновлений. Попробуем очистить ее средствами самой платформы:
Это пересоберет внутренние таблицы 1С и удалит помеченные на удаление объекты, которые могли попасть в файл выгрузки .dt.
Проанализировав все способы, мы видим, что решение проблемы «неудаляемого» места часто лежит в плоскости принудительного изменения структуры файла или очистки специфических типов данных (LOB). Помните, что любые операции с SHRINK вызывают сильную фрагментацию индексов. После успешного сжатия файла обязательно выполните REBUILD всех индексов, чтобы восстановить производительность системы.