1с динамическое обновление конфигурации что можно
Обновлено: 04.07.2024
Проблем с кешем не было никогда.
Честно пишу, на 8.3 (кажется 8.3.11) был однажды сбой: отпали роли у всех пользователей (в т.ч. у всех админов). В базу было не зайти, роли не назначались, конфигуратор вел себя не адекватно. Восстановил из бекапа.
За последние 10 лет три раза натыкался на проблему. Два раза обошёлся чисткой кеша, один раз пришлось перезаливать конфиг из бекапа.
(0) За лет 10, пару раз были сбои в РИБ, пришлось конфигурацию перезаливать. А так только кэш у клиентов иногда расходиться.
Пользуюсь динамическим обновлением регулярно, почти каждый день. На SQL есть бэкапы, на файловых стараюсь перед обновлением снять бэкап.
Главное правило, перед каждым, любым, обновлением сделай бэкапы и спи спокойно.
Бекап да, перед обновлением лучше делать, даже если обновление не динамическое.
(8)+ перед каждым это, наверно, правильно.
У нас бекап лога идет каждые 15 мин (а если он буде не удачным, SQL сервер всех админов на уши поставит по почте), поэтому я знаю когда он происходит и могу смотреть по времени, когда сделать обновление (хотя и могу забыть об этом).
Можно динамически обновлять 1 раз в день, но не рекомендуется.
Некоторые базы регулярно обновляем динамически. Один-два раза в год падают при динамическом обновлении. Научились быстро восстанавливать. С такой же частотой проявляются проблемы кэша пользователей.
Проблемы встречал на всех версиях платформы.
(0) Фатального не было. Были глюки с базой подключенной к хранилищу. Когда сохраняешь изменения, а в конфигурации оказывается код непонятно какой версии.
PS. Думаю что при условии нормального резервного копирования или не важности базы (тестовая) вполне можно динамически обновлять.
(13) + не кто кстати не отменял возможности фатальных последствий обычного обновления. просто реже это происходит.
динамически только если уж совсем по другому никак
Динамическое обновление сбоит. Если есть хоть малейшая возможность не обновлять динамически - не обновляйте.
Из сбоев замечено только отваливание регламентных фоновых заданий, если они работали в момент обновления .
Если делать несколько динамических обновлений подряд, в какой то момент могут быть потеряны все внесённые изменения предыдущими дин. обновлениями. Поэтому желательно придерживаться правила 1 дин. Обновление +1 обычное.
Если в конфигураторе и хранилище работает 1 программист то риск минимален.
Если несколько то уже возможны глюки.
Замечал такую тенденцию.
(0) За всё время существования динамического обновления у меня лично фатально сбойнуло только дважды. В том числе один раз на 8.3 (первый сбой - не помню на какой версии был).
Запомните раз и навсегда одну очень важную вещь!
Это не вопрос статистики! Это вопрос стоимости.
Стоимости простоя в случае сбоя, который может доходить до суток в зависимости от размера базы и необходимости проведения полного тестирования и исправления, чтобы быть более уверенным в корректности восстановления.
Стоимости работы специалистов по восстановлению (если не справитесь своими силами).
Стоимости затрат на выяснение того, что нужно внести в базу повторно - когда о проблеме узнали не сразу и часть пользователей продолжали что-то вносить в уже поломанную базу, а восстановиться решили из копии "до сбоя".
Стоимости работ на проверку данных после восстановления. Умножающиеся риски в случае, если сломанная база является источником для обмена данными с другими базами и конфигурациями.
Вы можете много лет ежедневно по несколько раз обновлять вашу базу динамически и ни разу не столкнуться ни с одним сбоем.
Но в один прекрасный день ваша база может рассыпаться.
И это всё, не говоря о том, что мелкие проблемы динамического обновления, когда у кого-то из пользователей не обновляется версия метаданных (лечится чисткой пользовательского кэша), всплывают с завидной регулярностью.
Примечание.
UUID информационной базы можно посмотреть в файле
C:\Documents and Settings\<Имя пользователя>\Application Data\1C\1Cv81\ibases.v8i.
Часто программисты не учитывают, что есть список объектов, НЕ доступных для динамического обновления
Регламентные задания
Общие реквизиты
Планы обмена
Реквизиты, предопределенные элементы, иерархия, владельцы, нумерация справочников
Реквизиты, нумерация, движения, последовательности, ввод на основании документов
Перечисления
Тип значений характеристик, реквизиты, нумерация, предопределенные элементы планов видов характеристик
Реквизиты, нумерация, субконто, предопределенные элементы планов счетов
Реквизиты, нумерация, расчет, предопределенные элементы планов видов расчета
Реквизиты, регистраторы регистров сведений, накопления, бухгалтерии, расчета
Реквизиты, нумерация, расчет, предопределенные элементы планов видов расчета
Реквизиты, адресация, нумерация задач
Реквизиты, нумерация, ввод на основании бизнес-процессов
Динамическое обновление есть смысл делать только в том случае если информационная система уже стоит, неработоспособна и хуже уже не будет. о всех остальных случаях мы рекомендуем избегать динамического обновления!
Если вы работаете с часто изменяемой печатной формой и не хотите постоянно выгонять пользователей, используйте внешние обработки.
Хорошей практикой считается все плановые изменения вносить например раз в неделю, например во вторник. К этому дню все правки тестируются не только по отдельности, но и в общем взаимодействии. Если во вторник информационная система ухудшила свою работу, значит сразу понятно, что надо откатить последний релиз к предыдущему. А это означает бэкап не только базы, но и бэкап cf перед внесением изменений.
Если Вы словили проблему связанную с динамическим обновлением, то обязательно очистите сеансовые данные с рестартом службы сервера 1С.
Если проблема не ушла, то запускайте сеанс 1С с ключом /ClearCache .
Преодолеть зависимость от динамического обновления мне помогли 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 ШАГОВ , РАЗРАБОТАННЫЕ САМИМИ ДИНАМИЧЕСКИМИ ОБНОВЛЯЛЬЩИКАМИ
1. Признать свое бессилие перед поведением платформы 1с при динамическом обновлении.
2. Согласиться с утверждением, что без посторонней помощи не обойтись.
3. Мысленно перепоручить себя некой Высшей силе, которая поможет.
4. Проанализировать свои поступки.
5. Признать перед собой и кем-то еще свои ошибки.
6. Не сомневаться, что бекап перед динамическим обновлением сработает.
7. Просить высшие силы избавить от недостатков.
8. Составить список всех людей, кому причинили зло, и захотеть загладить свою вину перед ними.
9. Лично возместить этим людям ущерб, нанесенный вами и вашим динамическим обновлением.
10. Продолжать самоанализ и, при малейших ошибках, сразу признавать, что вы их таки совершили.
11. Не переставать размышлять и благодарить помощника из пункта 3.
12. Достигнув пробуждения, благодаря пунктам 1-11, помогать другим динамическообновлялщикам.
Механизм работы обновления:
Процесс динамического обновления (и обновления вообще) происходит следующим образом:
Это последствия динамического обновления, когда разные сеансы используют разные версии метаданных. После монопольного обновления конфигурации базы данных или после того, как все пользователи перезапустятся и начнут работать с последней версией метаданных, замедления прекратятся.
Все изменения конфигураций 1С производятся в "Конфигураторе". Для того чтобы изменения конфигурации вступили в силу необходимо нажать "Обновить конфигурацию базы данных (F7)". Для этого нужно чтобы все пользователи вышли из информационной базы и конфигуратор получил монопольный доступ. В 1С есть динамический вариант обновления.
Ошибка исключительной блокировки информационной базы.
Активные сеансы:
Нажмите "Отмена" для прекращения обновления.
Нажмите "Повторить" для повторной попытки установки монопольного режима.
Нажмите "Обновить динамически" для обновления без завершения работы пользователей.
Динамическое обновление - обновление "конфигурации базы данных", при котором не требуется монопольный доступ к базе. Но данное обновление доступно, только когда нет изменений в структуре метаданных. После выполнении такого обновления, пользователи продолжают работать в информационной базе со старой конфигурацией. При перезапуске 1С, база запустится с новой конфигурацией.
Плюсы и минусы
Безусловно, при динамическом обновлении не требуется выгонять пользователей, что является плюсом. На этом плюсы заканчиваются. Из минусов можно отметить, что после обновления возможны ошибки в работе информационной базы. Ошибки могут решаться простыми методами, типа чисткой КЭШа или Тестирование и исправлением базы, и т.д. Когда данные методы не помогают приходится восстанавливать информационную базу из бэкапа. Поэтому основным минусом можно отметить возможную потерю данных и прерывание работы пользователей.
Комментарии (1)
| 1. progv8 23.10.2017 16:45 |
| Есть не типовая конфигурация, запускается на платформа 8.3.10 После частого динамического обновления или отключений света, один из справочников в конфигураторе виден, а в предприятии нет. Тестирование исправление не исправило, и чистка кэша не помогла. Проблема исчезла только после внесения новых изменений в этот справочник. Только после этого справочник в предприятии отобразился. |
Читайте также: