Как исправить ошибку «Попытка вставки не уникального в уникальный индекс» при создании начального образа РИБ в 1С?

← На главную

При формировании начального образа распределенной информационной базы (РИБ) разработчики и администраторы нередко сталкиваются с критической ошибкой платформы: «Попытка вставки не уникального в уникальный индекс», после чего указывается имя таблицы СУБД вида dbo._infoRg25364. При этом попытка найти указанную таблицу в рабочей базе часто заходит в тупик — там таблиц с таким номером попросту нет. Разберем детально, почему возникает эта ошибка, как быстро вычислить виновника среди метаданных и какими способами можно успешно развернуть периферийный узел.

Почему таблица с таким номером есть только в создаваемом образе?

Префикс _infoRg указывает на то, что сбой произошел при заполнении таблицы независимого регистра сведений. Числовой суффикс (в нашем примере 25364) формируется платформой 1С динамически в момент физического создания таблицы в базе данных СУБД. В исходной рабочей базе конфигурация пережила множество обновлений, добавления и удаления реквизитов, поэтому внутренние номера таблиц там совершенно другие. Когда вызывается метод создания начального образа, платформа создает новую чистую базу SQL «с нуля», разворачивает в ней структуру таблиц по порядку следования метаданных и начинает потоковую перегрузку записей. Именно поэтому идентификаторы таблиц в базе-источнике и базе-приемнике не совпадают.

Способ 1. Идентификация проблемного регистра сведений

Чтобы исправить ошибку, сначала необходимо точно выяснить, какому именно объекту конфигурации соответствует сбойная таблица _infoRg25364. Рассмотрим наиболее эффективные пути поиска:

Анализ структуры оставшейся базы образа: если после аварийного завершения база начального образа не удалилась автоматически с сервера СУБД, откроем ее через SQL Server Management Studio. Развернем список колонок таблицы dbo._infoRg25364. По именам полей (например, _Period, _RecorderRRef, а также суффиксам типов данных в полях _Fld...) и их типам данных легко сопоставить таблицу с конкретным регистром сведений в дереве метаданных конфигуратора.
Определение имени через выгрузку конфигурации: развернем абсолютно чистую информационную базу из файла конфигурации (.cf) рабочей базы на том же сервере СУБД. Порядок создания таблиц платформой будет аналогичен созданию образа. В этой пустой базе выполним программный код для получения карты соответствия:
```
Структура = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого Стр Из Структура Цикл
    Если Стр.ИмяТаблицыХранения = "_INFORG25364" Тогда
        Сообщить("Проблемный объект: " + Стр.Имя);
    КонецЕсли;
КонецЦикла;
```
Анализ логов SQL Server: при попытке вставки дублирующего ключа СУБД фиксирует ошибку 2601 или 2627 (сообщение вида The duplicate key value is (...)). В теле этой ошибки SQL Server указывает конкретные значения полей, нарушивших уникальность (дату, строку или шестнадцатеричный GUID ссылки). По этим значениям через глобальный поиск или консоль запросов в базе-источнике можно мгновенно локализовать сбойную запись.
Метод исключения объектов: если доступ к СУБД ограничен, можно временно снять признак авторегистрации или исключить регистры сведений из состава плана обмена небольшими группами, повторяя запуск создания образа, пока ошибка не исчезнет.

Шаг 2. Выясняем причины появления дублей и устраняем их

Казалось бы, если регистр сведений в рабочей базе независимый, платформа не должна была позволить записать неуникальный набор измерений. Почему же тогда падает создание образа? Проанализируем типичные причины:

Различия в обработке концевых пробелов и параметров сортировки (Collation): SQL Server при проверке уникальности в строковых полях не различает пробелы в конце строк. Если в рабочей базе в измерении строкового типа были записаны значения "Товар" и "Товар ", платформа 1С в режиме 1С:Предприятие могла считать их разными, но для уникального индекса SQL Server они являются полными дубликатами. При пакетной вставке в новую базу сервер СУБД блокирует операцию.
Скрытое разрушение индексов в рабочей базе: если ранее в рабочей базе происходили аварийные остановки или сбои дисковой подсистемы, индекс таблицы мог физически перестать контролировать уникальность. В источнике дубли уже существуют, а при создании образа платформа строит чистый индекс заново и натыкается на них.
«Битые» ссылки в измерениях: если объект, на который ссылалось измерение, был удален напрямую без контроля ссылочной целостности, платформа может преобразовывать такие записи к одинаковым пустым ссылкам, что приводит к схлопыванию ключа уникальности.

Для поиска дубликатов в выявленном регистре выполним в рабочей базе запрос по группировке всех измерений:


ВЫБРАТЬ
    Номенклатура,
    Характеристика,
    Склад,
    КОЛИЧЕСТВО(*) КАК КоличествоЗаписей
ИЗ
    РегистрСведений.ЦеныНоменклатуры
СГРУППИРОВАТЬ ПО
    Номенклатура,
    Характеристика,
    Склад
ИМЕЮЩИЕ
    КОЛИЧЕСТВО(*) > 1

Для выявления скрытых дублей по строковым полям обязательно дополним проверку вызовом функций обрезки пробелов или сравнением длины строки.

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

Шаг 3. Альтернативные методы создания узла РИБ

Если база имеет внушительный объем, а штатный механизм СоздатьНачальныйОбраз() продолжает падать по таймауту или нехватке памяти, применим проверенные обходные решения.

Вариант А: Исключение регистров сведений на этапе генерации образа. В плане обмена временно исключим из состава проблемный регистр сведений (или все тяжелые регистры). Успешно сформируем начальный образ без них — это гарантирует корректный перенос метаданных и, что критически важно, связей предопределенных элементов конфигурации (иначе при развертывании из .cf первый же обмен породит дубли предопределенных элементов). После развертывания периферийной базы вернем регистры в состав плана обмена и передадим данные порциями через штатные сообщения обмена.

Вариант Б: Развертывание узла напрямую из копии рабочей базы (Backup/Restore). Это самый надежный способ для высоконагруженных баз:

Делаем полную копию рабочей базы средствами СУБД (SQL Backup) и восстанавливаем ее на сервере подчиненного узла.
Заходим в созданную копию в режиме 1С:Предприятие и программно переводим ее в статус подчиненного узла РИБ:
```
ГлавныйУзел = ПланыОбмена.Филиалы.НайтиПоКоду("ЦБ");
ПланыОбмена.УстановитьГлавныйУзел(ГлавныйУзел);
```
В обеих базах (в центре и в новом узле) синхронизируем счетчики сообщений обмена, установив НомерПринятого = 0 и НомерОтправленного = 0.
Если подчиненный узел должен содержать не все данные, лишние документы и справочники очищаются уже непосредственно в периферийной базе специализированными обработками.

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