Вход | Регистрация


1С:Предприятие ::

Метки: 

При загрузке бекапа из SQL не получается программно создавать справочники и документы

Я
   Обфускация
 
28.08.18 - 07:55
При загрузке из SQL не получается программно создавать справочники и документы. Пишет "номер не уникален". При этом в базе, с которой только что делалась копия нет такого. Что с этим делать?
 
 
   shuhard
 
1 - 28.08.18 - 08:18
(0) [Что с этим делать?] 
- перезапустить рпхост
или
- обновить нумерацию глобальным методом
   Обфускация
 
2 - 28.08.18 - 08:31
проблема решилась выгрузкой и загрузкой  dt
   Гипервизор
 
3 - 28.08.18 - 08:35
ОбновитьНумерациюОбъектов
   capllary_surgut
 
4 - 28.08.18 - 08:49
(2) Это если база небольшая, а так да, ОбновитьНумерациюОбъектов самое лучшее решение.
   shuhard
 
5 - 28.08.18 - 08:49
(2) садись - кол (с)
   unregistered
 
6 - 28.08.18 - 09:00
(2) > проблема решилась выгрузкой и загрузкой  dt

Не лучшее решение. Возможно, что при загрузке через dt синхронизируется или обнуляется информация сервиса нумерации в кластере.

Проблема связана с тем, что сервис нумерации объектов предоставляется кластером серверов. Он хранит у себя последний выданный номер для каждого объекта (документа, справочника) в разрезе каждого префикса и владельца (для иерархических справочников с уникальностью в пределах владельца). То есть эта информация храниться не в базе, а в кластере. И при загрузке новой базы эта информация не синхронизируется - в базе выданы одни номера, а кластер хранит информацию о других последних номерах.
Например для документа Х для префикса "РОБП" храниться номер 0002. Ты загружаешь базу, где последний документ Х имеет номер РОБП-0003. Ты пытаешься создать новый документ Х. Сервис нумерации (который думает, что последний выданный номер 0002) выдаёт для него очередной номер - РОБП-0003. Возникает конфликт - документ с таким номером в базе есть.
Так же может возникнуть "дыра" в нумерации, если сервис содержит последний номер 0004, а в базе последний выданный - 0001. Сервис выдаст новому документу номер 0005 и образуется "дырка" - с 0002 по 0004.
В таком случае решение описано в (3) - метод ОбновитьНумерациюОбъектов. Но его надо применить к каждому объекту метаданных, где проблема возникла.
   Обфускация
 
7 - 28.08.18 - 09:08
(6)
Вот попробуй угадай все объекты, где такое возникло. А тут раз и все.
   Гипервизор
 
8 - 28.08.18 - 09:12
(6)(7) Да можно и для всех разом, без указания параметра: ОбновитьНумерациюОбъектов()
   dmpl
 
9 - 28.08.18 - 09:13
(6) Бага, однако.
   Обфускация
 
10 - 28.08.18 - 09:14
ОбновитьНумерациюОбъектов() - куда это вставить чтобы сработало?
 
 Рекламное место пустует
   unregistered
 
11 - 28.08.18 - 09:14
(9) Какая бага?... Всё логично и правильно. Кто же продуктивные базы перезаливает в реальной жизни?
   unregistered
 
12 - 28.08.18 - 09:16
(8) > можно и для всех разом

Я этого не знал. Всегда делал по мере возникновения проблемы для конкретного объекта.
   unregistered
 
13 - 28.08.18 - 09:17
(10) Сделай внешнюю обработку. Там выполни этот метод.
   dmpl
 
14 - 28.08.18 - 09:17
(11) Бага в том, что обновление нумерации не делается автоматом.
   unregistered
 
15 - 28.08.18 - 09:20
(14) > обновление нумерации не делается автоматом

Как ты себе это представляешь? Откуда сервер 1С узнает что на сервере СУБД базу перезалили и надо что-то там обновлять?
   Сияющий в темноте
 
16 - 28.08.18 - 09:24
(15)если бы он проверял уникальный отпечаток файла базы,то мог бы обнаружить,что что то поменялось,просто,в 1с решили,что лишнее программирование не для них
   Гипервизор
 
17 - 28.08.18 - 09:25
(15) Сервер должен надеяться и обновлять каждые 5 минут на всякий случай))
   unregistered
 
18 - 28.08.18 - 09:29
(16) > если бы он проверял уникальный отпечаток файла базы

Как часто он должен это делать?
Как изменяется отпечаток (я просто не владею темой)? Он меняется только при перезаливке базы или подмене файла? А при обычной записи данных в базу отпечаток не меняется?
   unregistered
 
19 - 28.08.18 - 09:30
(17) Обновлять каждый 5 минут что? Все хранящиеся в сервисе нумерации номера?
Боюсь, что это может сказаться на производительности. В высоко нагруженных системах уж точно.
   unregistered
 
