Итак, имеем: платформа 8.3.10, серверная база, самописная конфа.
В процессе динамического обновления конфигуратор упал с ошибкой формата потока и далее не запускался.
Первым делом попробовал почистить кэш. После очистки конфигуратор запустился с закрытой конфигурацией. При попытке открыть конфигурацию опять -- ошибка формата потока. Ну ок, поскольку конфигуратор все-таки запустился, попробовал выгрузить dt. Как ни странно, получилось. А вот дальше интересное. Сначала попробовал загрузить dt в новую свезесозданную базу. Всё сработало, открывается и предприятие, и конфигуратор и конфигурация. Загружаю в старую базу -- облом. Предприятие запускается, конфигуратор запускается, но при попытке открыть собственно конфигурацию -- ошибка формата потока. Попробовал базу на сервере удалить и создать заново -- та же фигня. Казалось бы, можно плюнуть и работать в новой базе, но пользователей дофига, территория большая, и админам страшно не хочется оббегать всех и перепрописывать базу. Куда ещё можно покопать, чтобы заставить базу работать под старым именем?

(0) демоническое обновление до добра не доводит)

(1) Да вот сто лет уже не сталкивался с проблемами от него, и на тебе.

тема ошибок при динамическом обновлении обсуждалась на этом форуме десятки раз. нет смысла повторять.
так что Вам в поиск.

Чем старее платформа, тем выше вероятность ошибок, хотя слишком свежие релизы тоже чреваты...

(0)

truncate table [dbo].[Config]
go
insert into [dbo].[Config] select * from [Copy].[dbo].[Config]
go

Предупрежу фразу о "лицензионном": А пусть пишут нормально

(0) Сталкивались с подобным, сервер PG был.
Развернули базу из dt в новую конфу. В старой дропнули таблицы config и configsave.
Перезалили из развернутой базы.
Бекапами только обвешайтесь

(6) "Добродетельному человеку можно всё" (Сократ)

(5) А смысл? Я загружал dt полностью из той же копии.

Или хотите сказать, что при загрузке dt таблица config не перезаписывается? Но это же бред.

(10) Содержимое перезаписывается. Она походу не пересоздается когда 1с грузит дт и в базе есть таблица config.

(11) Понял. Ок, попробую.

1С рекомендует делать бэкапы средствами субд

(2) >> сто лет уже не сталкивался с проблемами от него, и на тебе.

Уж сколько раз твердили миру...
С динамическим обновлением всегда так. Сто лет по десять раз в день никаких проблем, а потом в самый неудачный момент случается косяк.
Рецепт из (5) в 99% случаев спасает. Однако остаётся ещё 0.5%, когда и он не решает проблему. И ещё 0.5%, когда очистка таблиц помогает, но из-за того, что пользователи уже успели поработать с конфигурацией в разных состояниях (у кого-то обновлённая, а у кого-то - не обновившаяся) данные становятся неконсистентными.
Поэтому динамически обновляться нельзя.
Более того. Многие почему-то считают, что расширения помогают решить эту проблему. А это не так. Подключение расширения - есть не что иное как неявное динамическое обновление. И при нём случаются абсолютно те же самые проблемы, что и при обычном динамическом обновлении. И точно так же половина пользователей работают в конфе с подключенным расширением, а половина не перезапускают сеанс и продолжают работать со старой версией конфигурации.

Динамическое обновление и возможность подключать расширения "на лету" - очень заманчивые технологии. Но на практике крайне рискованные. Всегда надо быть готовым к самому негативному из возможных сценариев развития событий. Правильная оценка рисков приводит к единственно верному решению.

Можем обсудить, расширение это явное динамическое обновление или динамическое обновление это неявное расширение. И насколько неявным расширением базы является кэш.
Вопрос в том, достаточно ли инструментов для бакапа, управления сеансами пользователей и существующих сетевых протоколов (а возможно еще что то забыли) для нормальной работы искаропки.
Разве тонкий и веб клиент не решают проблему с динамическим обновлением структуры базы данных?

(15) >> Разве тонкий и веб клиент не решают проблему с динамическим обновлением структуры базы данных?

Интересно - каким образом?...

>> достаточно ли инструментов для бакапа, управления сеансами пользователей и существующих сетевых протоколов (а возможно еще что то забыли) для нормальной работы искаропки.

