Обновление нетиповых или даже находящихся на полной поддержке конфигураций 1С:Управление производственным предприятием (УПП) — это всегда ответственный процесс, требующий от разработчика и системного администратора повышенного внимания. С выходом релиза 1.3.112.4 многие специалисты столкнулись с рядом крайне странных симптомов. В конфигураторе при сравнении баз начали "вылезать" реквизиты без типов данных, а сам файл конфигурации .cf неожиданно вырос в объеме практически в два раза.
В этой статье мы подробно разберем причины возникновения этих проблем, проанализируем их влияние на стабильность системы и рассмотрим практические шаги по их устранению, включая особенности администрирования баз данных под управлением СУБД PostgreSQL.
---
При сравнении обновленной конфигурации 1.3.112.4 с предыдущими релизами (например, 1.3.111.x) или при анализе конфигурации поставщика вы можете обнаружить следующие аномалии:
РаботаСАкцизнымиМаркамиЕГАИС на форме ФормаВводаАкцизнойМарки реквизит Номенклатура не имеет назначенного типа данных.ПодключаемоеОборудование (или в связанных формах управления фискальными регистраторами) локальный реквизит Объект также оказывается без указания типа.Выясним причину происходящего. Данное поведение не является следствием локального сбоя базы данных на вашем сервере. Это классический баг сборки официального релиза со стороны вендора (фирмы «1С»). При подготовке файлов поставки (.cf и .cfu) автоматические скрипты сборщика некорректно сериализуют XML-структуру метаданных некоторых управляемых и обычных форм. В результате типы данных локальных реквизитов форм просто «затираются» и становятся пустыми в конфигурации поставщика.
Почему же в рабочей базе данных (конфигурации БД) у этих реквизитов часто отображается тип Строка?
Платформа «1С:Предприятие» в режиме конфигуратора строго следит за целостностью метаданных. Наличие реквизита без явного указания типа считается критической ошибкой. При попытке выполнить обновление конфигурации базы данных (клавиша F7) платформа автоматически обрабатывает пустые значения типов и принудительно сопоставляет им дефолтный тип — как правило, Строка (с неограниченной или ограниченной длиной). Таким образом, конфигуратор физически не позволяет записать в рабочую БД "бестиповой" объект.
Как это влияет на работу пользователей в режиме «1С:Предприятие»?
К счастью, критических сбоев (Runtime errors) в пользовательском режиме из-за этого бага обычно не возникает. В коде модулей данных форм значения этих реквизитов инициализируются программно при открытии или в процессе интерактивной работы. Платформа 1С динамически типизирует переменные, поэтому функционал ЕГАИС и работа с подключаемым оборудованием продолжают функционировать в штатном режиме.
Рассмотрим, как правильно поступать при последующих обновлениях:
Главная неприятность этой ошибки — постоянные ложные срабатывания при сравнении и объединении конфигураций при переходе на версии 1.3.113 и выше. Система всегда будет указывать на расхождения между конфигурацией поставщика и вашей основной конфигурацией. Чтобы избежать конфликтов и не затереть нужные настройки, придерживайтесь следующих правил по шагам:
Номенклатура и Объект).Строка (или соответствующий объектный тип, если это требуется для логики кастомизированной формы).---
Многие администраторы заметили, что размер выгрузки конфигурации .cf начиная с релиза 1.3.112 увеличился почти в два раза по сравнению со 111-м релизом. Сравним объемы: если ранее файл весил около 400–500 Мб, то теперь его размер вплотную приблизился к 900 Мб – 1 Гб.
Проанализируем причину роста. Разработчики 1С существенно расширили библиотеку подключаемого оборудования (БПО), интегрированную в УПП. В состав общего макета конфигурации было добавлено огромное количество новых драйверов торгового оборудования, ККТ и терминалов сбора данных. Большинство этих драйверов поставляются в виде тяжелых бинарных файлов (внешних компонент .zip и .dll), сохраненных непосредственно в метаданных в виде макетов с типом "Двоичные данные".
Критическая проблема для пользователей PostgreSQL:
Этот лавинообразный рост размера метаданных спровоцировал серьезную техническую проблему для всех крупных предприятий, чьи информационные базы развернуты на СУБД PostgreSQL (особенно на версиях 9.6, 10, 11 и 12, оптимизированных для 1С).
При попытке обновиться или выполнить резервное копирование с помощью стандартной утилиты СУБД администраторы начали получать критические ошибки:
invalid memory alloc request size — при выполнении запросов к системным таблицам.PQgetResult() при обращении к таблице config.pg_dump при попытке создать логический бэкап базы данных.Разберем природу этого ограничения. PostgreSQL имеет внутренний лимит на размер одного обрабатываемого значения (поля в строке таблицы) в рамках одного запроса, который составляет ровно 1 Гб в несжатом виде. Таблица config в базе данных 1С хранит системные данные, включая саму структуру метаданных, файлы конфигурации базы данных и конфигурации поставщика. Когда в СУБД включена возможность изменения конфигурации, 1С хранит в ней сразу несколько тяжелых конфигураций (основную, базу данных, поставщика). При попытке прочитать или записать эти данные единым пакетом, размер данных превышает внутренний лимит PostgreSQL, что мгновенно приводит к падению рабочего процесса СУБД.
---
Если ваша база данных УПП перестала обновляться или создавать резервные копии на PostgreSQL, выберите один из следующих вариантов решения.
Самый быстрый способ уменьшить размер таблицы config ниже критического порога — это избавление от хранения истории конфигурации поставщика в СУБД.
.dt, если она еще проходит).Важно: После выполнения этой процедуры вы не сможете использовать стандартный механизм автоматического обновления "следующим файлом обновления .cfu". Вам придется выполнять последующие обновления путем сравнения и объединения с полным файлом конфигурации нового релиза (.cf).
Если утилита логического резервного копирования pg_dump завершается с ошибкой выделения памяти, вам необходимо отказаться от нее в пользу инструментов физического копирования файлов СУБД на горячую.
Вместо использования скриптов с вызовом pg_dump настройте резервное копирование с помощью стандартной утилиты PostgreSQL — pg_basebackup. Этот инструмент выполняет копирование файлов базы данных на физическом уровне (бинарно), обходя ограничения движка SQL на лимиты полей в 1 Гб, так как он не анализирует структуру таблиц в процессе работы.
Если вам критически важно сохранить конфигурацию на поддержке и продолжать использовать логические бэкапы, мы можем пойти по пути уменьшения веса самого .cf файла. Разберем этот процесс по шагам:
config, вернув его в безопасную для PostgreSQL зону.Для наглядности приведем пример того, как программно проверить, какие внешние компоненты загружаются системой, чтобы случайно не удалить нужные драйверы. Вы можете использовать следующий код в обработке для анализа подключенных компонент:
Попытка
ИмяФайлаКомпоненты = "ОбщийМакет.ДрайверСканерШтрихкода"; // Пример имени макета
ДанныеМакеты = ПолучитьОбщийМакет(ИмяФайлаКомпоненты);
Если ДанныеМакеты <> Неопределено Тогда
ЗаписатьЛог("Драйвер успешно инициализирован в системе.");
КонецЕсли;
Исключение
ЗаписатьЛог("Ошибка обращения к макету драйвера: " + ОписаниеОшибки());
КонецПопытки;
---
Подводя итог анализу релиза 1.3.112.4 для 1С:УПП, дадим несколько ключевых советов для администраторов систем:
При обновлении не пугайтесь предупреждений о потере типов реквизитов Номенклатура и Объект — это штатная ошибка релиза, которую платформа нивелирует принудительным приведением к строковому типу в базе данных. Достаточно контролировать этот момент при объединении форм.
Если вы работаете на PostgreSQL, заранее подготовьте инфраструктуру к росту базы данных: протестируйте физические бэкапы через pg_basebackup или будьте готовы снять конфигурацию с поддержки для уменьшения нагрузки на таблицы метаданных СУБД.