20 - 28.08.18 - 09:38
ИМХО, в этом вопросе единственная претензия к 1С, что они не сделали какой-то стандартной обработки. По аналогии с "Управление итогами", "Активные пользователи" и пр. из раздела "Стандартные" меню "Все функции", которые на самом деле являются обычными обработками, написанными на встроенном языке, зашитыми в платформу, и которые можно выгрузить в файл обработки.

То есть загрузил я базу на СУБД, открыл её в предприятии и через "Все функции" - "Стандартные" вызвал обработку обновления нумерации, где можно было бы обновить нумерацию для всех объектов или выборочно.
   dmpl
 
21 - 28.08.18 - 10:13
(15) Он может текущий идентификатор базы там размещать и менять его, например, раз в минуту. Или даже после каждой операции. Не совпало - обновляем нумерацию.
   unregistered
 
22 - 28.08.18 - 11:08
(21) > и менять его, например, раз в минуту

Опять та же проблема - с какой частотой это делать? За одну минуту можно записать несколько тысяч объектов одного вида. Хотя для рассинхронизации номеров достаточно всего одного документа.
Делать это после каждой операции - сомнительное решение.
Неминуемо возникнут блокировки на ожидании. Огромное количество операций выполняется параллельно и в разные таблицы БД, не мешая друг другу, каждый в своей транзакции. Один документ записывается мгновенно, а другой проводится может несколько минут. А тут единый для всех идентификатор и все будут ждать когда долго проводящийся документ запишется. Выносить же обновление идентификатора за рамки транзакции рано или поздно приведёт к рассинхронизации.

Ну и проверка этого идентификатора. Как часто её делать? И кто даст гарантию, что в выбранном интервале не изменилось состояние нумераторов?

Единственным альтернативным вариантом тут могло бы быть хранение номеров в таблицах базы данных. Но это лишние таблицы (отдельная на каждый нумеруемый объект метаданных) и опять таки вопрос блокировок этих таблиц при параллельной записи большого количества объектов одного вида.
   zva
 
23 - 28.08.18 - 11:15
(20) Единственная претензия к 1С, что до определенного релиза платформы при разворачивании бекапа SQL проблемы с нумерацией не возникало...
   Cyberhawk
 
24 - 28.08.18 - 11:17
(22) "опять таки вопрос блокировок этих таблиц при параллельной записи большого количества объектов одного вида" // Так при такой записи и сервис нумерации тоже "блокируется" каждым запросом на выдачу очередного номера
   Cyberhawk
 
25 - 28.08.18 - 11:18
Просто видимо сервис нумерации, сидящий в оперативной памяти, обрабатывает обращения к нему быстрее, нежели обращение к какой-нибудь служебной табличке СУБД
   dmpl
 
26 - 28.08.18 - 14:36
(22) За 1 минуту вы сможете базу подменить так, чтобы незаметно было?
   MM
 
27 - 28.08.18 - 14:59
(22) Думаю, достаточно считать все нумераторы в БД не актуальными при входе первого пользователя. Сомневаюсь, что найдётся умник восстанавливающий базу при работающих пользователях.
   vde69
 
28 - 28.08.18 - 15:26
(15) вообще типовые это умеют определять, и там форма вопроса есть типа - это копия или базу перенесли, если говоришь - копия отключаются обмены...

логично это туда же встроить
   Cyberhawk
 
29 - 28.08.18 - 15:56
(28) Механизм определения перемещения / восстановления БД, реализованный в БСП, конечно же не работает во всех случаях.
Проще говоря, базу средствами СУБД можно восстановить так, что никто ничего не заметит.
   vde69
 
30 - 28.08.18 - 15:59
(29) механизм запоминает имя базы субд, при переносе имя базы меняется и все отлично распознается,

я этот механизм придумал лет 10 назад, а потом его "придумали" в 1с с небольшими изменениями....
   vde69
 
31 - 28.08.18 - 16:00
(30) единственное чего не сперли у меня - я в название главного окна добавлял "копия"
   Cyberhawk
 
32 - 28.08.18 - 16:09
(30) Во-первых, это ты описываешь простой случай, который более-менее легко диагностируется.
Во-вторых, "механизм запоминает имя базы субд" - это ты в очередной раз "дикуешь".
В-третьих, ты в (28) пишешь "типовые _это_ умеют определять", отвечая на (15), в котором вроде понятным языком написано "базу перезалили", что вроде однозначно трактуется как "имя базы ни в кластере 1С, ни в СУБД не изменилось".
   vde69
 
33 - 28.08.18 - 16:17
базу перезалили от куда?

я думаю - с рабочей копии, в ней имя базы б1, ее залили в базу т1... тут все хорошо...

