Как включение возможности изменения конфигурации 1С влияет на объем базы данных и скорость запуска?

← На главную

Разработчики и администраторы систем на платформе «1С:Предприятие» часто сталкиваются с дилеммой: стоит ли включать возможность изменения («снимать с замка») типовую конфигурацию? Существует множество мифов о том, что измененные конфигурации работают и запускаются в два раза медленнее тех, которые остались на полной поддержке поставщика. Еще один насущный вопрос — насколько физически увеличивается объем базы данных после нажатия заветной кнопки в настройках поддержки.

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

---

1. Как хранятся конфигурации в СУБД и почему растет размер базы данных

Рассмотрим, как именно платформа «1С:Предприятие» взаимодействует с СУБД (будь то Microsoft SQL Server, PostgreSQL, IBM DB2 или Oracle) на уровне хранения метаданных. Когда база данных находится на полной поддержке поставщика (на всех объектах дерева метаданных отображается пиктограмма «замочек»), платформа оптимизирует хранение файлов конфигурации.

На уровне физических таблиц в СУБД за хранение структуры метаданных отвечают две ключевые таблицы:

[Config] — основная рабочая таблица. Она хранит конфигурацию базы данных (с которой работают пользователи в режиме предприятия), основную (редактируемую в данный момент в конфигураторе) конфигурацию, а также конфигурацию поставщика.
[ConfigSave] — временная таблица, куда записываются промежуточные сохранения основной конфигурации в процессе разработки (до того, как будет выполнено обновление конфигурации базы данных по клавише F7).

В тот момент, когда конфигурация находится на полной поддержке, физически в СУБД нет необходимости держать избыточные копии метаданных. Но как только мы переходим в меню Конфигурация — Поддержка — Настройка поддержки и нажимаем кнопку «Включить возможность изменения», логика хранения кардинально меняется.

Даже если мы оставим для всех объектов без исключения правило «Объект поставщика не редактируется» (то есть сохраним все «замочки»), в таблице [Config] мгновенно создается обособленная физическая копия конфигурации поставщика. Платформа сжимает ее в бинарные блоки и сохраняет под уникальными GUID-идентификаторами.

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

Основная конфигурация — то, что мы редактируем в Конфигураторе.
Конфигурация базы данных (DB Config) — исполняемая конфигурация, с которой работают пользователи.
Конфигурация поставщика — эталонная версия от фирмы «1С», необходимая для последующего сравнения и обновления.

Для тяжелых прикладных решений (таких как «1С:ERP Управление предприятием», «1С:Комплексная автоматизация» или «1С:Управление производственным предприятием») размер метаданных в сжатом виде составляет сотни мегабайт. Физическое дублирование конфигураций приводит к моментальному увеличению объема служебных таблиц в СУБД в 1.5–2 раза. На диске это может выражаться в росте размера базы данных на 500 Мб – 1.5 Гб еще до того, как вы внесли первое реальное изменение в код.

---

2. Влияние модификации конфигурации на скорость запуска «1С:Предприятия»

Существует устойчивое мнение, что снятая с поддержки конфигурация загружается у пользователей значительно дольше. Проанализируем, так ли это на самом деле.

При запуске клиентского сеанса (в режиме тонкого, толстого или веб-клиента) платформа обращается исключительно к конфигурации базы данных. Ни основная («редактируемая») конфигурация, ни конфигурация поставщика при старте системы не считываются и в оперативную память сервера или клиента не загружаются. Таким образом, само по себе наличие конфигурации поставщика в таблице [Config] никак не влияет на скорость инициализации пользовательского сеанса.

Тогда почему измененные базы действительно иногда дольше открываются? Выделим реальные косвенные причины:

Динамическое обновление (люфт-эффект). Разработчики кастомизированных баз часто используют механизм динамического обновления («на лету»), чтобы не выгонять пользователей из системы. Это приводит к созданию множества версий метаданных в таблице [Config], фрагментации индексов на уровне СУБД и засорению локального кэша на компьютерах пользователей. В результате при старте платформа тратит дополнительное время на сопоставление версий кэша и метаданных.
Код инициализации при запуске. Медленный запуск практически всегда связан с неоптимизированным кодом в модуле управляемого приложения (события ПриНачалеРаботыСистемы, ПередНачаломРаботыСистемы) или в обработчиках параметров сеанса. Если при старте выполняются тяжелые запросы, проверки прав доступа или обращения к веб-сервисам, старт системы существенно замедляется.
Проблемы с лицензированием и сетевым окружением. Часто задержка происходит на этапе поиска аппаратного (HASP) или программного ключа защиты. Неправильно настроенный файл конфигурации nethasp.ini заставляет платформу опрашивать всю локальную сеть по различным протоколам, что визуально выглядит как «зависание» при запуске.

Для выявления истинной причины медленного старта рекомендуется использовать механизм замера производительности или технологический журнал. Ниже приведен пример того, как можно зафиксировать время выполнения инициализации в коде модуля управляемого приложения:


Процедура ПриНачалеРаботыСистемы()
    
    ВремяСтарта = ТекущаяУниверсальнаяДатаВМиллисекундах();
    
    // Вызов тяжелых серверных процедур инициализации
    ИнициализироватьПараметрыКлиента();
    
    ВремяОкончания = ТекущаяУниверсальнаяДатаВМиллисекундах();
    ОбщееВремяСекунд = (ВремяОкончания - ВремяСтарта) / 1000;
    
    ЗаписьЖурналаРегистрации(
        "ВремяЗапускаСистемы",
        УровеньЖурналаРегистрации.Информация,
        ,,
        "Время инициализации клиента составило: " + ОбщееВремяСекунд + " сек."
    );
    
КонецПроцедуры

---

3. Эволюция механизма расширений: почему больше не нужно снимать базу с поддержки

В прошлых версиях платформы (например, во времена 8.3.6 – 8.3.12) механизм расширений был сильно ограничен. Разработчик не мог добавить собственный регистр сведений, справочник или создать подписку на событие внутри расширения. Любая мало-мальски серьезная доработка требовала включения возможности изменения основной конфигурации.

В современных версиях платформы ситуация кардинально изменилась. Начиная с версии 8.3.11 и вплоть до актуальных релизов 8.3.24+, разработчикам доступен мощнейший инструментарий:

Возможность создавать в расширениях собственные справочники, документы, бизнес-процессы, задачи и все виды регистров (сведений, накопления, расчета).
Возможность заимствовать и дорабатывать роли, интерфейсы, общие модули и подписки на события.
Возможность изменения типов заимствованных реквизитов и добавления предопределенных элементов.

Благодаря этому в 99% случаев сегодня можно полностью отказаться от снятия конфигурации с поддержки. Все доработки изолируются в расширениях, а основная конфигурация остается на «замочке». Это гарантирует:

Минимальный физический объем базы данных в СУБД.
Максимально быстрое обновление конфигурации (так как платформе не нужно выполнять сложное трехстороннее сравнение-объединение метаданных).
Простоту поддержки и прозрачность внесенных изменений.

---

4. Риски принудительного изменения режима совместимости

Иногда разработчики идут на радикальный шаг — принудительно повышают режим совместимости конфигурации (например, с версии 8.3.6 до 8.3.12 или выше) непосредственно в свойствах дерева метаданных основной конфигурации, чтобы получить доступ к новым возможностям платформы или расширений.

Рассмотрим, к каким критическим последствиям и скрытым ошибкам может привести такой шаг без полноценного переписывания кода конфигурации:

Интерфейсный коллапс. Начиная с версии платформы 8.3.7, фирма «1С» кардинально обновила механизмы рендеринга управляемых форм и интерфейс «Такси». При резком отключении старого режима совместимости формы, спроектированные под старые стандарты отображения, могут отображаться некорректно: элементы управления накладываются друг на друга, сбиваются группировки и привязки.
Ужесточение стандартов транзакционных блокировок. В современных версиях платформы требования к автоматическим и управляемым блокировкам стали намного жестче. Код, который успешно работал в режиме совместимости с 8.3.6, при переходе на новые стандарты может начать вызывать частые взаимоблокировки (Deadlocks) или ошибки ожидания блокировок СУБД при одновременной работе нескольких пользователей.
Конфликты с Библиотекой Стандартных Подсистем (БСП). В коде БСП заложено огромное количество внутренних проверок используемой платформы. Принудительное изменение режима совместимости в свойствах конфигурации без соответствующего обновления версии БСП гарантированно приведет к неработоспособности базовых механизмов системы: фоновых заданий, механизмов авторизации, интеграционных шин и регламентных операций.

---

5. Почему «тяжелеют» типовые конфигурации (проблема макетов)

Многие системные администраторы замечают, что файлы обновлений конфигураций (файлы .cf и .cfu) за последние годы выросли в объеме в несколько раз. Например, размер дистрибутива конфигурации может превышать 1.5–2 Гб.

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

Драйверы торгового оборудования. Современные конфигурации содержат в себе полные zip-архивы драйверов для сотен моделей фискальных регистраторов, эквайринговых терминалов и сканеров штрихкодов.
Компоненты защиты и лицензирования (СЛК). Отраслевые решения поставляются со встроенными бинарными файлами защиты.
Дистрибутивы тонких клиентов. Фирма «1С» интегрирует дистрибутивы тонких клиентов под разные операционные системы (Windows, Linux, macOS) прямо в общие макеты конфигурации. Это сделано для того, чтобы при обновлении версии сервера у пользователей на рабочих станциях тонкий клиент обновлялся автоматически прямо из базы данных. Удобство администрирования в данном случае компенсируется увеличением объема файла конфигурации на сотни мегабайт.

---

Резюме

Подведем итоги нашего анализа:

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