8.х Блокировка на ИБ при отсутствии сеансов

Для этих случаев (хотя у нас и не круглосуточно) у нас существует:
1) Обработка рассылки сообщений (пользователи авторизуются виндой и в AD e-mail ы прописанны - поэтому получить список рассылки вполне реально).
2) Телефон

Сначала выполняем пункт 1 с формулировкой что то типа "По техническим причинам необходимо перезагрузить сервер 1С. Просьба выйти из баз данных 1С"

После выполнения пункта 1 (рассылки сообщения) ждем 3 минуты и начинаем обзванивать оставшихся юзеров. Если на рабочем месте трубку никто не берет (в кабинете никого нет) - после 2го звонка руками рвем сессию (нечего уходить надолго оставляя включенной 1С)

Где то за 10-15 минут успешно успеваем разогнать пользователей (у нас их чуть более 100).

В вашем варианте, ну запланируете перезагрузку и разошлите письмо (В хх:хх по московскому времени сервер 1С будет недоступен в течении 15 минут, на это время просьба ВСЕМ выйти из 1С)

Ну и в шедулер перезагрузку сервера (или удаленно).

А что делать? Даже стальные рельсы - и те приходиться иногда менять.


P.S.
А как вы обновления требующие перезагрузки на сервер натягиваете?

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

У нас на предприятии подход к работе с пользователями немного другой, пользователь всегда прав, т.е. без ОЧЕНЬ веских оснований прерывать его работу нельзя. Если 2-3 раза за месяц я выгоню всех пользователей из 1С, боясь что на второй месяц мою зарплату получит уже другой администратор.
Если нужно перезагрузить сервер (у нас их 2, на одном - основной кластер, на втором -резервный) примерный план действий такой:
- меняем порядок серверов в списке резервирования НЕАКТИВНОГО кластера, потом меняем порядок в списке АКТИВНОГО
- ждем пока пользователи мигрируют на резервный кластер
- можем спокойно выключать или перезагружать сервер с основным кластером
- меняем порядок серверов в списке резервирования обратно, в той же последовательности (сначала неактивный, потом активный)

Вот что то я затупил аки слон.
База же, вы говорите ТЕСТОВАЯ?
Ну дык может ее того, этого самого - выбросить на мороз удалить из кластера без удаления БД на скуле (или чего у вас). А потом добавить в кластер под прежним имененем (логи 1Совские потеряются, но нужны ли они для тестовой то БД?)

Интересное предложение. Тогда возникает вопрос: "А что есть блокировка в терминах 1С?" Если это запись в SQL БД то удаление базы с кластера серверов ничего не даст.
Просто хотел узнать есть ли возможность быстро и безболезненно снять любую блокировку средствами самой 1С. Сейчас она зависла на тестовой базе, а завтра может зависнуть на боевой, и тогда решать проблему надо будет очень быстро, счет пойдет на минуты.

Я для этих целей использую выше названную обработку с ИТС

Если это блокировка записи на уровне MS SQL - то она должна была бы "свалиться" в момент отключения последнего пользователя из SQL или перевода ее в автономный режим (а вы говорите, что там коннекторы все уже гасили).

А НАДЕЖНО СНЯТЬ... хм.. а вам производитель вашего железа "сервера" прямо таки гарантирует что сервер НИКОГДА не зависнет? Вам электрики гарантируют что не подгонят к вам эскаватор обесточив здания на много часов? А MS прямо таки гарантирует что MS SQL (и иже с ним винда) никогда не зависнет? Ну и еще, а пользователи гарантируют что не запорят БД?

P.S.

А обновления БД, которые требуют монопольного режима БД у вас никогда не случаются?

Так что, вот так вот.
В конце концов, не ядерным же блин реактором управляет у вас 1С, не запуск же ракет обсчитывает...

P.P.S.
Мой опыт говорит, что самое сложное - это не разогнать пользователей, а убедить руководство, что 10 минут простоя раз в месяц, например, организации - НЕИЗБЕЖНО. И нефига ебпилить мозг. В конце концов, операторы БД много больше указанных 10и минут проводят раскладывая пасьянсы/обсуждая пьянки по телефонам/асечкам (если только это не рабы прикованные к веслу)

Я имел ввиду не блокировку записи на уровне БД, а именно запись в базе 1С о том что такая-то таблица в базе заблокирована (у 1С свой механизм блокировок, не имеющий отношения к блокировкам SQL)

Для всего этого есть свои способы резервирования. Для сервера приложений 1С - резервный кластер, для сервера БД - второй такой же сервер в режиме active-active кластера, для электропитания - серверный ИБП и дизель-генератор и т.д.
А вот про саму БД большой вопрос - ее работоспособность напрямую зависит от прямизны рук писателей конфигурации, тут только регулярный и частый backup спасет.

Если честно то пока не случались, 1С только внедряем, процесс обновления конфигурации, требующий монопольного доступа к БД пока не прорабатывали.

Убеждать руководство в том, что простой всей организации из-за особенностей работы 1С (пусть даже раз в месяц и на 10 минут) - это неизбежно - не моя задача, а руководителя нашего отдела-управления. Моя задача - продумать процессы управления комплексом 1С так, чтобы сократить любые простои до минимума.