Ошибка динамического обновления 1с

Обновлено: 07.07.2024

Поводом к написанию данной статьи, послужило падение базы во время сохранения конфигурации, при динамическом обновлении. Казалось бы сколько уже раз предупреждали - «Не делайте динамическое обновление на 8.2!», но иногда, без него просто не обойтись.

«Внимание. При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» «Да, Нет»

«Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.»

И после нажатия на кнопку «Ок» это окно закрылось вместе с конфигуратором. Вот тут-то я и начал подозревать, что все будет не так просто.

Бэкап, конечно же имелся, но с одним нюансом - больше чем за половину дня, 2000 пользователей, сделали кучу документов и прочей полезной работы, а бэкап был только по состоянию на утро, да и восстановление базы, размером более 100 Гб, занимает ну очень продолжительное время.

Продолжая копать глубже, я узнал, что все дело в "испортившихся" таблицах dbo.Config и dbo.ConfigSave .

Итак, отставить панику!Проверяем есть ли у нас конфигурация идентичная рухнувшей. В моем случае, их было целых 4, так как работаем через Хранилище Конфигурации. Можно использовать и не совсем идентичную конфигурацию, но будьте готовы к тому, что тогда все изменения придется вносить заново (если конечно у вас нет Хранилища Конфигурации).

Далее заходим в SQL Management Studio и очищаем таблицы dbo.Config и dbo.ConfigSave рухнувшей базы с помощью нехитрого запроса (для того чтобы его написать, нажмите "New Query" или "Новый Запрос", ну а чтобы выполнить - "Execute" и "Выполнить" соответственно):

Все, теперь осталось "залить" эти же таблицы из хорошей конфигурации. Как я уже написал выше, способ предложенный VanDiesel1 мне не помог, так как рабочая база и все базы с хорошими конфигурациями, находились в разных кластерах. Почитав мануал к SQL Management Studio, я наткнулся на такую возможность, как импорт таблиц из одной базы в другую и незамедлительно решил ей воспользоваться. Итак в SQL Management Studio становимся на испорченную базу и щелкаем правой кнопкой мыши, далее Tasks -> Import Data.

Откроется визард в котором:

На второй странице указываем сервер и базу из которой мы будем брать данные.
На третьей указываем базу приемник.
На четвертой выбираем "Копировать данные из таблиц".
На пятой отмечаем галками таблицы dbo.Config и dbo.ConfigSave.
На шестой смотрим, чтобы не было ошибок и процесс загрузки прошел успешно.

Вот собственно и все, можно пробовать запускать 1С.

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

Надеюсь эта статья, кому-нибудь поможет сэкономить время и нервы. Также напоминаем что в нашем облаке 1С имеется бесплатное резервное копирование, которое защитит Вас от потери данных.

Работаю с обработкой или общей формой . Меняю значение реквизита / меняю код добавляю новые процедуры или функции.. Т.е. все как обычно. Делаю динамическое обновление программы. У всех пользователей которые зашли после обновления все изменения работают. Все как надо. Я не закрываю конфигуратор. 1 закрываю объект с которым работал . открываю его опять и там все как было до изменения. Конфикоратор говорит что база не изменялась, но если я запущусь в режиме отладки то все внесенные изменения ранее пропадают. . Если перезапустить конфигуратор - все становится на свои места. Изменения появляются. Но после любого изменения и динамического обновления опять откат. кто сталкивался? как лечится?

(0) 8.3.10.2466 - у меня пару раз было подобное безо всякого динамического обновления. Вылечил ребутом тестового сервера -
аптайм был где-то 3 недели, а авторебута не было.
Конфикоратор глюкнуло от демонического обновления.
остановить 1с(если клиент-сервер, то сервер тоже). дропнуть кэш(если клиент-сервер, то сервер тоже). запустить 1с(если клиент-сервер, то сервер тоже).

