Как исправить ошибку IDS_LICENSE_DATABASECOPY и зависание сервера 1С:Предприятие 8.3

Системный администратор 1С v8.3 (Управляемые формы)
← На главную

В процессе эксплуатации высоконагруженных систем на базе платформы 1С:Предприятие 8.3 системные администраторы часто сталкиваются с ситуацией, когда сервер перестает отвечать, клиенты не могут подключиться, а в консоли администрирования наблюдается аномальное количество «зависших» фоновых заданий. При анализе технологического журнала (ТЖ) обнаруживается бесконечный цикл записей с ошибкой IDS_LICENSE_DATABASECOPY. В этой статье мы подробно разберем, почему возникает эта проблема и как ее устранить различными методами.

Анализ ситуации и причины возникновения ошибки

Разберем природу сообщения IDS_LICENSE_DATABASECOPY. Данный идентификатор относится к механизму «Копии базы данных» и использованию «Дата-акселератора». Эти функции официально требуют наличия лицензии уровня КОРП. Однако проблема заключается в том, что ошибка фиксируется даже в тех системах, где данные механизмы никогда не настраивались и не использовались.

Выясним причину: это системная ошибка платформы (внутренние номера багов 10237750 и 40062369). Процесс ragent или rmngr при выполнении внутренних регламентных операций по проверке топологии кластера некорректно обращается к функционалу копий баз данных. Если в системе установлены обычные лицензии (ПРОФ), платформа инициирует исключение EXCP, которое записывается в лог. При высокой интенсивности таких обращений (каждые 1–2 минуты) происходят следующие негативные процессы:

Решение №1: Обновление технологической платформы (Рекомендуемое)

Проанализируем официальные исправления от компании 1С. Поскольку проблема признана программной ошибкой, наиболее надежным способом ее решения является переход на релизы, где этот баг был исправлен. Рассмотрим версии, в которых ошибка IDS_LICENSE_DATABASECOPY больше не проявляется:

  1. В ветке 8.3.22 исправление внесено начиная с версии 8.3.22.1603.
  2. В ветке 8.3.21 исправление доступно в последних сборках.
  3. В ветке 8.3.20 (на которой чаще всего воспроизводится ошибка) исправление появилось в релизе 8.3.20.2158.

Если ваша система работает на версии 8.3.20.1549, 8.3.20.1613 или 8.3.20.1710, обновление в рамках той же ветки (до 2158) будет самым быстрым и безопасным решением.

Решение №2: Очистка кэша кластера и настроек

Иногда ошибка «залипает» в реестре кластера даже после изменения условий эксплуатации. Проведем процедуру полной очистки временных данных сервера. Внимание: это потребует кратковременной остановки службы 1С.

  1. Остановим службу 1C:Enterprise 8.3 Server Agent.
  2. Перейдем в каталог данных сервера (обычно это C:\Program Files\1cv8\srvinfo).
  3. Удалим содержимое папок reg_1541 (или другого порта), за исключением файла 1cv8wsrv.lst, если мы не хотим заново прописывать базы в консоли. Однако для максимально «чистого» результата рекомендуется очистить все и пересоздать список баз вручную.
  4. Удалим временные файлы в папке snccntx.
  5. Запустим службу заново.

Решение №3: Обновление компоненты печати штрихкодов

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

  1. Найдем в актуальной типовой конфигурации (например, в свежем релизе УТ 11) общий макет с именем КомпонентаПечатиШтрихКодов.
  2. Выгрузим этот макет в файл, нажав правую кнопку мыши и выбрав «Сохранить в файл».
  3. В нашей проблемной базе откроем Конфигуратор, найдем аналогичный макет.
  4. Выберем пункт «Загрузить из файла» и укажем ранее сохраненную новую версию компоненты.
  5. Выполним обновление конфигурации базы данных.

Это действие помогает в случаях, когда ошибка возникает именно в момент работы пользователей с торговым оборудованием или печатными формами.

Решение №4: Оптимизация настроек Технологического журнала

Если по каким-то причинам немедленное обновление платформы невозможно, мы можем снизить нагрузку на сервер, исключив запись данной ошибки в логи. Это не устранит саму причину, но предотвратит зависание из-за переполнения диска и чрезмерной работы с I/O. Отредактируем файл logcfg.xml, добавив фильтр исключений.

Пример настройки фильтрации для события EXCP:


<log location="C:\LOGS\1C" history="24">
    <event>
        <eq property="Name" value="EXCP"/>
        <ne property="Descr" value="IDS_LICENSE_DATABASECOPY"/>
    </event>
    <property name="all"/>
</log>

Использование оператора ne (not equal) в свойстве Descr позволит платформе игнорировать записи, содержащие текст о лицензии КОРП, сохраняя при этом другие важные ошибки для анализа.

Решение №5: Проверка сетевой связности и менеджера лицензий

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

Рекомендуется выполнить следующие действия:

Таким образом, мы рассмотрели комплекс мер по борьбе с ошибкой IDS_LICENSE_DATABASECOPY. Начните с обновления платформы до рекомендуемых релизов, так как это единственный способ полностью устранить корень проблемы, заложенный в программном коде 1С.

← На главную