У одного из клиентов во время обновления конфигурации базы данных возникла ошибка «Для одного ссылочного кода существует более одной таблицы в базе данных».
В процессе обновления информационной базы произошла критическая ошибка по причине: Ошибка SDBL: Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных. Имена таблиц с кодом 26630: DocumentChngR26630, InfoRg26630 Имена таблиц с кодом 26634: Const26634, InfoRgChngR26634 Для исправления проблемы вы можете обратиться в службу технической поддержки.
Данная ошибка не так давно обсуждалась на партнерской конференции Задвоение номеров таблиц на SQL-сервере при добавлении в конфигурацию новых объектов.
Кроме того данная ошибка уже исправлена версиях платформы 8.3.12.1924, 8.3.13.1865, 8.3.14.1694, 8.3.15.1489.
Содержание
- Как возникает проблема и как ее избежать
- Как устранить проблему
- Определение проблемных объектов
- Определение жертвы
- Удаление метаданного
- Реструктуризация таблиц информационной базы
- Восстановление метаданного и данных
- Когда конфликтующие метаданные одинаковы
Как возникает проблема и как ее избежать
Воспроизведение достаточно простое:
- Делаем резервную копию ИБ средствами СУБД;
- Добавляем в ИБ объект конфигурации. В СУБД будет добавлена таблица с типом объекта и ссылочным кодом. Например _DocumentChngR26630;
- Восстанавливаем ИБ средствами СУБД из резервной копии созданной в пункте 1;
- Добавляем в ИБ объект конфигурации отличный от добавленного в пункте 2. В СУБД будет добавлена таблица с типом объекта и дублирующимся ссылочным кодом. Например _InfoRg26630;
Как результат дальнейшее обновление конфигурации базы данных прерывается с указанной ошибкой.
Данный сценарий вполне можно получить при работе в тестовом контуре, выполняя обновлениие тестовой ИБ данными резервной копии продуктивной ИБ.
Для избежания данной проблемы необходимо выполнить перезапуск сервера 1С:Предприятия сразу после восстановления ИБ из резервной копии средствами СУБД, или работать на версиях платформы начиная с 8.3.12.1924, 8.3.13.1865, 8.3.14.1694, 8.3.15.1489.
Но если счастье уже наступило ошибка уже имеется в наличии, то исправлять придется самостоятельно.
Как устранить проблему
Казалось бы, необходимо только восстановить порядок в ссылочных кодах. Первым на ум приходит вариант с выполнением реструктуризации таблиц информационной базы из меню Тестирование и исправление, но оно не помогает.
Определение проблемных объектов
Для этого воспользуемся методом ПолучитьСтруктуруХраненияБазыДанных(), точнее напишем небольшой кусочек кода:
СтруктураХраненияБазыДанных = ПолучитьСтруктуруХраненияБазыДанных(); Для Каждого ЭлементСтруктуры Из СтруктураХраненияБазыДанных Цикл Сообщение = Новый СообщениеПользователю; Сообщение.Текст = СтрШаблон("ИмяТаблицыХранения: %1, Метаданные: %2", ЭлементСтруктуры.ИмяТаблицыХранения, ЭлементСтруктуры.Метаданные); Сообщение.Сообщить(); КонецЦикла;
В полученном тексте найдем записи с указанными таблицами в сообщении об ошибке
ИмяТаблицыХранения: DocumentChngR26630, Метаданные: Документ.CRM_ШаблонЭтапаКалендарногоПлана ИмяТаблицыХранения: InfoRg26630, Метаданные: РегистрСведений.СостоянияБлокировкиВычетаНДСПоСчетамФактурам ИмяТаблицыХранения: Const26634, Метаданные: Константа.CRM_ПарольПользователяСинхронизацииiCRM ИмяТаблицыХранения: InfoRgChngR26634, Метаданные: РегистрСведений.СостоянияБлокировкиВычетаНДСПоСчетамФактурам
Из полученного видно, что РегистрСведений.СостоянияБлокировкиВычетаНДСПоСчетамФактурам конфликтует с Константа.CRM_ПарольПользователяСинхронизацииiCRM и Документ.CRM_ШаблонЭтапаКалендарногоПлана.
Определение жертвы
Теперь необходимо исходя из наполнения ИБ и важности объектов решить какой из них удалить. В разбираемом примере РегистрСведений.СостоянияБлокировкиВычетаНДСПоСчетамФактурам оказался пуст, его и будем удалять.
Если объект содержит данные, тогда необходимо обеспечить возможность возвращения данных в исходное состояние. Например обработкой из инструментов разработчика ВыгрузкаЗагрузкаДанныхXML выполнить выгрузку данных в файл.
Удаление метаданного
Если метаданное стоит на поставке, тогда необходимо снять его с поставки. Для этого перейдем в меню Конфигурация — Поддержка — Настройка поддержки, в дереве матаданных найти необходимый объект и установить правило поддержки Объект снят с поддержки и установить признак Установить для подчиненных.
Теперь необходимо выполнить попытку удаление. Если на объект есть ссылки, то выведется сообщение об нерешенных зависимостях: “Объект не может быть удален, так как на него имеются ссылки в других объектах”.
Объект "РегистрСведений.СостоянияБлокировкиВычетаНДСПоСчетамФактурам" использован в: ПодпискаНаСобытие.ПолныйРегистрацияНабора.Источник ПодпискаНаСобытие.ПроверитьДатуЗапретаИзмененияПередЗаписьюНабораЗаписей.Источник ПодпискаНаСобытие.СОтборамиРегистрацияНабора.Источник ОпределяемыйТип.ВладелецЗначенийКлючейДоступаНаборЗаписей.Тип Документ.БлокировкаВычетаНДС.
Заходим в каждый из них, убираем ссылки, после удаляем сам объект.
Теперь, если все выполнено правильно, обновление конфигурации базы данных пройдет без проблем.
Реструктуризация таблиц информационной базы
Но это еще не конец. Если сейчас вернуть конфигурацию к начальному ее состоянию, то ошибка повторится. Для избежания повторения необходимо выполнить рекструктуризацию таблиц информационной базы.
Для этого необходимо перейти в меню Тестирование и исправление, и выполнить реструктуризацию таблиц информационной базы.
Восстановление метаданного и данных
Теперь настала пора вернуть конфигурацию к ее начальному состоянию. Удаленный объект, и ссылки на него в других объектах возвращаются путем сравнения и объединения с сохраненной ранее конфигурацией или конфигурацией поставщика .
Если в удаляемом объекте были данные, тогда необходимо выполнить их восстановление, например обработкой из инструментов разработчика ВыгрузкаЗагрузкаДанныхXML.
Собственно все! Таким нехитрым способом устранили ошибку «Для одного ссылочного кода существует более одной таблицы в базе данных».
Может возникнуть ситуации, когда конфликтующие метаданные одинаковы. Ошибка характерна для планов видов расчета. Для исправления необходимо в проблемный план видов расчета добавить любой реквизит и обновить конфигурацию ИБ, произойдет реструктуризация, после чего проблема исчезнет. После исправления не забываем удалить реквизит, если он не нужен.
Данная ошибка может возникнуть даже при разворачивании пустой ИБ из шаблона поставки ЗУП 2.5 или УПП.
12.07.19 — 11:24
https://prnt.sc/odyu10
Начало возникать после сбоя во время обновления.
База работает.
Сообщение выдаёт только при изменении структуры метаданных. Если просто код меняем, даёт сохранить-обновить.
Посмотрел через структуру, что это за таблицы — планы видов расчета. При этом ничего криминального не видно. В копии видно то же самое.
https://prnt.sc/odyukx
В обед попробуем перезагрузить сервера и почистить кэш на сервере.
Пока хочу спросить совета, если не поможет.
п.с. ТИИ и чекдбф не предлагать. База большая, пользователей много, выгонять пользователей на полдня не вариант.
1 — 12.07.19 — 11:33
2 — 12.07.19 — 11:35
(1) сорян)
Платформа 8.3.15.1489
Также посмотрели скулёвые базы. Все в наличии, выглядят норм, навскидку визуально совпадают с базами из копии.
3 — 12.07.19 — 11:36
(1)
Насчёт ссылки:
«У Вас нет доступа к «Партнерской конференции». «
4 — 12.07.19 — 11:43
5 — 12.07.19 — 11:46
(3) тогда https://bugboard.v8.1c.ru/error/000051158
В клиент-серверном варианте в базе данных, восстановленной из резервной копии средствами СУБД, может происходить нарушение нумерации таблиц и, как следствие, неработоспособность информационной системы.
Способ обхода:
После восстановления базы данных из резервной копии средствами СУБД перезапустить кластер.
*Ищите рабочий бэкап.
6 — 12.07.19 — 14:15
(4)
один в один. Спасибо
7 — 19.07.19 — 06:37
(5) После восстановления базы данных из резервной копии средствами СУБД перезапустить кластер.
Это как перезапустить сервер-1С?
8 — 28.07.19 — 09:44
Уважаемый Bibr, удалось забороть проблему?
9 — 31.07.19 — 04:38
(0)
Здравствуйте! Не могли бы вы подсказать как просмотрели структуру базы данных?
Возникла на такой же платформе(8.3.15.1489), эта же ошибка (Ошибка SDBL)… Новенькая в этом деле, пытались перезагрузить сервер и кэш, и откатывать до рабочей версии, до внесения изменений, все равно выскакивает ошибка.
10 — 31.07.19 — 08:20
Мне техподдержка 1С посоветовала провести ТИИ с флажком реструктуризации. В выходные буду делать, о результатах отпишусь
11 — 31.07.19 — 08:29
(9) да, при переходе на новую платформу обязательно тии делайте. А если файловая база, то вообще делайте тии раз в неделю, по пятницам. Даже если платформа нее меняется.
12 — 31.07.19 — 10:16
(10) (11)
Благодарю, Уже процесс запущен:)
(10) Будем ждать результатов, надеюсь у Вас все будет отлично
13 — 01.08.19 — 22:10
(12) На тестовой получилось. Итак, решение: ТИИ с флажком реструктуризации (я ставил 1 этот флажок)
14 — 01.08.19 — 22:18
Это ошибка последних версий платформы.
Для работы со старыми конфигурациями понизьте релиз до 8.3.13.1865.
15 — 02.08.19 — 14:01
(14) Когда по правят?
16 — 02.08.19 — 14:12
(14) У меня на 8.3.13 ошибка проявлялась, вылечилась ТиИ с реструктуризацией.
17 — 27.08.19 — 16:01
(0) короче на КА при установке 8.3.15 при обновлении вылезла такая же штука, это проблема платформы, помогло:
создание новой базы на 8.3.12, загрузка туда dt , и уже обновление платформы на 8.3.12
Если этот же dt загружать на 8.3.15, то вылазиет именно эта ошибка
18 — 21.09.19 — 14:59
Спасибо всем, кто подсказал про тестирование и исправление, после этого обновление пошло, как по маслу, а до этого мучилась, платформы меняла 2 недели!
19 — 02.10.19 — 10:24
20 — 24.10.19 — 23:38
зарегился, чтобы Клизме спасибо сказать! (17)
21 — 25.10.19 — 00:31
Всё проще, для ошибки как в (0) надо в плане вида расчета добавить реквизит, сохранить конфу — тогда обновление пройдет, потом прибить реквизит.
Там 2 плана — управленческие начисления и начисления по организации.
Усё.
А запуск ТиИ с реструктуризацией, на большой базе, это можно и не дождаться. Да и не надо.
rphosts
22 — 25.10.19 — 02:11
(21) +100500/ только сначала всё повторить на копии. Для тех кто в танке, копию делать не через выгрузку DT.
Описана методика исправления ошибки путем внесения изменений в sql-таблицы.
Отказ от ответственности: вы все здесь взрослые и делаете всё на свой страх и риск. Да, и ещё: лицензионное соглашение не разрешает вам это делать, поэтому данное описание дано для образовательных целей.
После перехода с 8.3.12 на 8.3.15 словили неприятную ошибку «Для одного ссылочного кода существует более одной таблицы в базе данных». Самое неприятное, что ошибка стала вылезать и на типовых базах, которые никто никогда не трогал.
Гугл ничего не дал кроме стандартных «почистить кэш, перерегистрировать базу в кластере, выполнить ТИИ». Ну и еще «добавить реквизит к объекту и обновить БД» (этот пункт не пробовал, напишите в комментариях — вдруг это самый простой метод в комментариях к этой статье есть сообщение что метод сработал на 8.3.16.1030, пробуйте).
На партнерке есть пара веток, в т.ч. https://partners.v8.1c.ru/forum/topic/1792992, из которой приведу пару цитат:
Воспроизводится так (проверено на релизе 8.3.13.1644 / SQL 2023):
1. Создаём две базы test1 и test2
2. Запускаем конфигуратор test1, добавляем справочник, обновляем конфигурацию. В базе добавляется таблица _Reference21
3. Делаем SQL бэкап базы test1 и восстанавливаем его в test2.
4. Запускаем конфигуратор test2 и добавляем документ, обновляем конфигурацию. В базе видим таблицы: _Reference21 и _Document21.
Помогает перезапуск rmngr.exe после восстановления test2 из бэкапа.
И ответ представителя фирмы 1С:
Да, действительно, в этом сценарии две таблицы получают два одинаковых ссылочных номера.
Это ошибка, будет исправлена в одной из следующих версий.
Что можно сказать по этой ошибке. Во-первых, чистка кэша не поможет. Во-вторых, ошибка воспроизводится только если было хотя бы одно добавление объекта метаданных до восстановления из резервной копии (это приводит к инициализации сервиса в менеджере кластера, и как следствие — сохранению значения последнего номера таблицы).
Рекомендации на сейчас (до выхода версий с исправлением) по обходу ошибки: сразу после восстановления ИБ средствами СУБД — производите перезапуск сервера платформы.
Я провел тест на 8.3.12 — проблема по методике первой цитаты воспроизводится. Так что делаю выводы:
1) проблема с задвоением внутренней нумерации объектов существовала очень давно, как минимум с 8.3.12, но лишь в 8.3.15 добавили проверку (понятно) и запрет применения изменений (а вот тут явно не подумали что у пользователей много таких «поломанных» баз)
2) по-идее, можно жить спокойно на релизах менее 8.3.15 и ждать манны небесной от фирмы 1С.
Ну а нам ждать «одной из следующих версий» нельзя. Базы разработчиков «встают» одна за другой на этой ошибке. Я предлагал откатиться на 8.3.13 или 8.3.14 — но согласился пробовать найти свое решение, т.к. когда будет эта «манна» — неизвестно. А если продолжить использовать «старые» релизы — то дубли нумерации скорее всего будут только плодиться, хоть мы их и не будем видеть.
Размышления привели к пониманию того, что надо найти «где в базе хранится сопоставление таблиц sql и объектов конфигурации». Как оказалось таких мест два: таблица DBSchema и реквизит DBNames таблицы Params.
Попытка получить DBSchema использованием SQL Management studio завершилась неудачей: в режиме ssms получается получить лишь первые 65КБ двоичных данных, хранящихся в таблице, и при вставке в hex-редактор получаем неполную структуру.
А уж DBNames и вовсе хранится в сжатом виде. Поэтому усилия были перенаправлены на поиск инструмента для редактирования этих данных. И он был найден: Восстановление структуры DBSchema
Стоимость инструмента — 10sm (Мопед не мой!). Впрочем, описанная ниже методика не зависит именно от этой обработки; можете поискать аналог или написать свою. Функционал указанной обработки используется только в части выгрузки DBSchema и DBNames из sql в файл и обратно.
А я опишу методику лечения баз:
- рекомендуется использовать Notepad++ или аналог. В отдельном файле открыть текст ошибки из конфигуратора.
- запустить обработку, получить DBSchema (схема — список объектов — распознать схему) и DBNames (вверху «загрузить из БД в файл»), выгрузить обе структуры в файлы, указав вверху пути и нажав на кнопки рядом. Открыть файлы в Notepad++. Должно получиться примерно следующее (слева DBNames, справа — DBSchema):
- из текста ошибки для каждой пары объектов выбрать «жертву»; проще менять номер у констант или регистров, т.к. на них обычно нет ссылок в реквизитах других объектов. Желательно выбирать в таком качестве «таблицы изменений» вида _ConstChngR2346 или _DocumentChngR3078 не имеющие табличных частей (у нет таблиц вида Document750.VT20237 или _Reference49197_VT3332).
- в DBNames находим строку жертвы по номеру объекта, переносим строку в конец файла, меняем номер объекта (+1 к предыдущему)
- в файле с текстом ошибки к номеру «жертвы» добавляем «-НовыйНомер»
- в DBSchema находим объект, меняем номер объекта (в третьем параметре); ищем все вхождения имени объекта (например Reference3048) — ссылки на этот объект в реквизитах других объектов — выполняем замену например Reference3048 на Reference49189.
- в DBNames первый параметр меняем на новый максимальный номер объекта
- сохраняем файлы, считываем их обработкой (вся схема — текст — прочитать схему из файла, Имена — Прочитать DBNames из файла), выгружаем из обработки в БД
- пишем sql-код для переименования всех таблиц вида:
EXEC sp_rename _Enum3066, _Enum49200
EXEC sp_rename _Enum3067, _Enum49201
EXEC sp_rename _DocumentChngR3078, _DocumentChngR49202и выполняем его. Если все-таки жертвой был справочник с табличной частью — во всех табличных частях надо переименовать ссылку
EXEC sp_rename '_Reference49197_VT3332._Reference3048_IDRRef', '_Reference49197_IDRRef', 'column'- после выполнения указанных действий также рекомендую удалить-добавить базу в кластере.
Хотя от представителя 1с на партнерском форуме есть альтернатива — рекомендация перезапускать сервер — в комментариях (7) к данной статье коллега отписался о неэффективности этого метода.