Ситуация, когда информационная база успешно выгружается в файл .dt, но отказывается загружаться на другой сервер (чаще всего под управлением MS SQL Server), является одной из самых неприятных в практике администратора 1С. Основная сложность заключается в том, что ошибка возникает на этапе создания индексов, когда данные уже частично загружены, и стандартные средства восстановления могут быть недоступны. Разберем подробно причины возникновения этой проблемы и методы ее решения на основе практического опыта.
Для начала проанализируем, почему возникает сообщение "Нарушено условие уникальности данных. Попытка вставки неуникального значения в уникальный индекс". При загрузке данных из формата .dt платформа 1С выполняет следующие действия:
CREATE UNIQUE INDEX для создания уникальных индексов, предусмотренных метаданными.Если в процессе эксплуатации информационной базы в нее (из-за сбоев транзакций, некорректной работы расширений или динамического обновления) попали дублирующиеся записи, SQL-сервер не позволит создать уникальный индекс и прервет транзакцию загрузки. При этом в обычной работе базы (если она была развернута из SQL-бэкапа .bak) эта проблема может не проявляться, так как индексы уже существуют и просто блокируют запись новых дублей, но "старые" дубли могут годами храниться в таблицах, если они попали туда в обход механизмов контроля.
В тексте ошибки часто упоминаются системные таблицы, такие как _InfoRg3468 или _InfoRg3473. В конфигурациях на базе БСП (Библиотека стандартных подсистем) это чаще всего регистры сведений (поможет автоматическая диагностика и очистка битых записей в регистрах):
Как показывает практика, наиболее надежным (хотя и длительным) способом решения проблемы является использование встроенного механизма "Тестирование и исправление". Рассмотрим последовательность шагов, которая помогла автору темы:
Проанализируем ситуацию: если база большая, запуск полного ТиИ может прерваться из-за нехватки ресурсов или превышения лимита времени. Поэтому мы будем действовать итерационно.
.bak), так как в ней данные доступны, несмотря на логические ошибки.Тестирование и исправление со следующими настройками:
После того как ТиИ будет пройдено до конца без ошибок, выполним выгрузку в .dt и попробуем загрузить его на целевой сервер. Если ошибка повторяется, но с другим именем таблицы — это признак того, что мы постепенно очищаем базу от "мусора".
Рассмотрим более быстрый способ, если мы точно знаем имя проблемной таблицы из текста ошибки (например, _InfoRg3468). Выясним, какому объекту метаданных она соответствует. Для этого можно воспользоваться функцией платформы:
Сообщить(ПолучитьСтруктуруХраненияБазыДанных().Найти("ИмяТаблицыВSQL", "ИмяТаблицыХранения").Метаданные);
Выяснив, что это за регистр, проанализируем его содержимое в исходной базе (которая работает в SQL). Нам нужно найти записи, у которых совпадают все измерения (ключ записи). Рассмотрим пример запроса для поиска дублей в абстрактном регистре:
ВЫБРАТЬ
Регистр.Измерение1,
Регистр.Измерение2,
КОЛИЧЕСТВО(*) КАК КоличествоДублей
ИЗ
РегистрСведений.ПараметрыРаботыРасширений КАК Регистр
СГРУППИРОВАТЬ ПО
Регистр.Измерение1,
Регистр.Измерение2
ИМЕЮЩИЕ
КОЛИЧЕСТВО(*) > 1
Проанализировав результат, мы увидим записи, которые мешают созданию уникального индекса. Эти записи необходимо удалить программно (в этом поможет обработка очистки регистров от некорректных записей). В случае с системными регистрами БСП, такими как Идентификаторы объектов метаданных, лучше использовать специализированные инструменты.
Если проблема локализована в регистрах идентификаторов, рассмотрим применение встроенных функций БСП. Посмотрим на алгоритм действий:
ОбновлениеИнформационнойБазы.epf (часто входит в состав дистрибутива конфигурации) или перейдем в раздел "Администрирование" -> "Обслуживание" -> "Результаты обновления программы".
Справочники.ИдентификаторыОбъектовМетаданных.ВыполнитьОбновлениеДанных();
Часто причиной нарушения уникальности становятся расширения, которые добавляют свои поля в уникальные индексы стандартных таблиц. Выясним, не в этом ли причина. Попробуем следующий подход:
.dt) удалим все расширения конфигурации. Важно: это приведет к потере данных, хранящихся в этих расширениях. Если данные критичны, этот метод использовать нельзя!.dt на другую СУБД (например, PostgreSQL), выполнение там полного тестирования и исправления, и повторная выгрузка в .dt для MS SQL.В процессе загрузки .dt может возникнуть ошибка Transaction was deadlocked on lock resources with another process. Проанализируем причины:
.mdf и .ldf в реальном времени.Для решения разберем следующие шаги: временно отключим Full-Text Search в настройках базы 1С, добавим файлы базы данных в исключения антивируса и убедимся, что во время загрузки к базе нет сторонних подключений через SSMS или другие утилиты.
Подводя итог, отметим: ошибка уникальности при загрузке .dt — это всегда следствие накопленных логических ошибок в структуре данных. Наиболее эффективным и безопасным методом остается многократное итерационное Тестирование и исправление исходной базы с обязательной проверкой логической целостности расширений. Если же время ограничено, следует переходить к точечному поиску дублей в таблицах SQL и их программному удалению средствами встроенного языка 1С — для этого подойдёт готовый набор обработок для удаления дублей и очистки регистров.