← На главную

Переход на новые версии технологической платформы 1С:Предприятие — это всегда ответственный шаг для системного администратора и разработчика. Очень часто разработчики прикладных решений (например, конфигурации "Бухгалтерия предприятия КОРП, редакция 3.0") выпускают очередные обновления, которые жестко требуют использования платформы не ниже определенного релиза. В такой ситуации перед нами встает дилемма: какую ветку выбрать — условно стабильную и проверенную временем 8.3.15 или более новую 8.3.16?

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

Выбор между ветками платформы: 8.3.15 или 8.3.16

Выпуская обновления для конфигураций, фирма "1С" постепенно поднимает требования к минимальному релизу платформы. Например, для полноценной работы конфигурации БП КОРП версии 3.0.75.37 требуется платформа версии не ниже 8.3.15.1830. Это связано с тем, что прикладной код начинает активно использовать новые возможности Библиотеки стандартных подсистем (БСП) и оптимизированные механизмы запросов, которые физически не поддерживаются старыми версиями платформы.

При выборе релиза между 8.3.15 и 8.3.16 рекомендуем придерживаться следующих правил:

1. Консервативный подход (ветка 8.3.15). Если вашей основной задачей является обеспечение стабильности без погони за новым функционалом интерфейса, оптимальным решением станет выбор верхних стабильных билдов ветки 8.3.15 (например, 8.3.15.1830). Эта линейка является стабилизированной, в ней исправлено большинство базовых системных ошибок, и она полностью совместима с актуальными требованиями конфигураций.
2. Инновационный подход (ветка 8.3.16). Если вам требуются новые возможности платформы — такие как улучшенные диаграммы, доработки Системы взаимодействия, новые функции видеозвонков и демонстрации экрана, то следует выбирать ветку 8.3.16. При этом крайне не рекомендуется ставить самые первые билды этой ветки. Наиболее стабильным и проверенным решением здесь выступает релиз 8.3.16.1148 и выше.

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

Решение ошибки SDBL: «Для одного ссылочного кода существует более одной таблицы в базе данных»

Это одна из самых коварных и распространенных ошибок СУБД, с которой сталкиваются администраторы при переходе с платформы 8.3.14 на 8.3.15 и 8.3.16. Проблема локализуется на уровне сервера приложений 1С и СУБД (например, MS SQL Server или PostgreSQL).

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

Рассмотрим по шагам, как исправить эту ошибку:

Шаг 1. Выполнение реструктуризации проблемной таблицы через Конфигуратор

Самый простой способ заставить платформу пересчитать ссылочные коды для конкретного объекта метаданных (например, справочника или документа, на который ругается система при обновлении) — это принудительная реструктуризация. Для этого:

1. Откройте конфигурацию информационной базы в режиме Конфигуратор.
2. Найдите объект метаданных, вызывающий сбой.
3. Добавьте в этот объект новый реквизит с любым именем (например, ВременныйРеквизит) и типом Булево.
4. Выполните обновление конфигурации базы данных (клавиша F7). В этот момент платформа физически пересоздаст таблицу в СУБД и исправит сопоставление ссылочных кодов.
5. Удалите добавленный ВременныйРеквизит и снова обновите конфигурацию базы данных (F7).

Шаг 2. Очистка кэша сервера приложений 1С

Если реструктуризация через Конфигуратор не помогла, необходимо полностью очистить серверный кэш метаданных. Проанализируем схему действий:

1. Остановите службу сервера 1С:Предприятия (1C:Enterprise 8.3 Server Agent или ragent).
2. Перейдите в каталог кластера сервера. По умолчанию в ОС Windows это путь:
   C:\Program Files\1cv8\srvinfo\reg_1541\
3. Найдите внутри каталоги с уникальными идентификаторами баз (UID) и удалите в них папки кэша (папки с именами snccntx*).
4. Запустите службу сервера 1С.

Шаг 3. Использование резервного тестирования и исправления

В случае, если база полностью заблокирована, запустите тестирование и исправление информационной базы через Конфигуратор (меню Администрирование — Тестирование и исправление) с обязательным выбором пунктов "Реиндексация таблиц информационной базы" и "Реструктуризация таблиц информационной базы".

Решение ошибки: «Операция не может быть выполнена с текущим составом лицензий»

