Учимся писать SQL скрипты

  оглавление  Тестирование и исправление базы

Обновлятор-1с. Конфигуратор несанкционированно сбрасывает блокировку сеансов в клиент-серверной базе

Суть проблемы

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

Обновляется конфигурация базы данных.
ОбщаяКартинка.Информация: Имя не уникально!
Обновление конфигурации базы данных
Обработка структуры базы данных...
Ошибка исключительной блокировки информационной базы.
База данных заблокирована:
пользователь: ?, сеанс : 4, начат: 13.10.2021 в 0:40:29, приложение: ?

... либо на этапе выполнения обработчиков обновления:

Выполняются обработчики обновления.
Ошибка: ошибка разделенного доступа к базе данных, база данных заблокирована:, компьютер: ?,
пользователь: ?, сеанс: 61511, начат: ?, приложение: ?

Почему это происходит, ведь обновлятор устанавливает блокировку сеансов и выгоняет всех пользователей перед началом операции? Каким образом новые пользователи попадают в базу по ходу выполнения операции?

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

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

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

  1. База является клиент-серверной.
  2. Платформа 1с любая версии 8.3.18, 8.3.19 или 8.3.20.
  3. В базе накоплены определённые изменения в конфигурации (например, выполнено обновление конфигурации Бухгалтерия Предприятие с версии 3.0.95.24 на 3.0.99.19) без последующего обновления конфигурации базы данных. Отдельно подчеркну, что проблема воспроизводится не на всех обновлениях конфигурации, именно поэтому я привёл пример конкретного обновления на котором проблема воспроизводится.

Если при выполнении этих 3 условий...

  1. Установить в базе блокировку сеансов и код разрешения.
  2. А затем выполнить операцию "Обновление конфигурации базы данных" (хоть вручную через конфигуратор, хоть через обновлятор)

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

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

Общение с технической поддержкой 1с

26.10.2021 Вся собранная информация (включающая детальное описание и быстрый способ воспроизведения ошибки) отправлена в техническую поддержку 1с на адрес v8@1c.ru, обращение зарегистрировано под номером HL-405298.

18.11.2021 Получил такой ответ от технической поддержки 1с:
"Ошибка платформы https://bugboard.v8.1c.ru/error/000114376
Исправлена в будущих версиях 8.3.21+"

Решение

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

Назначаем всем пользователям непустые пароли

Потому что, если у пользователя пустой пароль, то становится возможен следующий сценарий:

  1. Пользователь с пустым паролем оставил базу открытой и ушёл домой.
  2. Ночью вы сами (вручную или через обновлятор) установили в базе блокировку сеансов (для её обслуживания) и дождались, когда всех пользователей (это функционал типовых) выбросит из базы.
  3. Да, пользователя выбросило, но на его рабочем месте появилось окно ожидания с попытками (каждую минуту) повторного подключения к базе.
  4. Попытки повторного входа будут неудачными, ведь в базе установлена блокировка сеансов.
  5. И тут конфигуратор по ходу выполнения операции "Обновление конфигурации базы данных" несанкционированно сбрасывает (то есть снимает) блокировку сеансов и тот самый диалог ожидания автоматически пускает пользователя обратно в базу! И операция обновления базы данных завершается ошибкой из-за исключительной блокировки.
  6. Так вот если бы у пользователя был непустой пароль - его бы в базу обратно автоматически не пустило.

Заставляем пользователей вводить пароль

Эту рекомендацию не всегда возможно выполнить целиком. Её смысл в том, что даже если у пользователя непустой пароль, но при этом...

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

... пользователя также пустит обратно в базу автоматически (см. предыдущий сценарий, пункт 5).

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

Вопрос какими средствами в этом случае заставить пользователей не прописывать нигде пароль для автоматического входа в базу остаётся открытым.

Заставляем обновлятор контролировать сохранение установленной блокировки сеансов

Заходим в свойства клиент-серверной базы, закладка "Обновление", раздел "Сам процесс":

Здесь включаем опцию "При обновлении конфигурации базы данных (на проблемных релизах платформы 1с) контролировать сохранение блокировки сеансов".

По умолчанию данная опция включена и имеет значение "Однократно после" ( рекомендую сразу сменить это значение на "непрерывно в процессе" ).

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

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

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

Если это не помогает - установите эту же опцию со значением "Непрерывно в процессе":

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

Вот как это будет выглядеть в отчёте:

Как помочь с исправлением ошибки

Друзья, я уже отписался выше, что ошибка зарегистрирована в 1С.

Теперь я прошу вас по возможности зайти на страницу с ошибкой и поставить отметку "Для меня исправление ошибки важно":

Тем самым мы повысим вероятность исправления этой ошибки в одном из ближайших релизов платформы.

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



Владимир Милькин
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.

Нажмите одну из кнопок, чтобы поделиться:



Учимся писать SQL скрипты

  оглавление  Тестирование и исправление базы