Собственно, вся суть в теме.

Возможно ли каким-то образом настроить работу так (без совсем жестких извращений) чтобы при обновлении 1С не выгонять пользователей из базы?

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

Может, у кого был интересный опыт - поделитесь

Можно, но долго. И не факт что сработает.
1. Должен быть SQL и  копия базы.
2. Обновляешь копию.
3. Переносишь из копии конфиг.
4. Парсишь различия структуры таблиц.
5. Меняешь структуру.
6. Вероятность траблов 50%, всё зависит от обновления.

(0) При небольших доработках можно использовать динамическое обновление

(1) Такое себе - спасибо
(2) Вообще не вариант

(1)

Что такое обновление? Новый релиз конфы ?

Вот было обновление ERP. Реструктуризация 15 мин
А дальше обновление фоновыми "Расчет с клиентами" и  "Расчет с поставщиками"
(каких-то 2-3 часа)

И вроде работать можно, но толку нет,
ибо 1С не даёт проводить документы связанные с этими регистрами.

P.S.
Или вам необходимо обновлять конфу по 10 раз на дню ?

P.S.S.
Или вы настолько большие, что не можете позволить технологическое окно даже ночью ?

(4) да, обновление конфы
У нас обновления проходят пару раз в неделю. Но хотелось бы на время релиза не блокировать вообще работу пользователей (это критично, такая специфика)
Вот пытаюсь понять возможно ли это +/- адекватными способами

Давайте разбиратся, автор хочет что-бы

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

Собственно я не знаю ни одной серьезной системы (не 1с) которая так умеет.

Да обновление формочек и прочей мелочи можно накатывать "тихо", но изменение в базе данных это по любому транзакция и блокировка...

(0) а в чем схема сумасшедшая? у меня она отлично работала несколько лет. юзеры иногда даже не замечали подвоха, так как всё было автоматизировано. РИБ все изменения переносил, остатки всегда были актуальны. Я эту схему использовал для помесячной свертки баз. батник + расширение

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

(6) глобально да, всех переводить на новый функционал (если это возможно)
Пока выглядит, что это не получится и тогда буду смотреть в сторону "минимизирования времени простоя"

(1) так-то, вероятность проблем в такой схеме больше 50%
3. Переносишь из копии конфиг. - Алгоритмы уже работают, а структура не та
4. Парсишь различия структуры таблиц.
5. Меняешь структуру.
Как минимум порядок: 4,5,3

(0) В (6) правильно говорит, нет такого функционала, без прерывания работы пользователей, даже на уровне БД

Как вариант решения проблемы:
делаем отдельные конфигурации на функциональные блоки, например, Склад, Банк и что там ещё нужно. Главное: они замкнуты в себе, т.е. обновление одного не влечёт последствий для другого, например, Контрагент для склада - это просто ссылка с наименованием и ИНН, а для Банка уже и РС и договор нужен и т.д.

Кроме того - основную БД выводим в режим архива данных, т.е. обновить оную можно и ночью без последствий для работы конторы, бо менеджеры спят

(0) поделитесь что за область деятельности такая с нулевым технологическим окном?

Так корп. функционал вроде позволяет такое. Или я что то путаю?

10+ Можно рассмотреть отдельную точку для ведения НСИ, а остальные из неё будут получать данные, например, через HTTP сервис, т.е. на время реструктуризации для получения данных можно завернуть и на копию с остановленным вводом данных

(11) Вполне возможно, разные часовые пояса в обычной оптовой торговле с разбросанными складами по всему свету

(0) >Кроме совсем сумасшедших схем
1С в ERP так и делает

https://www.youtube.com/watch?v=gZsQrlcUg-4

КОРП же вроде позволяет фоновое обновление БД

(0) Что такое фоновое обновление конфигурации базы данных

(12) да

(0) Чем методика с ИТС не устраивает? Долго? Сложно? Высоки риски накосячить? Ну так либо одно, либо другое.

(0) пока ТС не расскажет подробности, можно считать, что ТС просто лень обновлять вечером-ночью, и он хочет обновлять днем и уходить вовремя)

Все эти "обновления на лету" - риск для больших, просто огромных косяков. Надежнее выделять для обновления технологическое окно. Если специфика работа 24/7 - то можно использовать распределенную базу и обновлять ее "сегментами", пока часть пользователей спит (8-ми часовой рабочий день никто не отменял).

(11) (19) Финансовый сектор

(17) вы этим пользовались на практике?
т.е. при покупке лицензии Корп порядок обновления БД меняется? :) Не оч понимаю как это работает

(18) поделитесь методикой, рассмотрю

(22) Фактически РИБ с разными версиями конфы
Пользователь при отключении/подключении попадает на обновленный узел

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

Возможно, это разные конфигурации по наполнению и составу

25+ В такой схеме работы есть проблема: закрытие счетов другого отделения, нужно получить остаток и организовать уведомление о закрытии счёта (дабы дважды не выплатили остаток разным людям)

(23) https://its.1c.ru/db/erp25ltsdoc#bookmark:UpdateBase:UpdateWithoutStop

Чисто теоретически, без особо жестоких извращений, можно нечто подобное реализовать в РИБ:
а) юзверя завершают сеанс в узле с ещё необновленной конфигурацией;
б) проводится нетиповой сеанс синхронизации данных (нетиповой - для обхода платформенного контроля идентичности конфигураций);
в) юзверя открывают сеанс работы в узле с уже обновленной конфигурацией.

