Оглавление
Суть проблемы
Ошибка исправлена в тестовой 8.3.21.1140.При обновлении или тестировании клиент-серверной базы через обновлятор может возникать ошибка исключительной блокировки на этапах обновления конфигурации базы данных...
Обновляется конфигурация базы данных. ОбщаяКартинка.Информация: Имя не уникально! Обновление конфигурации базы данных Обработка структуры базы данных... Ошибка исключительной блокировки информационной базы. База данных заблокирована: пользователь: ?, сеанс : 4, начат: 13.10.2021 в 0:40:29, приложение: ? |
... выполнения обработчиков обновления:
Выполняются обработчики обновления. Ошибка: ошибка разделенного доступа к базе данных, база данных заблокирована:, компьютер: ?, пользователь: ?, сеанс: 61511, начат: ?, приложение: ? |
... или тестирования, включающее пересчёт итогов.
Кроме ошибки исключительной блокировки тестирование, включающее пересчёт итогов, может просто зависнуть , если в базу в этот момент зайдёт пользователь.
Почему это происходит, ведь обновлятор устанавливает блокировку сеансов и выгоняет всех пользователей перед началом операции? Каким образом новые пользователи попадают в базу по ходу выполнения операции?
Оказывается при определенных условиях ( а именно пересчёт итогов ) конфигуратор сам (несанкционированно) сбрасывает установленную блокировку сеансов (а заодно код разрешения) в клиент-серверной базе.
Я провёл расследование и выяснил, что это баг в платформе (уже веду переписку с технической поддержкой 1с). Проблема никак не связана с обновлятором и воспроизводится только при помощи конфигуратора.
Для того, чтобы конфигуратор несанкционированно сбросил установленную блокировку сеансов (и код разрешения) необходимо выполнение следующих условий:
- База является клиент-серверной.
- Платформа 1с любая версии 8.3.18, 8.3.19 или 8.3.20.
- В базе накоплены определённые изменения в конфигурации (например, выполнено обновление конфигурации Бухгалтерия Предприятие с версии 3.0.95.24 на 3.0.99.19) без последующего обновления конфигурации базы данных. Отдельно подчеркну, что проблема воспроизводится не на всех обновлениях конфигурации ( а только на тех, когда возникает пересчёт итогов ), именно поэтому я привёл пример конкретного обновления на котором проблема воспроизводится.
Если при выполнении этих 3 условий...
- Установить в базе блокировку сеансов и код разрешения.
- А затем выполнить операцию "Обновление конфигурации базы данных" (хоть вручную через конфигуратор, хоть через обновлятор), либо запустить тестирование и исправление конфигурации с пересчётом итогов (тогда пункт 3 из предыдущего абзаца не важен).
... мы обнаружим, что установленная блокировка сеансов и код разрешения были несанкционированно сброшены конфигуратором (это подтверждается технологическим журналом) по ходу выполнения операции "Обновление конфигурации базы данных" ( а вернее возникшего в процессе выполнения пересчёта итогов ) или тестирования, включающее пересчёт итогов.
И если в этот момент (когда блокировка сеансов сброшена, но операция ещё не закончена) в базу заходят пользователи (вручную или автоматически, так как их предварительно выбросило из базы при блокировке и у них нет пароля), то мы получаем ошибку исключительной блокировки или зависание, если речь идёт о тестировании.
Общение с технической поддержкой 1с
26.10.2021 Вся собранная информация (включающая детальное описание и быстрый способ воспроизведения ошибки) отправлена в техническую поддержку 1с на адрес v8@1c.ru, обращение зарегистрировано под номером HL-405298.
18.11.2021 Получил такой ответ от технической поддержки 1с:
"Ошибка платформы https://bugboard.v8.1c.ru/
Исправлена в будущих версиях 8.3.21+"
А значит, установленная блокировка сеансов будет сбрасываться не только при обновлении базы данных, но и при отдельно запущенной операции тестирование и исправление, включающей пересчёт итогов.
Ошибка исправлена в тестовой 8.3.21.1140.Решение
Как решить проблему не дожидаясь исправления платформы? Для этого я подготовил ряд рекомендаций, а также разработал дополнительную опцию в обновляторе. Итак, поехали.
Назначаем всем пользователям непустые пароли
Потому что, если у пользователя пустой пароль, то становится возможен следующий сценарий:
- Пользователь с пустым паролем оставил базу открытой и ушёл домой.
- Ночью вы сами (вручную или через обновлятор) установили в базе блокировку сеансов (для её обслуживания) и дождались, когда всех пользователей (это функционал типовых) выбросит из базы.
- Да, пользователя выбросило, но на его рабочем месте появилось окно ожидания с попытками (каждую минуту) повторного подключения к базе.
- Попытки повторного входа будут неудачными, ведь в базе установлена блокировка сеансов.
- И тут конфигуратор по ходу выполнения операции "Обновление конфигурации базы данных" несанкционированно сбрасывает (то есть снимает) блокировку сеансов и тот самый диалог ожидания автоматически пускает пользователя обратно в базу! И операция обновления базы данных завершается ошибкой из-за исключительной блокировки.
- Так вот если бы у пользователя был непустой пароль - его бы в базу обратно автоматически не пустило.
Заставляем пользователей вводить пароль
Эту рекомендацию не всегда возможно выполнить целиком. Её смысл в том, что даже если у пользователя непустой пароль, но при этом...
- он прописал его (пароль) в параметрах базы в стартере вот так
- либо зашёл в базу через альтернативный стартер (в настройках которого уже прописаны логин и пароль для входа в базу), например, вот так
... пользователя также пустит обратно в базу автоматически (см. предыдущий сценарий, пункт 5).
Пользователя пускает обратно в базу автоматически потому, что при первоначальном (описанном выше) входе в базу логин и пароль сохраняются в параметрах запуска платформы.
Вопрос какими средствами в этом случае заставить пользователей не прописывать нигде пароль для автоматического входа в базу остаётся открытым.
Заставляем обновлятор контролировать сохранение установленной блокировки сеансов
Заходим в свойства клиент-серверной базы, закладка "Обновление", раздел "Сам процесс":
Здесь включаем опцию "При обновлении конфигурации базы данных (на проблемных релизах платформы 1с) контролировать сохранение блокировки сеансов".
Кроме того, в скриптах у команды из меню "Обновлятор-Методы-Выполнение пакетного скрипта" появился дополнительный параметр keep_sessions_lock, установка которого в true позволит осуществить контроль за сохранением блокировки сеансов (при условии, что она включена в свойствах базы) при выполнении любой команды.
Например:
@run_cmd( script: "%run_1c_d% /UpdateDBCfg -Dynamic-", keep_sessions_lock: "true" ) @run_cmd( script: "%run_1c_d% /IBCheckAndRepair -RecalcTotals -TestOnly", keep_sessions_lock: "true" ) |
По умолчанию данная опция включена и имеет значение "Однократно после" ( рекомендую сразу сменить это значение на "непрерывно в процессе" ).
"Однократно после" означает, что обновлятор считывает состояние блокировки сеансов (а также код разрешения) перед обновлением конфигурации базы данных.
А затем (после окончания обновления конфигурации базы данных) восстанавливает блокировку сеансов (и код разрешения), если они были сброшены конфигуратором.
Эта опция предотвращает дальнейшие проблемы, если блокировка сеансов была сброшена конфигуратором в процессе обновления конфигурации базы данных, но нам повезло и в базу (в процессе обновления конфигурации базы данных) никто из пользователей не попал.
Если это не помогает - установите эту же опцию со значением "Непрерывно в процессе":
В этом случае обновлятор параллельно с выполнением операции "Обновление конфигурации базы данных" будет контролировать (примерно раз в секунду) состояние блокировки сеансов и как только он обнаружит, что конфигуратор несанкционированно сбросил блокировку сеансов, он тут же восстановит её. В этом случае пользователь сможет попасть в базу, если осуществит такую попытку только в ту же самую секунду, когда конфигуратор несанкционированно сбросил блокировку сеансов.
Вот как это будет выглядеть в отчёте:
Как помочь с исправлением ошибки
Ошибка исправлена в тестовой 8.3.21.1140.Друзья, я уже отписался выше, что ошибка зарегистрирована в 1С.
Теперь я прошу вас по возможности зайти на страницу с ошибкой и поставить отметку "Для меня исправление ошибки важно":
Тем самым мы повысим вероятность исправления этой ошибки в одном из ближайших релизов платформы.