Как правильно уменьшить размер базы 1С в MSSQL после обновления конфигурации

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

Почему база данных увеличивается после обновления

Проанализируем основные технические причины, приводящие к резкому увеличению дискового пространства базы данных при обновлении конфигурации:

1. Реструктуризация таблиц: Если в процессе обновления меняются типы данных, добавляются или удаляются реквизиты и измерения, платформа 1С создает временную копию изменяемой таблицы, переносит в нее данные, перестраивает индексы и удаляет старую таблицу. На время этой операции требуется как минимум двойной объем свободного места для каждой модифицируемой таблицы.
2. Рост журнала транзакций (файл .ldf): При установленной полной модели восстановления (Full Recovery Model) все операции массового переноса данных и перестроения индексов фиксируются в журнале. Без регулярного резервного копирования лога размер файла транзакций может превысить размер основных данных.
3. Хранение версий конфигурации поставщика: При обновлении нетиповых конфигураций таблицы метаданных Config, ConfigCAS и Params сохраняют новые версии конфигурации поставщика и основной конфигурации, что заметно увеличивает объем данных.
4. Пересчет итогов и незакрытые регистры: Если в регистрах накопления присутствуют незакрытые остатки (пересортица по аналитическим разрезам), таблицы итогов резко разрастаются при пересчете.

Возможности платформы 1С и ограничения механизма ТиИ

Выясним, существует ли возможность сжать базу средствами Конфигуратора. В режиме «Тестирование и исправление» (ТиИ) присутствует флаг «Сжатие таблиц информационной базы». Однако в клиент-серверном варианте работы (MSSQL) данная процедура лишь выполняет внутреннюю реорганизацию страниц в таблицах СУБД и удаляет логически помеченные на удаление записи. Она не возвращает освободившееся дисковое пространство операционной системе и не уменьшает физический размер файлов .mdf и .ldf.

Платформа 1С не имеет встроенных методов для выполнения физического сжатия файлов базы данных на стороне СУБД. Управление размером файлов данных лежит исключительно в зоне ответственности администратора баз данных.

Почему не рекомендуется выполнять сжатие файлов данных (SHRINK)

Сжатие файла данных (DBCC SHRINKFILE или DBCC SHRINKDATABASE) возвращает неиспользуемое пространство операционной системе, однако регулярное выполнение этой операции на рабочих базах 1С приводит к серьезным проблемам:

1. Критическая фрагментация индексов: Механизм сжатия переносит страницы данных из конца файла в его начало без учета структуры индексов. Это приводит к фрагментации индексов до 95–99%, что вызывает сильные задержки при выполнении запросов 1С.
2. Циклический рост и падение производительности: После сжатия требуется обязательное обслуживание индексов (Rebuild/Reorganize). Однако процедура перестроения индексов снова потребует свободного места внутри файла данных, и MSSQL снова выполнит автоматическое расширение (Autogrowth). Каждое такое расширение сопровождается задержкой операций ввода-вывода (I/O) и блокировками.

Свободное место внутри файла .mdf является резервом СУБД для будущих операций вставки данных, и его наличие — нормальный режим работы MSSQL.

Поиск незакрытых регистров накопления

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

ВЫБРАТЬ
    ТоварыОрганизацийОстатки.Организация КАК Организация,
    ТоварыОрганизацийОстатки.СтруктурноеПодразделение КАК СтруктурноеПодразделение,
    ТоварыОрганизацийОстатки.Товар КАК Товар,
    ТоварыОрганизацийОстатки.НомерГТД КАК НомерГТД,
    ТоварыОрганизацийОстатки.КоличествоОстаток КАК КоличествоОстаток
ИЗ
    РегистрНакопления.ТоварыОрганизацийБУ.Остатки КАК ТоварыОрганизацийОстатки
УПОРЯДОЧИТЬ ПО
    Организация,
    СтруктурноеПодразделение,
    Товар,
    НомерГТД

Если по одной номенклатуре в разрезе разных ГТД присутствуют остатки со значениями +10 и -10, регистр фактически не закрыт. Таблица итогов регистра накопления хранит избыточные строки, что увеличивает объем базы и замедляет проведение документов. Для сопоставления физических имен таблиц MSSQL с метаданными 1С используем метод ПолучитьСтруктуруХраненияБазыДанных().

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

Разберем корректные альтернативы сжатию файлов данных:

1. Выгрузка и загрузка через файл .dt: Выгрузка информационной базы в файл .dt с последующей загрузкой в новую пустую базу данных на MSSQL пересоздает структуру всех таблиц с нуля. Это полностью устраняет неиспользуемые пустоты и фрагментацию без выполнения команд сжатия на уровне СУБД.
2. Сжатие только журнала транзакций (.ldf): В отличие от файлов данных, сжатие лога транзакций безопасно для производительности. Перед тяжелым обновлением рабочую базу переводят в простую модель восстановления (Simple), после обновления выполняют резервное копирование, возвращают модель Full и сжимают файл лога.
3. Использование сжатия данных на уровне MSSQL (Page/Row Compression): Включение компрессии страниц (PAGE) или строк (ROW) для больших таблиц движений и версий объектов позволяет уменьшить объем дискового пространства в 2–3 раза и снизить нагрузку на дисковую подсистему без фрагментации файлов.