Бекап не решает проблему.
Пример из личного опыта (версию платформы сейчас не вспомню). База в режиме восстановления, позволяющем откатиться на любой момент времени. Подключили сутра расширение к базе при работающих пользователях. Примерно к обеду заявка на техподдержку с ошибкой формата потока. Начинаем разбираться. В конфигуратор не войти. В пользовательском режиме - кто-то может войти, а кто-то нет. Кто и сколько проработал в какой версии (с подключенным / с неподключенным расширением непонятно). Проблему решили методом очистки таблиц из (5). Но базу пришлось восстанавливать по состоянию на утро (до подключения расширения). А потом долго объяснять пользователям, что всё, что они делали полдня, придётся повторить заново. Хорошо, что речь шла об обычной бухгалтерии, а не о какой-нибудь из оперативных баз.

По поводу остальных инструментов. Всё что нужно есть.
Для установки обновления на продуктив надо всех выгонять из базы. Делаем рассылку по пользователям, устанавливаем блокировку подключения, останавливаем обмены, ставим обновление или подключаем расширение. Только после этого запускаем пользователей.
Если база в режиме 24/7, значит установка обновлений и расширений должна быть исключительно в периоды технологического окна, которые строго регламентированы и планируются заранее. И разумеется эти обновления предварительно тщательно тестируются.

А динамическое обновление только расхолаживает программиста и дает ему возможность гнать не оттестированную лажу в продуктив. Типа "а фигня - если чё - динамически поправлю".
И работает оно без сбоев только в теории. А в жизни постоянно встречаются "нюансы" - то операционная система на клиенте кэш не почистила, то вэб-сервер, то сервер приложения, то пользователь открыл одновременно пять сеансов и в каждом из них своя версия конфигурации, то закрыл как-то некорректно сеанс, а в кэше что-то осталось и т.д. и т.п.
Пока нет 100%-ной гарантии стабильной работы в любых условиях, пользоваться динамическим обновлением можно только на свой страх и риск. И тогда, как автор, успешно отработав 10 лет, можно нарваться на проблему. И по законам подлости, произойдёт это в самый неподходящий момент.

(16) При этом на мисте многие специалисты (настоящие, а не как Г1С) регулярно утверждают, что "динамическое обновление норм, всегда так делаю", а те, кто их послушает, потом ловит ошибку аля (0) или похуже (до полной неработоспособности базы).

Ну поорите очередной раз, что и расширения дрянь дрянная и чего?

(18) Может уже откажутся от расширения. Только проблемы от него

(0) Админам можно рассказать про список общих баз...

Я если пользуюсь динамическим обновлением (редко) обязательно вечером того же дня обновляю базу нединамически (изменяю реквизитик в неиспользуемом справочнике). Помогает.

(19) не откажутся. Тем более, что это правильный путь

(21) :-) - не совсем в тему, но вспомнилось "... Вы или крестик снимите, или трусы наденьте ..."

(23) Он правильно делает. Динамическое обновление — это риск, на который он идёт осознанно, но в ближайшую ночь обновление становится обычным. Получается, что это короткий риск на несколько часов, он не переходит на следующий день

а я отвечу еще одним анекдотом, точнее, фразой : " - Миша, а ты почему в небо фигу не крутишь? "

Просто, если на проблему нарвешься с этим самым обновлением, то она выскочит мгновенно и ночи, до того времени, пока соблаговолят обновиться "по православному", ждать не будет.

т.е. если придется восстанавливаться из архива, то брать придется точку "перед", а не "после" установки обновлений

(25) Проблемы обычно решаются чисткой кэша у конкретного пользователя. Не будьте таким пессимистом.

(25) Не факт. По моим наблюдениям динамические обновления "копятся". Иными словами, вчера дин. обновил, сегодня, а завтра - сразу накроется.
С тех пор, как стал придерживаться тактики "ночью обязательно обновляю" проблемы с динамическим обновлением исчезли.

(28) Правильно. Одно динамическое обновление в сутки - ОК. При условии, что ночью будет полноценное обновление.

(25) Проблема динамического обновления может и через год стрельнуть в виде битой конфигурации, в результате чего у одних пользователей выполняется один код, а у других - другой. Ну мало ли что там произошло - ну забыла платформа удалить старые версии кода когда ими все перестали пользоваться. И оно так и осталось внутри.

(30) Через год!... О-ля-ля

А где топикстартер-то? У него всё нормально?

