Что такое динамическое обновление 1с
Что такое динамическое обновление 1с
Это заявленная возможность платформы 1с выполнять обновление без монопольного доступа к базе.
Следовательно мы можем вносить изменения в конфигурацию при работающих в базе пользователях.
Такое обновление возможно лишь при отсутствии изменений в структуре базы данных. К примеру, если вы добавили новый реквизит справочника, обновиться при работающих пользователях не получится.
Подробнее о возможностях и ограничениях динамического обновления можно прочитать здесь.
Почему динамическое обновление по умолчанию отключено в обновляторе
О проблемах, с которыми можно столкнуться используя «демоническое» обновление можно почитать, например: здесь, здесь и здесь.
Поэтому если можно обойтись без динамического обновления, запланировав достаточное по времени технологическое окно для монопольного доступа к базе, лучше всегда так и делать.
Но ситуации бывают разные. Например, может быть выявлена ошибка в коде критичная для одной части работающих пользователей, требующая немедленного исправления без остановки работы другой части пользователей. В этом случае без динамического обновления не обойтись.
И здесь самое главное всегда делать резервную копию базы непосредственно перед динамическим обновлением. Вы спросите как её делать, если мы не можем выгонять пользователей. Очень просто. Если у вас серверная база, то вот так; а если файловая, то вот так.
И тогда, после динамического обновления базы, той части пользователей, для которой мы вносили изменения в код конфигурации, будет достаточно лишь переподключиться к базе, чтобы начать работу с новой версией конфигурации.
Как включить возможность динамического обновления базы в обновляторе
Заходим в дополнительные настройки:
Переходим на закладку «Обновление баз» и устанавливаем галку «Включить возможность динамического обновления»:
После этого в меню операций над базами появляются пункты меню, соответствующие динамическому варианту выполнения:
При этом я очень рекомендую выполнять операции динамического обновления с настроенной архивацией базы.
Для файловой базы в свойствах нужно настроить теневое копирование без блокировки пользователей:
Для серверной базы в свойствах нужно настроить sql-архивы:
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
| Подписывайтесь и получайте новые статьи и обработки на почту (не чаще 1 раза в неделю). |
Вступайте в мою группу ВКонтакте, Одноклассниках, Facebook или Google+ — самые последние обработки, исправления ошибок в 1С, всё выкладываю там в первую очередь.
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Нажмите одну из кнопок, чтобы поделиться:
Динамическое обновление 1С
Не зря в народе динамическое обновление 1С называют «демоническим».
Многие утверждают что оно удобно для экстренного исправления ошибок в алгоритмах, но это самообман. На самом деле исправления для старых сессий не начнут действовать. Поведение системы, когда в разных сеансах пользователи с одними и теме же таблицами работают де-факто по разным алгоритмам — просто становится не очень прогнозируемым и стабильным.
1. Например можно словить:
Ошибка СУБД:
ERROR: relation «_reference5029» does not exist
2. Если изменилась (или удалилась) функция — будет фатальная ошибка или отсутствие контроля целостности данных.
3. Еще одна неприятная ситуация возникает при некорректной работе с кэшем метаданных.
Кэш метаданных расположен в папке \ \Local Settings\Application Data\1C\1Cv81\
В нем необходимо стереть подпапки Config, ConfigSave, DBNameCache, SICache.
В результате легко получить ошибку «Ошибка потока формата».
Примечание.
UUID информационной базы можно посмотреть в файле
C:\Documents and Settings\ \Application Data\1C\1Cv81\ibases.v8i.
Не исключены также проблемы с падением производительности.
При этом в технологическом журнале могут встречаться сообщения типа: Попытка подключения к контексту сервера с неподходящей версией метаданных.
Возможные проблемы:
1. Основная проблема в работе с КЭШ.
1.1. У пользователя может не обновиться кэш на клиенте.
1.2. Кэш на сервере может не обновиться.
1.3. Кэш у разработчика может не обновиться (если работают несколько разработчиков)
2. Сталкивались с такой ситуацией когда делаешь штук 5 демонических обновлений а потом обычное. При обычном все демонические пропадают. Т.е. все что нажито непосильным трудом…
3. Сама ошибка заключатся в том, что в момент записи в таблицу «Config» что-то произошло, что помешало корректно закончить данную процедуру.
Часто программисты не учитывают, что есть список объектов, НЕ доступных для динамического обновления
Регламентные задания
Общие реквизиты
Планы обмена
Реквизиты, предопределенные элементы, иерархия, владельцы, нумерация справочников
Реквизиты, нумерация, движения, последовательности, ввод на основании документов
Перечисления
Тип значений характеристик, реквизиты, нумерация, предопределенные элементы планов видов характеристик
Реквизиты, нумерация, субконто, предопределенные элементы планов счетов
Реквизиты, нумерация, расчет, предопределенные элементы планов видов расчета
Реквизиты, регистраторы регистров сведений, накопления, бухгалтерии, расчета
Реквизиты, нумерация, расчет, предопределенные элементы планов видов расчета
Реквизиты, адресация, нумерация задач
Реквизиты, нумерация, ввод на основании бизнес-процессов
Были известны случаи, когда «демоническое обновление» останавливало работу всей системы, а исправление последствий отнимало уйму времени или базы восстанавливали из копии, потеряв часть данных.
Динамическое обновление есть смысл делать только в том случае если информационная система уже стоит, неработоспособна и хуже уже не будет. о всех остальных случаях мы рекомендуем избегать динамического обновления!
Если вы работаете с часто изменяемой печатной формой и не хотите постоянно выгонять пользователей, используйте внешние обработки.
Хорошей практикой считается все плановые изменения вносить например раз в неделю, например во вторник. К этому дню все правки тестируются не только по отдельности, но и в общем взаимодействии. Если во вторник информационная система ухудшила свою работу, значит сразу понятно, что надо откатить последний релиз к предыдущему. А это означает бэкап не только базы, но и бэкап cf перед внесением изменений.
Народное творчество. Порочность динамического обновления воспета народом в интернете:
«Здравствуйте, меня зовут Алексей и я делаю динамическое обновление.
Раньше, я делал динамическое обновление по три или даже целых пять раз в день.
Я мог не спросить пользователей, не сделать бекап средствами СУБД и динамически обновить базу ради изменения макета печатной формы счета на оплату.
Но потом случилось горе и в одно прекрасное обновление база просто не запустилась.
Это был ч0рный день в моей жизни.
Я потерял друзей, коллеги отвернулись от меня.
Жена меня бросила и дети не хотят со мной разговаривать.
Попа болела после долгого и многозначительного разговора с начальством.
И я решил изменить свою жизнь.
Я теперь занимаюсь спортом
Стал посещать бассейн.
Питаюсь правильно и соблюдаю правила дорожного движения.
Сегодня у меня праздник.
Я уже 30 дней не делаю динамического обновления без архивации базы данных средствами СУБД.
Я практически готов полностью отказаться от динамического обновления.
Вообще не обновлять динамически.
Преодолеть зависимость от динамического обновления мне помогли 12 простых шагов:
Механизм работы обновления:
Процесс динамического обновления (и обновления вообще) происходит следующим образом:
В случае если обновление происходит динамически и клиент подключен к клиент-серверной ИБ, тогда конфигуратор уведомляет сервер о том, что поколение метаданных, с которым сейчас работает сервер, устарело. Сервер запоминает этот факт и при подсоединении следующего нового клиента «поднимает» для него самое актуальное поколение метаданных. Уже подключенные клиенты живут в старом поколении до тех пор, пока они подключены к серверу. Так как конфигуратору, для продолжения работы после обновления ИБ, требуется самое новое поколение, а он подключен к старому, то конфигуратор перезапускается, чтобы подключится к новому поколению метаданных на сервере.
1с динамическое обновление конфигурации
Это заявленная возможность платформы 1с выполнять обновление без монопольного доступа к базе.
Следовательно мы можем вносить изменения в конфигурацию при работающих в базе пользователях.
Такое обновление возможно лишь при отсутствии изменений в структуре базы данных. К примеру, если вы добавили новый реквизит справочника, обновиться при работающих пользователях не получится.
Подробнее о возможностях и ограничениях динамического обновления можно прочитать здесь.
Почему динамическое обновление по умолчанию отключено в обновляторе
О проблемах, с которыми можно столкнуться используя «демоническое» обновление можно почитать, например: здесь, здесь и здесь.
Поэтому если можно обойтись без динамического обновления, запланировав достаточное по времени технологическое окно для монопольного доступа к базе, лучше всегда так и делать.
Но ситуации бывают разные. Например, может быть выявлена ошибка в коде критичная для одной части работающих пользователей, требующая немедленного исправления без остановки работы другой части пользователей. В этом случае без динамического обновления не обойтись.
И здесь самое главное всегда делать резервную копию базы непосредственно перед динамическим обновлением. Вы спросите как её делать, если мы не можем выгонять пользователей. Очень просто. Если у вас серверная база, то вот так; а если файловая, то вот так.
И тогда, после динамического обновления базы, той части пользователей, для которой мы вносили изменения в код конфигурации, будет достаточно лишь переподключиться к базе, чтобы начать работу с новой версией конфигурации.
Как включить возможность динамического обновления базы в обновляторе
Заходим в дополнительные настройки:
Переходим на закладку «Обновление баз» и устанавливаем галку «Включить возможность динамического «:
После этого в меню операций над базами появляются пункты меню, соответствующие динамическому варианту выполнения:
При этом я очень рекомендую выполнять операции динамического обновления с настроенной архивацией базы.
Для файловой базы в свойствах нужно настроить теневое копирование без блокировки пользователей:
Для серверной базы в свойствах нужно настроить sql-архивы:
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
| Подписывайтесь и получайте новые статьи и обработки на почту (не чаще 1 раза в неделю). |
Вступайте в мою группу ВКонтакте, Одноклассниках, Facebook или Google+ — самые последние обработки, исправления ошибок в 1С, всё выкладываю там в первую очередь.
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Нажмите одну из кнопок, чтобы поделиться:
Настройка системы 
19.10.2017 09:40 
5879Все изменения конфигураций 1С производятся в «Конфигураторе». Для того чтобы изменения конфигурации вступили в силу необходимо нажать «Обновить конфигурацию базы данных (F7)». Для этого нужно чтобы все пользователи вышли из информационной базы и конфигуратор получил монопольный доступ. В 1С есть динамический вариант обновления.
Ошибка исключительной блокировки информационной базы.
Активные сеансы:
Нажмите «Отмена» для прекращения обновления.
Нажмите «Повторить» для повторной попытки установки монопольного режима.
Нажмите «Обновить динамически» для обновления без завершения работы пользователей.
Динамическое обновление — обновление «конфигурации базы данных», при котором не требуется монопольный доступ к базе. Но данное обновление доступно, только когда нет изменений в структуре метаданных. После выполнении такого обновления, пользователи продолжают работать в информационной базе со старой конфигурацией. При перезапуске 1С, база запустится с новой конфигурацией.
Плюсы и минусы
| 1. progv8 23.10.2017 16:45 |
| Есть не типовая конфигурация, запускается на платформа 8.3.10 После частого динамического обновления или отключений света, один из справочников в конфигураторе виден, а в предприятии нет. Тестирование исправление не исправило, и чистка кэша не помогла. Проблема исчезла только после внесения новых изменений в этот справочник. Только после этого справочник в предприятии отобразился. |
Для того чтобы добавить сообщение, необходимо Войти или Зарегистрироваться
Если на живых данных ведется активная разработка, и часто выполняется динамическое обновление конфигурации базы данных — велик риск словить ошибку «Нарушена целостность структуры конфигурации». Это означает полную неработоспособность. Не запускается ни конфигуратор, ни «предприятие».
Несмотря на исправное и частое создание копий средствами СУБД — это помогло лишь отчасти, так как с точки зрения SQL бэкапы без нарушений, а вот 1С их уже не открывает. И замечаешь это только уже когда всё сломалось.
Вобщем поаккуратней с частыми динамическими обновлениями.
Архив метки: динамическое обновление
Не зря в народе динамическое обновление 1С называют «демоническим».
Многие утверждают что оно удобно для экстренного исправления ошибок в алгоритмах, но это самообман. На самом деле исправления для старых сессий не начнут действовать. Поведение системы, когда в разных сеансах пользователи с одними и теме же таблицами работают де-факто по разным алгоритмам — просто становится не очень прогнозируемым и стабильным.
1. Например можно словить:
Ошибка СУБД:
ERROR: relation «_reference5029» does not exist
2. Если изменилась (или удалилась) функция — будет фатальная ошибка или отсутствие контроля целостности данных.
3. Еще одна неприятная ситуация возникает при некорректной работе с кэшем метаданных.
Кэш метаданных расположен в папке \ \Local Settings\Application Data\1C\1Cv81\
В нем необходимо стереть подпапки Config, ConfigSave, DBNameCache, SICache.
В результате легко получить ошибку «Ошибка потока формата».
Примечание.
UUID информационной базы можно посмотреть в файле
C:\Documents and Settings\ \Application Data\1C\1Cv81\ibases.v8i.
Не исключены также проблемы с падением производительности.
При этом в технологическом журнале могут встречаться сообщения типа: Попытка подключения к контексту сервера с неподходящей версией метаданных.
Возможные проблемы:
1. Основная проблема в работе с КЭШ.
1.1. У пользователя может не обновиться кэш на клиенте.
1.2. Кэш на сервере может не обновиться.
1.3. Кэш у разработчика может не обновиться (если работают несколько разработчиков)
2. Сталкивались с такой ситуацией когда делаешь штук 5 демонических обновлений а потом обычное. При обычном все демонические пропадают. Т.е. все что нажито непосильным трудом…
3. Сама ошибка заключатся в том, что в момент записи в таблицу «Config» что-то произошло, что помешало корректно закончить данную процедуру.
Часто программисты не учитывают, что есть список объектов, НЕ доступных для динамического обновления
Регламентные задания
Общие реквизиты
Планы обмена
Реквизиты, предопределенные элементы, иерархия, владельцы, нумерация справочников
Реквизиты, нумерация, движения, последовательности, ввод на основании документов
Перечисления
Тип значений характеристик, реквизиты, нумерация, предопределенные элементы планов видов характеристик
Реквизиты, нумерация, субконто, предопределенные элементы планов счетов
Реквизиты, нумерация, расчет, предопределенные элементы планов видов расчета
Реквизиты, регистраторы регистров сведений, накопления, бухгалтерии, расчета
Реквизиты, нумерация, расчет, предопределенные элементы планов видов расчета
Реквизиты, адресация, нумерация задач
Реквизиты, нумерация, ввод на основании бизнес-процессов
Были известны случаи, когда «демоническое обновление» останавливало работу всей системы, а исправление последствий отнимало уйму времени или базы восстанавливали из копии, потеряв часть данных.
Динамическое обновление есть смысл делать только в том случае если информационная система уже стоит, неработоспособна и хуже уже не будет. о всех остальных случаях мы рекомендуем избегать динамического обновления!
Если вы работаете с часто изменяемой печатной формой и не хотите постоянно выгонять пользователей, используйте внешние обработки.
Хорошей практикой считается все плановые изменения вносить например раз в неделю, например во вторник. К этому дню все правки тестируются не только по отдельности, но и в общем взаимодействии. Если во вторник информационная система ухудшила свою работу, значит сразу понятно, что надо откатить последний релиз к предыдущему. А это означает бэкап не только базы, но и бэкап cf перед внесением изменений.
Народное творчество. Порочность динамического обновления воспета народом в интернете:
«Здравствуйте, меня зовут Алексей и я делаю динамическое обновление.
Раньше, я делал динамическое обновление по три или даже целых пять раз в день.
Я мог не спросить пользователей, не сделать бекап средствами СУБД и динамически обновить базу ради изменения макета печатной формы счета на оплату.
Но потом случилось горе и в одно прекрасное обновление база просто не запустилась.
Это был ч0рный день в моей жизни.
Я потерял друзей, коллеги отвернулись от меня.
Жена меня бросила и дети не хотят со мной разговаривать.
Попа болела после долгого и многозначительного разговора с начальством.
И я решил изменить свою жизнь.
Я теперь занимаюсь спортом
Стал посещать бассейн.
Питаюсь правильно и соблюдаю правила дорожного движения.
Сегодня у меня праздник.
Я уже 30 дней не делаю динамического обновления без архивации базы данных средствами СУБД.
Я практически готов полностью отказаться от динамического обновления.
Вообще не обновлять динамически.
Преодолеть зависимость от динамического обновления мне помогли 12 простых шагов:
Механизм работы обновления:
Процесс динамического обновления (и обновления вообще) происходит следующим образом:
В случае если обновление происходит динамически и клиент подключен к клиент-серверной ИБ, тогда конфигуратор уведомляет сервер о том, что поколение метаданных, с которым сейчас работает сервер, устарело. Сервер запоминает этот факт и при подсоединении следующего нового клиента «поднимает» для него самое актуальное поколение метаданных. Уже подключенные клиенты живут в старом поколении до тех пор, пока они подключены к серверу. Так как конфигуратору, для продолжения работы после обновления ИБ, требуется самое новое поколение, а он подключен к старому, то конфигуратор перезапускается, чтобы подключится к новому поколению метаданных на сервере.
Попытка подключения к контексту сервера с неподходящей версией метаданных
«Динамическое обновление» в 1С Предприятие 7.7
Скажу сразу: метод недокументированный и ранее в публикациях мной не встречался.
Метод протестирован на файловом варианте 7.70.27 в режиме терминального сервера. Для остальных вариантов не тестировался.
«Лирика»
Как обычно это и бывает, потребовалось у клиента провести ряд модернизаций конфигурации в режимах «срочно», «еще вот это» и «ещё вот это забыли». При этом был разгар рабочего времени, люди трудятся, да и выгнать всех из базы задачка нетривиальная. Да ещё и несколько раз подряд.
И тут подумалось мне, а как и когда загружается файл 1cv7.md в память процесса? И провел эксперимент (естественно на копии рабочей базы: «тест база»). Загрузил 1С в режиме «Предприятие», через Process Explorer (спасибо sysinternals) нашел Handler файла 1cv7.md и сделал «close handler». 1С продолжила работу. Все, проверенные мной, обработки, отчёты, документы, справочники открывались без проблем.
Закрываем handler 1cv7.md базы Предприятия и копируем 1cv7.md «тест 2 база» в каталог базы «тест база» с перезаписью.
Предприятие работает как будто ничего не произошло. А при повторном заходе «подхватывает» новую конфигурацию.
«Проза»
Метод был протестирован на рабочей базе с одновременным подключением 15-ти пользователей в файловом режиме в терминальном сервере сначала в периферийной, а затем в центральной БД.
Были отключены handler-ы файла 1cv7.md рабочей базы.
Все пользователи продолжили работать без изменений.
На место рабочей конфигурации копировался модифицированный файл 1cv7.md (без изменения структуры рабочей базы данных).
Новый файл 1cv7.md подхватывался при очередном заходе пользователя в 1С.