Дьявол кроется в деталях: чтобы корректно реализовать пункт "Б", Вы должны знать что именно и как именно происходит преобразование данных в этом конкретно взятом обновлении :(

(28) "б" может занять сутки

(10) на уровне субд есть "снимок", примерным аналогом которого в 1с может выступать узел распределенки.

Но тут возникают глобальные проблеммы с целостностью транзакций....

(21) в финансовом секторе НЕТ задач реального времени кроме игры на бирже (но биржи не 24 часа работают). Короче мозги не парьте, делайте регламент и в этот регламент включайте обновление.

Да банально у Вас же есть бекапирование, перестройка индексов, шринк и т.д. или это то-же делаете не выгоняя пользователей?

(30) просто на это может быть выделено окно час-два (на что-то одно хватает). а обновление или синхронизация могут занять гораздо больше времени. вот тут буферная база и нужна. бэкапы давно уже системы научились делать мгновенно.

(31) провести обновление за час или сделать его безшовным - это две совершенно разные задачи...

(29) "Не верю"(с)
Если допустить нечто такое несуразное, то придётся поверить и в существование таких баз данных, где штатное типовое обновление длится сутки и более. А также придётся поверить в существовании организаций, готовых терпеть суточный простой в своей работе.

PS: просто надо чаще синхронизировать данные в РИБ.

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

(34) Ок, спорить не буду. Я сочувствую работникам "целого завода"(с), который до сих пор сидит на телефонном модеме :))

А если серьёзно, то нетиповая синхронизация данных требуется только  для тех данных, которые были изменены с момента последнего сеанса связи в необновленном узле. Обмен данными после обновления - не в их числе.

(35) реальный пример прошлых обновлений:

перенос всей контактной информации из общего регистра в табличные части обьектов...

затрагивает немерянно обьектов...

(30) Есть, например, выплата вкладов физ.лиц, закрытие их счетов, перевод на другой счёт (у всего контроль доступного остатка он-лайн).

Остальное - терпит по времени, но есть нюанс при больших объёмах данных и замороченных условиях вкладов и кредитов начисление % может занять приличный объём времени  + не забываем про Юр.лиц: с них денюжку за обслуживания счета, им % за остаток на счете.
Всё это похоже на расчет себестоимости в ЕРП, только чуть проще

Кроме того, есть ещё печать мемориальных ордеров начисления / удержания %. Тут зависит от организации работы: вечером начисляет и печатает оператор (в одно лицо можно долбануться - печать иногда занимает около 5-6 часов, я распараллеливал печать на 2-3 принтера кусками) или автоматическое начисление с печатью ордеров бухгалтером для ЮЛ

Потому РИБ, с одной стороны - нормально, с другой - может представлять проблему, т.к. расчёты нужно провести за ограниченное время и дёргать оператора не стоит в момент печати

В такой ситуации само оптимально - замкнуть работу в отделении / регионе, но тут есть моменты:
1. для отделений нужна отдельная конфигурация с её поддержкой
2. нужна отдельная конфигурация для централизованной БД и, очень возможно, что отличающаяся по функционалу от п.1 + её  поддержка
3. чётко отстроить обмен между п.1 и п.2

Тут проблемно задействовать что-то стандартное от 1С (РИБ и то засадно, бо нужен перелогин пользователей)

(36) Ещё раз повторю, но более подробно: пункт "Б" - это выгрузка только лишь зарегистрированных изменений из подчиненного узла (с момента последнего обмена данными перед  началом обновления конфигурации в центральном узле).

ibcmd infobase config apply --force --dbms=MSSQLServer --db-server=SQLServer --db-name=BaseName

(0) Если Ваша 1С является микросервисом, подключённым к шине, то можете поднять столько экземпляров, сколько нужно, и обновлять их отдельно.

Конечно, живых пользователей в базе быть не должно, только роботы.

Пользователи могут работать в каких-то браузерах, например, через некий фронт-офис.

(5) >> У нас обновления проходят пару раз в неделю.

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

Наладьте процессы хоть какого-то планирования.
Разделите обновления на те, что требуют реструктуризации и те которые её не требуют.
Для установки обновлений, не требующих реструктуризации, достаточно буквально нескольких минут. Их можно, например, раз в неделю ставить.
Установку обновлений с реструктуризацией проводите пореже - раз в две недели.

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

(40) Плюсую.
Вебклиенты + Шина данных + Копии базы данных для СКД,  а лучше вообще  КХД для отчетов в той же самой 1С Аналитике.

Тут хорошее КОРП решение напрашивается само собой которое построено на микро-сервисной архитектуре применяемой в мобильной разработке.

(0) Помысли иначе, что у тебя не одна база, а тысяча баз и в каждой базе ведутся исключительно свои узкие транзакции.
Какие то базы создают транзакции сами без пользователей.
Где то есть Озеро данных в котором плавают финансовые аналитики и формируют свои прогнозы.
Решение уверен найдешь.

Нужно понимать,что в процессе обновления данных идёт преобразование структуры хранения из одной в другую.
В этот момент,запросы как к старой так и к новой структуре не дадут правильного результата.
Поэтому,в процессе преобразования полноценная работа невозможна.
А далее,можно играться сокращением времени полного простоя сильно увеличивая время частичного доступа.