Почему после обновления 1С с версии 11.4 на 11.5 резко вырос размер базы и как его уменьшить

← На главную

Переход с версии 11.4 на 11.5 в таких конфигурациях, как 1С:Управление торговлей, 1С:ERP или Комплексная автоматизация, является одним из самых ресурсоемких обновлений за последние годы. Часто администраторы и программисты сталкиваются с ситуацией, когда после успешного завершения процесса размер файла базы данных (MDF) увеличивается в несколько раз — например, с 20 Гб до 80 Гб. В этой статье мы подробно разберем, почему это происходит, проанализируем роль регистра ТоварыКОтгрузке и изучим методы принудительного уменьшения объема базы без потери производительности.

Выясняем причины: почему растет регистр Товары к отгрузке

Разберем ситуацию: основным «виновником» роста часто становится регистр накопления ТоварыКОтгрузке. В версии 11.5 разработчики 1С радикально пересмотрели концепцию обеспечения заказов. Появился так называемый «Новый порядок обеспечения». Рассмотрим по шагам, что происходит при обновлении:

Массовая миграция данных: При переходе система пересчитывает все текущие остатки и резервы. Старые записи в регистрах не просто удаляются, а заменяются новыми структурами. Это порождает колоссальный объем транзакционных записей.
Изменение структуры таблиц: В регистр ТоварыКОтгрузке и связанные с ним таблицы итогов добавляются новые измерения и реквизиты. Даже небольшое увеличение длины строки в таблице с миллионами записей дает существенный прирост в гигабайтах.
Временные таблицы и итоги: В процессе пересчета 1С создает множество временных записей в таблицах итогов. Даже если после завершения обновления «лишние» движения удаляются, физическое место в файлах MS SQL Server остается зарезервированным.

Шаг 1. Контроль завершения отложенного обновления

Прежде чем приступать к операциям на уровне SQL-сервера, нам необходимо убедиться, что сама платформа 1С завершила все регламентные операции. В версии 11.5 многие процедуры миграции данных вынесены в отложенное обновление. Если они не завершены, база будет хранить избыточные данные для обеспечения возможности дозаполнения новых регистров.

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

Шаг 2. Очистка на уровне 1С: Тестирование и исправление

Если обновление завершено, а размер регистра в 1С (по данным отчетов) пришел в норму, но файл базы на диске все еще огромен, рассмотрим штатные средства платформы. Нам поможет инструмент «Тестирование и исправление» (ТиИ). Однако важно выбрать правильные опции:

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

Шаг 3. Работа с MS SQL Server: Shrink и его последствия

Выясним причину, по которой база в SQL остается большой, даже если данные внутри нее удалены. SQL Server работает по принципу резервирования: если ему однажды потребовалось 80 Гб под данные, он будет удерживать этот объем в файле .mdf, ожидая новых вставок. Чтобы вернуть это место операционной системе, необходимо выполнить операцию Shrink (Сжатие).

Рассмотрим алгоритм безопасного сжатия:

Важно: Прямое выполнение команды SHRINKDATABASE приводит к катастрофической фрагментации индексов, что может замедлить работу 1С в несколько раз.

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

Для оценки свободного места внутри файла можно использовать следующий SQL-запрос:


SELECT 
    name AS FileName, 
    size/128.0 AS CurrentSizeMB, 
    size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS FreeSpaceMB
FROM sys.database_files;

Шаг 4. Использование сжатия данных (Data Compression)

Одним из самых эффективных методов «похудения» базы является включение сжатия на уровне таблиц SQL Server. Существует мнение, что это сильно снижает скорость работы, однако на современной технике это миф. Нагрузка на CPU немного возрастает, но нагрузка на дисковую подсистему (I/O) снижается, так как серверу нужно читать меньше страниц с диска.

Для 1С наиболее эффективно Page Compression (сжатие страниц). Оно отлично работает с GUID и повторяющимися значениями, которых в 1С огромное количество. Проанализируем эффект: база может уменьшиться в 2–4 раза без потери производительности для пользователя.

Пример команды для включения сжатия одной из самых тяжелых таблиц (замените TableName на реальное имя таблицы регистра):


ALTER TABLE [dbo].[_AccumRg12345] 
REBUILD PARTITION = ALL 
WITH (DATA_COMPRESSION = PAGE);

Шаг 5. Радикальный метод: Перезаливка через .dt

Если вы не обладаете глубокими знаниями SQL или база ведет себя нестабильно, можно прибегнуть к методу, который использовал автор темы. Рассмотрим его шаги:

Создаем полную резервную копию базы.
Выгружаем информационную базу в файл .dt.
Создаем новую пустую базу на SQL Server.
Загружаем .dt в новую базу.

Почему это работает? При загрузке из .dt платформа 1С создает таблицы с нуля, последовательно записывая данные. Это автоматически устраняет фрагментацию, пересчитывает итоги и не резервирует лишнего места. База будет иметь минимально возможный физический размер. Однако помните, что для баз объемом более 100 Гб выгрузка в .dt может быть нестабильной.

Работа с логом транзакций (.ldf)

В процессе обновления с 11.4 на 11.5 огромный рост показывает не только основной файл данных, но и лог транзакций. Если ваша база находится в модели восстановления Full, лог будет расти бесконечно, пока не будет сделан бэкап лога.

Для разовой очистки после обновления рекомендуем:

Переключить модель восстановления в Simple.
Выполнить Shrink для лог-файла.
Вернуть модель Full (если вы используете инкрементальные бэкапы).

Подводя итог, отметим: рост базы при переходе на 11.5 — это ожидаемое поведение, связанное с изменением архитектуры учета. Сочетание штатного «Пересчета итогов» в 1С и грамотного обслуживания на уровне SQL Server (сжатие и перестроение индексов) позволяет вернуть объем базы к разумным пределам и сохранить высокую скорость работы системы.