Добрый день. Есть кластер 1С из 4 серверов. На нём большая информационная база. Несколько месяцев назад при обновлении конфигурации (сейчас вылезло в третий раз за 5 месяцев, обновления в 1-2 раза в неделю) стала появляться ошибка раздельного доступа к информационной базе со списком соединений, мешающих обновлению.
Зашёл в список блокировок - блокировки есть.
Зашёл в список соединений - соединений, на которые ругается 1С при обновлении нет.
Если остановить на серверах все службы, очистить серверный кэш и запустить заново, блокировки исчезают, но в этом кластере вскоре появится ещё штук 10 информационных баз и из-за каждой зависшей блокировки перезагружать службы всего кластера будет очень проблематично.
Соответственно, вопрос:
1. Можно ли найти источник блокировки (какой пользователь, какое задание, какая функция, что заблокировало)?
2. Есть ли какой-то способ убить блокировки без перезапуска всего на свете, если уверен, что они глючные?
При обновлении конфигурации в 1С возможны два варианта - динамичное обновление без завершения сессий пользователя и завершение работы в информационной базе всех пользователей.
Второй вариант и должен использоваться. Отсюда вопрос - зачем знать кто блокирует, когда все сеансы должны быть принудительно завершены. Если я правильно понял проблему.
Каждая блокировка привязана к пользователю, завершив сессию пользователя - блокировка снимается.
В конфигурации БД можно настроить, когда должна отвалиться зависшая блокировка.
1. Можно ли найти источник блокировки (какой пользователь, какое задание, какая функция, что заблокировало)?
Можно, но сложно выполнять руками.
Как вариант для автоматизации отслеживания блокировок (головная боль кластеров 1с) делали вот такую приблуду.
2. Есть ли какой-то способ убить блокировки без перезапуска всего на свете, если уверен, что они глючные
Лёгких - нет.
Тяжелые: описаны тут, тут, воспользоваться стандартными рекомендациями 1С "Обновите платформу", ну и копать консоль 1с (вообще в ней висяки, как раз и можно убить, но есть нюансы).
Наиболее вероятный сценарий, как и пишут выше в комментарии, - динамическое обновление.
Пример: если во время динамического обновления ERP, работает регламентное задание Документооборота, которое создает COM-объект базы ERP и выполняет что-нибудь ... (обмен), то у нас всё висло намертво и помогал только рестарт служб. Аналогичная ситуация возможна если в самой ERP выполняется регламентное задание, не обязательно блокировка из-за юзеров;
Учитывая что без динамического обновления жить сложно, рекомендация простая: перегружать службы раз в день ночью;
Простой
Простой