"Здравствуйте, меня зовут Алексей и я делаю динамическое обновление.
Раньше, я делал динамическое обновление по три или даже целых пять раз в день.
Я мог не спросить пользователей, не сделать бекап средствами СУБД и динамически обновить базу ради изменения макета печатной формы счета на оплату.
Но потом случилось горе и в одно прекрасное обновление база просто не запустилась.
Это был ч0рный день в моей жизни.
Я потерял друзей, коллеги отвернулись от меня.
Жена меня бросила и дети не хотят со мной разговаривать.
Попа болела после долгого и многозначительного разговора с начальством.
И я решил изменить свою жизнь.
Я теперь занимаюсь спортом
Стал посещать бассейн.
Питаюсь правильно и соблюдаю правила дорожного движения.
Сегодня у меня праздник.
Я уже 30 дней не делаю динамического обновления без ахивации базы данных средствами СУБД.
Я практически готов полностью отказаться от динамического обновления.
Вообще не обновлять динамически.

Преодолеть зависимость от динамического обновления мне помогли 12 простых шагов:

12 ШАГОВ , РАЗРАБОТАННЫЕ САМИМИ ДИНАМИЧЕСКИМИ ОБНОВЛЯЛЬЩИКАМИ
1. Признать свое бессилие перед поведением платформы 1с при динамическом обновлении.
2. Согласиться с утверждением, что без посторонней помощи не обойтись.
3. Мысленно перепоручить себя некой Высшей силе, которая поможет.
4. Проанализировать свои поступки.
5. Признать перед собой и кем-то еще свои ошибки.
6. Не сомневаться, что бекап перед динамическим обновлением сработает.
7. Просить высшие силы избавить от недостатков.
8. Составить список всех людей, кому причинили зло, и захотеть загладить свою вину перед ними.
9. Лично возместить этим людям ущерб, нанесенный вами и вашим динамическим обновлением.
10. Продолжать самоанализ и, при малейших ошибках, сразу признавать, что вы их таки совершили.
11. Не переставать размышлять и благодарить помощника из пункта 3.
12. Достигнув пробуждения, благодаря пунктам 1-11, помогать другим динамическообновлялщикам.

Примечание.
UUID информационной базы можно посмотреть в файле
C:\Documents and Settings\<Имя пользователя>\Application Data\1C\1Cv81\ibases.v8i.

Часто программисты не учитывают, что есть список объектов, НЕ доступных для динамического обновления
Регламентные задания
Общие реквизиты
Планы обмена
Реквизиты, предопределенные элементы, иерархия, владельцы, нумерация справочников
Реквизиты, нумерация, движения, последовательности, ввод на основании документов
Перечисления
Тип значений характеристик, реквизиты, нумерация, предопределенные элементы планов видов характеристик
Реквизиты, нумерация, субконто, предопределенные элементы планов счетов
Реквизиты, нумерация, расчет, предопределенные элементы планов видов расчета
Реквизиты, регистраторы регистров сведений, накопления, бухгалтерии, расчета
Реквизиты, нумерация, расчет, предопределенные элементы планов видов расчета
Реквизиты, адресация, нумерация задач
Реквизиты, нумерация, ввод на основании бизнес-процессов

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

Если вы работаете с часто изменяемой печатной формой и не хотите постоянно выгонять пользователей, используйте внешние обработки.
Хорошей практикой считается все плановые изменения вносить например раз в неделю, например во вторник. К этому дню все правки тестируются не только по отдельности, но и в общем взаимодействии. Если во вторник информационная система ухудшила свою работу, значит сразу понятно, что надо откатить последний релиз к предыдущему. А это означает бэкап не только базы, но и бэкап cf перед внесением изменений.

Если Вы словили проблему связанную с динамическим обновлением, то обязательно очистите сеансовые данные с рестартом службы сервера 1С.
Если проблема не ушла, то запускайте сеанс 1С с ключом /ClearCache .

Преодолеть зависимость от динамического обновления мне помогли 12 простых шагов:

Механизм работы обновления:
Процесс динамического обновления (и обновления вообще) происходит следующим образом:

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

Преодолеть зависимость от динамического обновления мне помогли 12 простых шагов:

Читайте также: