При обновлении информационной базы 1С:Предприятие 8.3 пользователи нередко сталкиваются с критической ошибкой СУБД, связанной с превышением максимально допустимой длины ключа индекса. Эта проблема особенно актуальна при переходе с файлового режима работы базы данных на клиент-серверный вариант, например, с использованием MS SQL Server или PostgreSQL, а также при обновлении сильно доработанных конфигураций — поможет панель управления кластером серверов и сеансами 1С. Давайте подробно разберем, почему возникает эта ошибка и как ее эффективно устранить.
Типичное сообщение об ошибке выглядит следующим образом:
Ошибка СУБД:
Длина ключа индекса превышает максимально допустимую '_Referen44781_ByParentFieldFld51836_RLRSRLSSSRS (_ParentIDRRef, _Folder, _Fld51836RRef, _Description, _IDRRef, _Marked, _Fld51840, _Fld51841, _Fld51842, _Fld51843RRef, _Fld51854) UNIQUE'
по причине:
Длина ключа индекса превышает максимально допустимую '_Referen44781_ByParentFieldFld51836_RLRSRLSSSRS (_ParentIDRRef, _Folder, _Fld51836RRef, _Description, _IDRRef, _Marked, _Fld51840, _Fld51841, _Fld51842, _Fld51843RRef, _Fld51854) UNIQUE'
Эта ошибка указывает на то, что один из индексов в базе данных, который 1С пытается создать или обновить, содержит слишком много полей или поля с очень большой длиной, что превышает ограничения используемой системы управления базами данных (СУБД). Файловая версия 1С имеет более "мягкие" ограничения на длину ключей индексов, чем клиент-серверные СУБД, такие как SQL Server или PostgreSQL. Поэтому конфигурация, прекрасно работающая в файловом режиме, может столкнуться с такой проблемой при попытке ее обновления или переноса на клиент-сервер. На доступной копии базы обработка обследования метаданных поможет сопоставить физическое имя таблицы с объектом 1С и изучить его реквизиты. Сам индекс она не исправляет.
Прежде чем перейти к решению, давайте подробнее рассмотрим основные причины этой ошибки:
Строка (500) или Строка (неограниченная длина). Каждая буква занимает определенное количество байт, и суммарная длина всех полей в индексе быстро превышает допустимый лимит.Важно понимать, что каждая СУБД имеет свои ограничения:
Мы предлагаем комплексный подход к устранению этой ошибки, начиная с подготовительных шагов и заканчивая конкретными действиями в конфигураторе 1С.
Восстановите базу из архива: Первое и самое главное правило администратора или программиста 1С – перед любыми критическими операциями, такими как обновление конфигурации, всегда создавать архивную копию базы данных — поможет обработка для принудительного завершения сеансов пользователей. Если обновление завершилось с ошибкой, не пытайтесь продолжить работу с испорченной базой. Восстановите ее до состояния, предшествующего неудачной попытке обновления.
Работайте только с копией: Никогда не выполняйте эксперименты или исправления на рабочей базе. Всегда создавайте точную копию рабочей базы и проводите все манипуляции на ней. Это позволяет безопасно проверять гипотезы, откатываться к предыдущему состоянию без риска для продуктивной работы и не "накосячить" в основной базе.
Сообщение об ошибке содержит ключевую информацию – имя проблемного индекса. В нашем примере это _Referen44781_ByParentFieldFld51836_RLRSRLSSSRS. Давайте разберем, как расшифровать это системное имя и найти соответствующий объект в конфигураторе.
Анализ имени индекса:
_Referen: Этот префикс почти всегда указывает на объект типа "Справочник" (Reference), но может также относиться к "Документу" или "Регистру".
44781: Это внутренний идентификатор (ID) объекта метаданных в конфигурации 1С. Мы будем использовать его для поиска.
_ByParentFieldFld51836_RLRSRLSSSRS: Эта часть указывает на поля, входящие в индекс, и их типы. Например, _ParentIDRRef – это поле, ссылающееся на родителя (ParentIDRRef), а _Fld51836RRef и _Fld51843RRef – это системные имена реквизитов, которые также являются ссылочными типами (RRef). Числа 51836, 51840, 51841, 51842, 51843, 51854 – это внутренние ID полей (реквизитов), которые участвуют в индексе.
UNIQUE: Этот суффикс указывает, что индекс является уникальным, то есть комбинация значений всех полей в нем должна быть неповторяющейся для каждой записи. Уникальные индексы часто создаются автоматически для измерений регистров, некоторых табличных частей или для полей, помеченных как "Основное представление".
Поиск объекта в конфигураторе 1С:
Чтобы найти, какому объекту соответствует ID 44781, мы можем воспользоваться специальными инструментами — для этого подойдут инструменты анализа метаданных и структуры системы. Откройте конфигуратор 1С.
51836) можно использовать поиск по метаданным или обработку для анализа структуры базы данных.Поиск в клиент-серверной СУБД (для продвинутых):
Если база данных клиент-серверная (например, MS SQL Server), вы можете выполнить SQL-запросы к системным представлениям для получения информации об индексах — в этом поможет мониторинг производительности СУБД и выявление тяжелых запросов. Например, в MS SQL Server, мы можем использовать следующие запросы:
SELECT
i.name AS IndexName,
OBJECT_NAME(i.object_id) AS TableName,
(SELECT SUM(COL_LENGTH(OBJECT_NAME(i.object_id), c.name))
FROM sys.index_columns ic
INNER JOIN sys.columns c ON ic.object_id = c.object_id AND ic.column_id = c.column_id
WHERE ic.object_id = i.object_id AND ic.index_id = i.index_id) AS IndexKeyLengthBytes,
i.is_unique
FROM sys.indexes i
WHERE i.name = '_Referen44781_ByParentFieldFld51836_RLRSRLSSSRS';
Этот запрос поможет подтвердить имя индекса, его таблицу и оценить его текущую длину. Затем вы можете запросить столбцы, входящие в индекс:
SELECT
c.name AS ColumnName,
t.name AS DataType,
c.max_length AS MaxLengthBytes
FROM sys.index_columns ic
INNER JOIN sys.columns c ON ic.object_id = c.object_id AND ic.column_id = c.column_id
INNER JOIN sys.types t ON c.system_type_id = t.system_type_id
WHERE ic.object_id = OBJECT_ID('ИмяПроблемнойТаблицы') AND ic.index_id = (SELECT index_id FROM sys.indexes WHERE name = '_Referen44781_ByParentFieldFld51836_RLRSRLSSSRS');
Замените 'ИмяПроблемнойТаблицы' на имя таблицы, соответствующей найденному объекту 1С. Системные таблицы 1С обычно начинаются с префиксов типа _ReferenceXXX, _DocumentXXX, _InfoRgXXX и т.д.
После того как вы нашли проблемный объект (например, справочник) и определили реквизиты, которые участвуют в индексе и имеют большую длину, необходимо внести изменения в конфигурацию.
Уменьшение длины строковых реквизитов:
Это наиболее прямолинейное и часто используемое решение. Если в проблемном индексе присутствует строковый реквизит, длина которого избыточна (например, Строка (500), хотя фактически используется не более 100 символов), мы можем уменьшить его длину.
_Referen44781)._Fld51836RRef, _Fld51840 и т.д.). Обычно это реквизиты, добавленные разработчиками или кастомизаторами.Строка (500), попробуйте уменьшить до Строка (100) или Строка (255). Важно при этом провести анализ фактического использования данных, чтобы не обрезать важную информацию. Если вы не уверены, лучше сделать минимально возможное изменение, которое позволит пройти обновление, а затем оценить последствия.Снятие индексации с реквизита (если это возможно):
В некоторых случаях, если индексация проблемного поля не является критичной для производительности запросов или логики работы системы (например, это поле редко используется для поиска или сортировки), мы можем отключить индексацию для этого реквизита. Однако, будьте осторожны: снятие индексации может повлиять на производительность системы.
Изменение состава индекса:
Этот подход более сложен и обычно применяется к пользовательским индексам или при глубокой переработке типовой логики. Если индекс был создан вручную или является частью сложного механизма, возможно, мы можем пересмотреть его состав, убрав наименее значимые или длинные поля. Однако, для типовых индексов, создаваемых платформой автоматически, этот вариант может быть недоступен или крайне нежелателен, так как может нарушить работу стандартных механизмов.
Обновление платформы 1С:
В некоторых редких случаях ошибка может быть связана с некорректной работой самой платформы 1С или её особенностями при взаимодействии с конкретной СУБД. Установка более новой, стабильной версии платформы (например, 8.3.18.1289 или выше) может содержать исправления для подобных проблем. Мы всегда рекомендуем использовать актуальные и проверенные версии платформы.
После внесения необходимых изменений в конфигурацию:
Сохраните изменения: В конфигураторе сохраните конфигурацию базы данных (меню "Конфигурация" -> "Обновить конфигурацию базы данных").
Повторите процесс обновления: Попробуйте снова запустить процесс обновления на вашей копии базы данных.
Проверьте результат: Если обновление прошло успешно, проведите тщательное тестирование базы на копии, чтобы убедиться в отсутствии других проблем и корректной работе всех механизмов.
Примените к рабочей базе: Только после успешного обновления и тестирования копии, выполните те же шаги по обновлению на основной рабочей базе, предварительно сделав ее свежий архив.
Важно помнить, что любые изменения в структуре базы данных или конфигурации должны производиться очень обдуманно, с полным пониманием возможных последствий для производительности и функциональности системы. Всегда консультируйтесь со специалистами и используйте тестовые среды.