При обновлении крупных конфигураций, таких как 1С:ERP Управление предприятием, системные администраторы и разработчики часто сталкиваются с резким увеличением объема файла базы данных на SQL-сервере. Например, при переходе между техническими релизами (даже в рамках одной ветки, например, 2.5.8) объем может вырасти на 5–10 Гб за один шаг. Рассмотрим подробнее, почему это происходит, разберем влияние механизма «Копии базы данных» и выясним, как вернуть базе оптимальный размер.
В процессе обновления системы 1С:Предприятие в логах часто можно увидеть сообщения о создании таблиц, относящихся к механизму «Копии базы данных» (Data Acceleration). У многих пользователей это вызывает опасения, особенно если используется лицензия уровня ПРОФ, которая официально не поддерживает работу с копиями (требуется лицензия КОРП).
Проанализируем ситуацию: даже если функционал копий базы данных не активирован программно, соответствующие объекты метаданных включены в состав типовой конфигурации ERP. При реструктуризации платформы или обновлении метаданных SQL-сервер обязан создать физические структуры (таблицы) для этих объектов. Рассмотрим ключевые моменты:
Таким образом, само наличие таблиц «Копий базы данных» не является основной причиной роста на несколько гигабайт. Основной объем «съедают» другие процессы.
Разберем по шагам, что происходит с файлом .mdf в процессе обновления. Основная причина роста — реструктуризация таблиц. Когда в новом релизе меняется состав реквизитов, типы данных или индексы в крупных регистрах, СУБД выполняет следующие действия:
В момент выполнения этой операции SQL-серверу требуется место для хранения обеих копий данных. Если у вас регистр накопления занимает 5 Гб, то в процессе его пересоздания база временно вырастет еще на 5 Гб. После завершения операции старое место помечается как свободное (White Space), но физический размер файла базы данных на диске не уменьшается автоматически.
Посмотрим на структуру ERP в динамике. От релиза к релизу (например, при переходе с 2.5.8 на 2.5.12) количество объектов метаданных неуклонно растет. Рассмотрим причины дополнительного веса:
1. Новые индексы. Для ускорения работы отчетов и проведения документов разработчики 1С постоянно оптимизируют индексы. В ERP индексы могут занимать до 20–40% от общего объема фактических данных. Новые индексы для подсистем «Закупки», «Склад» или «Производство» добавляют сотни мегабайт к общему весу.
2. Версионирование объектов. Если в базе включена «История изменений», то при запуске отложенных обработчиков обновления, которые массово перезаписывают документы для актуализации данных, создается огромное количество новых версий в регистре СведенияОНоменклатуре или подобных. Это приводит к моментальному росту базы.
3. Полнотекстовый поиск. Расширение области использования полнотекстового поиска также создает дополнительные служебные данные в системных таблицах.
Чтобы стабилизировать размер базы и не допустить бесконтрольного роста дискового пространства, рекомендуем выполнять следующий регламент после каждого этапа обновления:
В ERP основная часть работы по трансформации данных происходит не в конфигураторе, а в режиме «Предприятие» в фоне. Пока статус всех обработчиков обновления не станет «Выполнено», проводить сжатие базы бессмысленно, так как данные продолжают перемещаться.
После того как реструктуризация завершена и старые таблицы удалены, внутри файла .mdf образуется много пустого места. Для его возврата операционной системе используйте команду SQL:
DBCC SHRINKDATABASE (Имя_Вашей_Базы);
Важно: Чрезмерное использование Shrink может привести к фрагментации индексов, поэтому сразу после сжатия необходимо выполнить обслуживание индексов.
Проанализируем состояние индексов после массового обновления данных. Рекомендуется выполнить дефрагментацию (Reorganize) или перестроение (Rebuild) индексов, а также обновить статистики. Это не только оптимизирует место, но и значительно ускорит работу системы после обновления.
Если ваша конфигурация «НЕ типовая», как у автора вопроса, следует обратить внимание на добавленные реквизиты. При обновлении типовых объектов, в которые добавлены ваши кастомные поля, процесс реструктуризации может проходить медленнее и требовать больше временного пространства в tempdb и основном файле данных.
Проверьте, не дублируют ли ваши доработки новый типовой функционал. Иногда при обновлении стоит перенести данные из своих реквизитов в новые типовые и удалить лишние объекты, чтобы снизить нагрузку на СУБД и уменьшить объем хранимых данных.
Рост базы ERP на 6–10 Гб при обновлении — это нормальное явление, обусловленное архитектурой 1С и SQL Server. Это не является ошибкой или следствием «лишних» механизмов типа копий баз данных. В большинстве случаев это временное расширение файла под нужды реструктуризации. Регулярное техническое обслуживание SQL-сервера после обновлений позволит вам держать размер базы под контролем.