1с ошибка разделенного доступа конфигуратор

Содержание: 

1.         Варианты возникновения ошибки разделенного доступа

2.        Файловый режим работы: способы решения ошибки разделенного доступа

3.        Пути решения ошибки разделенного доступа в клиент-серверном варианте работы

4.        Зависшие фоновые задания разделенного доступа в клиент-серверном варианте 

1.  Варианты возникновения ошибки разделенного доступа

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

Пользователи подключены к 1С

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

У пользователя запущена 1С, но не введен пароль

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

Зависший сеанс

Пользователи закрыли все свои окна 1С 8.3, но ошибка все еще осталась, в таком случае, вероятно, остались зависшие сеансы. В таком случае требуется принудительное завершение работы подобных сеансов. Последующие действия следует выполнять только после того, как испробовали методы описанные выше.  

2.  Файловый режим работы: способы решения ошибки разделенного доступа

— С помощью Диспетчера задач.

После завершения активных сеансов в файловом режиме работы, не сохраненная информация пользователей будет утеряна. Завершить сеансы этим способом можно вызвав диспетчер задач (диспетчер задач можно вызвать комбинацией клавиш Ctrl+Alt+Delete), выбрать нужные процессы(1Сv8.exe или 1Сv8c.exe), после этого нажать кнопку снять задачу.

— Перезагрузка сервера, на котором установлена 1С.  

3.  Пути решения ошибки разделенного доступа в клиент-серверном варианте работы

Завершить активные сеансы поможет консоль администрирования сервера, находим в ней нужную нам базу и заходим в меню «Сеансы».

Выделяем мешающие нам сеансы и завершаем их через пункт контекстного меню «Удалить» или соответствующую кнопку на панели.

— Если не удалось удалить сеансы, используя консоль, то пробуем перезапустить службу Агент сервера 1С Предприятия 8.3.

— Если не получается удалить соединение, можно попробовать это сделать средствами в 1С СУБД. К примеру, в MS SQL для 1С, можно открыть Management studio и написать запрос к нужной базе с использованием метода kill <ID>, где ID – номер соединения с СУБД, который так же можно увидеть в консоли администрирования.

— Только если все предыдущие способы не дали нам результата и ошибка все еще сохраняется, то можем перезагрузить сервер. Важно помнить, что к этому методу стоит прибегать только в крайнем случае.  

4.  Зависшие фоновые задания разделенного доступа в клиент-серверном варианте работы

В подобном случае, при повышенной пиковой нагрузке на сервер, сеансы фоновых заданий могут отрабатывать медленно или даже зависать, что так же влечет за собой возникновение данной ошибки.

Фоновые задания, как и обычный сеанс можно попытаться завершить, но после завершения они могут запускаться вновь. Активные сеансы фоновых заданий, как и пользовательские, можно увидеть в консоли администрирования на вкладке Соединения.

Попробовать завершить эти сеансы можно следующими методами:

— Завершить сеанс и обновить список активных соединений, для проверки, не запускаются ли они заново.

— Среди свойств базы найти флажок «Блокировка регламентных заданий включена», после этого снова надо попытаться завершить задание.

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

Специалист компании «Кодерлайн»

Марк Романенков

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

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

 Ошибка исправлена в тестовой 8.3.21.1140. 

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

Обновляется конфигурация базы данных.
ОбщаяКартинка.Информация: Имя не уникально!
Обновление конфигурации базы данных
Обработка структуры базы данных...
Ошибка исключительной блокировки информационной базы.
База данных заблокирована:
пользователь: ?, сеанс : 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. А затем выполнить операцию «Обновление конфигурации базы данных» (хоть вручную через конфигуратор, хоть через обновлятор), либо запустить тестирование и исправление конфигурации с пересчётом итогов (тогда пункт 3 из предыдущего абзаца не важен).

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

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

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

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

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

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

 Ошибка исправлена в тестовой 8.3.21.1140. 

Решение

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

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

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

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

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

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

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

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

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

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

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

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

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

@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С.

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

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