если заливают с текущей копии, то там сабж вообще не возникнет, так как там не  может быть номеров больше текущего рубрикатора...

пошевели моззгом...
 
 
   Cyberhawk
 
34 - 28.08.18 - 16:29
Абсолютно не важно, какое имя у базы в СУБД. Как Я уже говорил выше, "базу перезалили" = "у базы не изменилось ни имя в кластере, ни имя в СУБД".
И конечно же вторая часть твоего поста - опять, замечу - неверна. Как тебе не пришел в голову вариант, что в некую тестовую базу залили очередной свежий снимок рабочей базы (с более свежими данными и с заведомо большими номерами, чем нумератор выдавал этой базе до заливки)?
   vde69
 
35 - 28.08.18 - 16:36
(34) балин....

есть база рабочая, кластер 1 имя базы 1, в этой базе в константе записано 1.1

при загрузке в тестовый кластер 2 в тестовую базу 2 бекапа с рабочей, мы в константе тестовой получим 1.1, при старте пользака идет проверка которая говорит это кластер 2 база 2 а в константе 1.1 - не порядок, надо спросить пользака, наверно это копию перенесли...
   Cyberhawk
 
36 - 28.08.18 - 16:39
1. Зачем ты описал механизм, реализованный в БСП, не ясно.
2. Уже отказываешься от "механизм запоминает имя базы субд" в (30), заменив это на имя базы в кластере, правильно?
   vde69
 
37 - 28.08.18 - 16:44
(36) де факто и у меня и в бсп хранится урезаная строка подключения...

мне не ясно чего ты хочешь сказать, я говорю - механизм есть ион достаточно надежный, если хочешь аппанировать опиши ситуацию когда это не сработает
   Cyberhawk
 
38 - 28.08.18 - 16:46
Вроде выше все довольно ясно сказано. Ситуация тоже описана.
   vde69
 
39 - 28.08.18 - 16:49
(38) не виду ничего конкретного, только общее бла-бла-бла
   Cyberhawk
 
40 - 28.08.18 - 16:50
Могу только рекомендовать перечитать сообщения
   vde69
 
41 - 28.08.18 - 16:52
(40) понятно, слился...
   Serg_1960
 
42 - 28.08.18 - 16:57
Эх, не о том вы спорите. Автор залил SQL бэкап в существующую базу 1С. Речь о том, что разработчикам хватило ума реализовать функционал и спросить за копию, но не пришло в голову принудительно обновить нумерацию (да и не только это).
   Cyberhawk
 
43 - 28.08.18 - 17:02
(42) Так у автора про копию ничего и не спрашивалось
   Serg_1960
 
44 - 28.08.18 - 17:06
Угу. А ещё автор не озвучил ни платформу, ни конфигурацию. А если, вдруг, у него старая конфа и платформа - то ваш спор - "не в тему" :)
   Cyberhawk
 
45 - 28.08.18 - 17:08
Пока хороший вариант решения описан в (27) - он значительно сокращает вероятность возниконвения таких веток, как текущая
   Serg_1960
 
46 - 28.08.18 - 17:25
(45) Может не стоит придумывать "защиту от дурака" - это бесперспективно? :)

(офф) Мне эти диалоги ветки навеяли анекдот "Группа опытных археологов во время раскопок нашла группу неопытных."(цы)
   dmpl
 
47 - 28.08.18 - 18:33
(34) Прям вот так при работающих пользователях взяли и перезалили?
   Вафель
 
48 - 28.08.18 - 18:49
(46) защиту от дурака ОБЯЗАТЕЛЬНО нужно придумывать
   Cyberhawk
 
49 - 28.08.18 - 19:36
(47) Конечно. Какие проблемы в скуле соединения прибить?
 
 Рекламное место пустует
   Cyberhawk
 
50 - 28.08.18 - 19:36
(46) Так это не от дурака - разворачивание базы средствами СУБД в уже зарегистрированную в кластере инфобазу - далеко нередкий сценарий
   unregistered
 
51 - 29.08.18 - 00:12
(33) > базу перезалили от куда?

Простейший пример:
База BD1. Вдруг решили восстановить из копии по состоянию "на час назад". Имя этой резервной копии BD1.

Не поменялось ровным счетом ничего. Механизм БСП никак не определит что что-то изменилось. Имя базы прежнее, имя сервера и кластера прежнее.

БСП-шный механизм подходит исключительно для случая развёртывания копии базы с другим именем или на другом сервере (кластере серверов). Собственно говоря для этого он и придумывался.
   unregistered
 
52 - 29.08.18 - 00:15
(26) > За 1 минуту вы сможете базу подменить так, чтобы незаметно было?

Если базюка маленькая, то легко.
   unregistered
 
53 - 29.08.18 - 00:19
(27) > считать все нумераторы в БД не актуальными при входе первого пользователя.