Начиная с версий платформы 8.3.15, разработчики 1С существенно ужесточили автоматический контроль соответствия используемых программных лицензий и настроек кластера. Если у вас установлена стандартная лицензия уровня ПРОФ, но в свойствах кластера или рабочих серверов заданы параметры, относящиеся к уровню КОРП, сервер заблокирует запуск сеансов пользователей с этой ошибкой.

Проанализируем ситуацию. Чтобы исправить эту проблему, нам необходимо вернуть настройки кластера к стандартным значениям, которые разрешены для лицензий уровня ПРОФ. Выполните следующие действия:

1. Запустите утилиту Администрирование серверов 1С:Предприятия.
2. Перейдите в свойства вашего кластера (по умолчанию "Локальный кластер").
3. Внимательно проверьте следующие параметры и установите их в значения по умолчанию:
   • Количество информационных баз на процесс: должно быть установлено в значение 0 (автоматически).
   • Количество соединений на процесс: установите в значение 0.
   • Максимальный объем памяти рабочих процессов: установите значение 0 (без ограничений).
   • Безопасный расход памяти за один вызов: установите значение 0.
4. Перейдите в ветку "Рабочие серверы", откройте свойства вашего сервера (например, "localhost") и убедитесь, что там также отсутствуют ограничения по памяти и не включена расширенная балансировка нагрузки.
5. Примените изменения и перезапустите службу сервера 1С.

Помните, что для ПРОФ-лицензий использование многопроцессности кластера жестко ограничено. Не пытайтесь вручную создавать дополнительные рабочие процессы rphost в консоли, предоставьте это автоматическим механизмам платформы.

Устранение сбоев платформы на Windows Server 2003 x64

При обновлении платформы до версий 8.3.15.1830 на серверах под управлением устаревшей ОС Windows Server 2003 x64 администраторы часто сталкиваются с моментальным аварийным завершением работы системы. Сразу после выбора информационной базы в окне запуска приложение аварийно закрывается, формируя минидамп в каталоге C:\Program Files\1cv8\common\.

Выясним причину этого сбоя. Современные релизы платформы 1С ориентированы на использование системных вызовов API операционных систем Windows Server 2008/2012 и выше. В Windows Server 2003 многие из этих динамических библиотек и вызовов отсутствуют или работают некорректно.

Для решения этой проблемы мы можем применить два подхода:

1. Обновление релиза платформы. Данная ошибка была частично исправлена разработчиками в релизе 8.3.16.1063 и полностью локализована в сборке 8.3.16.1148. Если архитектура вашей сети не позволяет оперативно обновить ОС, используйте для работы именно эти релизы платформы 8.3.16.
2. Миграция операционной системы (Рекомендуется). Работа современных версий 1С:Предприятия на Windows Server 2003 официально больше не поддерживается и не тестируется. Единственным надежным способом гарантировать стабильность и безопасность данных является переход на современные ОС (Windows Server 2016/2019 или дистрибутивы Linux).

Оптимизация потребления памяти и переход на 64-битные системы

Рассмотрим еще одну важную особенность версий 8.3.15 и 8.3.16. Архитектура рабочих процессов была изменена: в процесс rphost интегрировали новые фоновые механизмы поиска, контроля и интеграции с внешними сервисами. Это привело к росту потребления оперативной памяти — практически в два раза по сравнению с веткой 8.3.14.

Если на вашем сервере используется 32-разрядная версия сервера 1С:Предприятия, то один процесс rphost ограничен адресным пространством в 2 ГБ (в редких случаях 3 ГБ при использовании ключа /3GB). При активной работе пользователей (особенно более 10 человек) этот лимит достигается очень быстро, что приводит к критической ошибке нехватки памяти и аварийному вылету всех пользователей этого процесса.

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

1. Выполните переход на 64-разрядный сервер 1С:Предприятия. Это снимет ограничение адресного пространства процесса rphost в 2 ГБ и позволит серверу эффективно использовать всю установленную на сервере оперативную память.
2. Настройте регулярный перезапуск рабочих процессов. В свойствах кластера задайте параметр "Допустимый объем памяти" и "Интервал превышения допустимого объема памяти", чтобы нагруженные процессы, накопившие утечки памяти в течение дня, корректно и незаметно для пользователей замещались новыми чистыми процессами.

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