(31) Ну, через год таки заметили глюки в одной редко используемой ветке кода, и дошли до причины их возникновения, когда у одних пользователей выполняется один код, а у других - немного другой. И чистка кеша не помогала, т.к. оно было в конфигурации и рандомно выдавало разные версии кода. Когда выяснили это и стали проверять - оказалось, что и по интерфейсу были небольшие различия у пользователей, тоже внесенные динамическим обновлением. Решилось через выгрузку и загрузку файлов, но их пришлось подчистить ручками перед загрузкой. Весело было... после этого динамическое обновление согласуется со всеми отделами - и чаще всего оказывается, что не очень-то и срочно оно нужно.

(31)был случай (сам свидетель), когда после динамо из хранилища восстановился местами код месячной примерно давности....

+ (34) месяца за 2 до этого хранилище пересоздавали... возможно поэтому не такой жёсткий был откат

Потрясающе

(27) ну как сказать...
если чистка кэша проблему решает, то нужно этого пользователя из базы выкинуть, чтоб этот самый кэш почистить.
Просто реальные проблемы, когда они случаются, в не чистке кэша, в котором замерзает программный код, а в несоответствии описания структурных данных. Т.е. это не кэш юзера, а кэш сервера. Серверный кэш можно очистить с рестартом сервера или рестартом хотя бы всех рпхостов этой базы - монопольный режим обработки данных из базы, грубо говоря.
Вот отсюда и легенда "демоническое обновление - зло"

(29) // Одно динамическое обновление в сутки - ОК. При условии, что ночью будет полноценное обновление.

Не правильно. Если критичных изменений нет, но обновлений может быть и больше чем одно
Полноценное обновление ночью... Ну не спасет оно, если проблема реально будет. Такую рекомендацию давать нельзя.
Надо осознавать именно характер изменений, а не формально следовать "трусы наденьте, либо крестик снимите"

(0) да утвердите уже регламент обновления у генерального директора.
1. Ночные обновления.
2. Обеденные обновления.
3. Экстренные обновления, с оповещением всех пользователей.

(0) Распишите ситуацию, когда динамическое обновление прям нужно делать, иначе капец. И оно не укладывается в три пункта выше.

если не пользоваться демоническим обновлением, то не удастся узнать какие проблемы это может принести
Как наверняка развалить базу динамическим обновлением?

(40) >> если база серверная, то можно открыть ее из разных серверов приложений и одновременно динамически обновить

Зачёт!

(33) >> динамическое обновление согласуется со всеми отделами - и чаще всего оказывается, что не очень-то и срочно оно нужно.

+100. Та же самая фигня. Как только стали согласовывать установку исправлений/обновлений, выяснилось, что в 99.9% случаев все абсолютно спокойно готовы подождать до завтра. И крайне редко согласуется 10-тиминутное окно с блокировкой доступа к базе.

(18) >> Ну поорите очередной раз, что и расширения дрянь дрянная и чего?

Да ничего. Чё орать о том, что и так очевидно?

Как и в любой другой технологии, в 99% случаев проблема не в ней самой, а в тех, кто её применяет, и как они это делают.
Обсуждения на мисте показывают, то подавляющее (если не сказать "абсолютное") большинство, мягко говоря, не очень четко представляют себе как и для чего надо пользоваться расширениями, применяя их к месту и не к месту.

И еще в тему про боязнь демонического обновления с баша. Как будто мы другими способами не можем базу уложить.

#357076
26.06.2007 в 0:25
Kenga: я не пью кофе, тем более чёрный. Это для сердца опасно. Умиреть боюсь:)
шИринко: Ты выкуриваешь по три пачки сигарет в день, неделями не выходишь из запоя, при этом пьёшь всё что горит, постоянно спишь с какими то бл#дями, переходишь дорогу на красный свет и постоянно когда видишь толпу злых гопнегов тычешь в них пальцем с криками "Самри какие они лохи!" И ТЫ БОИШЬСЯ УМЕРЕТЬ ОТ КОФЕ?!?!?!?!?! O_o

(44) прост обычными способами ты сразу базу положишь, а не через какое-то время. И обычно делаешь бекапы перед такими телодвижениями. А при демоническом обновлении 99% никто бекапы не делает и в режиме онлайн тестят свой код по живому, а потом удивляются, мол как так ошибка потока)

(43) ну вот ты очереодной раз проорался, хотя, на минуточку, пост не был адресован персонально тебе :-)

Не чешите Гондурас и он не будет Вас беспокоить

(46) Про расширения в теме динамического обновления именно я поднял вопрос в этой ветке.
Поэтому именно я ответил на твою реплику.
Расширения - это тот самый Гондурас, который зачастую лучше расчесать пораньше, чем потом кусать локти.