Интересный вариант. Если бы только не глюки кластера, в котором бывают зависшие сеансы пользователей.
На СУБД выводишь базу в офлайн, загружаешь в неё копию, включаешь олайн, и .... первого пользователя нет, т.к. в кластере есть висящий сеанс, который можно прибить только остановив кластер и прибив папку scntx.... в папке реестра кластера серверов 1С.
   unregistered
 
54 - 29.08.18 - 00:24
(42) > не пришло в голову принудительно обновить нумерацию

Так в том и вопрос - как определить момент для "обновить нумерацию". Что должно быть признаком необходимости сделать это?

Все озвученные тут варианты нельзя назвать идеальными и однозначно и гарантированно решающими проблему.
ИМХО, эта проблема относится к разряду тех, которые лучше не решать вовсе (оставив только костыль в виде метода платформы ОбновитьНумерациюОбъектов), чем пытаться придумать какие-то другие костыли, которые будут работать от случая к случаю - то сработало, то нет, то сработало, когда не нужно.
   unregistered
 
55 - 29.08.18 - 00:34
(24) > при такой записи и сервис нумерации тоже "блокируется" каждым запросом на выдачу очередного номера

Время блокировки сервиса значительно меньше. У него своя база, свои транзакции, никак не связанные с транзакциями СУБД. В базе транзакция записи и проведения документа могла висеть несколько минут, а в сервисе транзакция отработала почти мгновенно - запрос на выдачу следующего свободного и запись нового занятого номера.

Хотя для подобных рассуждений надо точнее знать - как устроен сервис нумерации...
   vde69
 
56 - 29.08.18 - 08:22
(51) если продакт откатили "на час назад" то нумерация от этого не изменится


смотри
в 13часов был номер 120
в 14часов был номер 150

откатились с 14 часовой на 13 часовую, нумерация спокойно пойдет далше с номера 151, никаких проблемм нет...
   Serg_1960
 
57 - 29.08.18 - 09:36
(56) В данном примере, на первый взгляд,  кроме как "пропуска" номеров, другого негатива не наблюдается. Просто пример не тот. Предлагаю другой пример (на основе твоего):
- в базе удалили документы начиная с 150 по 120 включительно и после этого "откатились". Имхо, возникнет ошибка автора ветки (о дублировании номера 120).
   dmpl
 
58 - 29.08.18 - 09:48
(49) И сервер 1С предприятия этого не заметит? Ну вот и бага - у него соединения прибили, а он ни сном, ни духом. Дело-то житейское...
   dmpl
 
59 - 29.08.18 - 09:50
(52) Ну значит платформа пусть ставит смену каждую секунду на маленькой базе.
   vde69
 
60 - 29.08.18 - 09:53
(57) не возникнет, при удалении документов нумератор не откатится назад сам, единственное такое будет если после удаления обновят нумиратор програмно, но это уже экзотика
   vde69
 
61 - 29.08.18 - 09:57
кстати на основе этой ветки я себе в сервесной базе скрипты сделаю для запуска после копирования,

в скрипте сделаю
1. обновление нумерации
2. изменение заголовка
3. отключение обменов и почты

может еще чего...

в целом ветка для меня полезная
   Cyberhawk
 
62 - 29.08.18 - 10:00
(58) А на что повлияет, заметит он это или не заметит? Допустим, он заметил. Что предлагаешь в этом случае делать?
   unregistered
 
63 - 29.08.18 - 10:42
(56) > если продакт откатили "на час назад"...

Усложним задачу. Откатили на час назад от часа Х, а потом решили откатиться на копию на полчаса от часа Х (то есть более позднюю). В промежутке между этими событиями обновили сервис нумерации.

Короче говоря. Повторюсь. Все предложенные варианты не дают однозначной 100%-ной гарантии решения проблемы. 99% - да, но всегда найдётся 1% каких-нибудь исключений.
   Cyberhawk
 
64 - 29.08.18 - 10:49
(63) Вроде обновление сервиса нумерации после перезаливки БД дает 100% гарантию, что проблем с нумерацией не возникнет
   Serg_1960
 
65 - 29.08.18 - 11:45
(60) Нет, ну почему "экзотика"? Обычный вариант, один из многих, настройки штатного механизма автонумерации в конфигурации. Судя по всему, автор на него и нарвался.

(63) Вот и я об том же, когда говорил о бесполезности "защиты от дурака" когда речь об специалистах идёт - жизнь подкидывает много вариантов. "Дураков не становится больше - они просто становятся более активные" ;)

PS: и да, "защита от дурака" - это только термин такой, не принимайте близко к сердцу и на свой счет.
   dmpl
 
66 - 29.08.18 - 15:22
(62) Очистить все кешированные данные.



Список тем форума
Рекламное место пустует Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует