1с ошибка исключительной блокировки информационной базы com соединение

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

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

Появление ошибок в 1С является нормальным рабочим процессом. Но это не из-за того, что программа как-то плохо сделана. Большинство ошибок возникает от того, что пользователь что-то недоглядел или пропустил. Поэтому важно уметь быстро и оперативно диагностировать и решать такие проблемы. Особенно если работа не терпит отлагательств.

От чего возникает «Ошибка исключительной блокировки информационной базы»

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

Во время работы с базой есть активные сеансы пользователей

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

Список пользователей, которые сейчас не вышли из 1С, можно увидеть в разделе «Администрирование», в подразделе «Активные пользователи». Либо в самом сообщении об ошибке.

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

Подробнее: На сервере 1С: Предприятия произошла неисправимая ошибка. Приложение будет закрыто.

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

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

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

Но если найти пользователя не удаётся, то можно попытаться отыскать его процесс в диспетчере задач и завершить его. Для запуска диспетчера задач, нажмите правой кнопкой мышки на панель задач, а затем «Диспетчер задач» (или можно просто нажать сочетание клавиш Ctrl + Alt + Del).

Найдите процессы с названиями 1Cv8.exe и/или 1Cv8c.exe, и выделите мышкой.

Затем внизу диспетчера нажмите «Снять задачу».

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

Ошибка исключительной блокировки информационной базы такого характера возникает в файловых базах данных.

Зависшие сеансы в 1С

Если вы убедились в том, что все пользователи вышли из своих учётных записей, а также нет пользователей, которые запустили базу, но не ввели пароль, то проблема может быть в зависших сеансах. Определить, какой конкретно пользователь завис, будет также затруднительно, так как в активных пользователях он может не отображаться.

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

Вам может быть это интересно: Соединение с сервером баз данных разорвано администратором в 1С.

Зависшие фоновые процессы

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

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

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

Перейти к контенту

23.03.11 — 11:01

8.2 не могу выгрузить базу из конфигуратора, пишет ОШИБКА ИСКЛЮЧИТЕЛЬНОЙ БЛОКИРОВКИ ИНФОРМАЦИОННОЙ БАЗЫ?

1 — 23.03.11 — 11:02

перегрузи сервер 1С.

2 — 23.03.11 — 11:02

монитор активности 1с и скуля все знает…

3 — 23.03.11 — 11:02

выгони всех пользователей, перезапусти конфигуратор.
Не поможет — перезапусти лужбу сервера 1с

4 — 23.03.11 — 11:03

и перестань орать, и вообще паниковать. давай больше информации

5 — 23.03.11 — 11:08

все перечисленное было проделано и не помогло

6 — 23.03.11 — 11:09

тогда переходи на 64-битные ОС и сервер 1С

7 — 23.03.11 — 11:19

порт 1541 под 8.2 это правильно?

8 — 23.03.11 — 11:20

(5) не верю

9 — 23.03.11 — 11:21

(5) посмотри в консоли, в сеансах…

10 — 23.03.11 — 11:21

(6) не а,

11 — 23.03.11 — 11:23

(8) а я верю… потому что однажды после физической перезагрузки сервера у меня тонкий клиент, запущенный с этого же компьютера, остался висеть в сеансах… после этого можно поверить во что угодно…

12 — 23.03.11 — 11:24

клиент толстый

13 — 23.03.11 — 11:25

(11) но его спокойно можно вырубить из консоли кластера
так что — не верю ))

14 — 23.03.11 — 11:26

2(12)толстым клиентом выгружаешь базу? а говорил же из конфигуратора…

15 — 23.03.11 — 11:27

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

15 — 23.03.11 — 11:27

это УПП на платформе 8.2 было проведено 2 обновления до 1.3.6.1 после этого перестало выгружаться

17 — 23.03.11 — 11:28

(15) ты сеансы посмотрел?

18 — 23.03.11 — 11:29

(15) периодически тоже такое наблюдаю, но это такая мелочь по сравнению с мировой революцией )

19 — 23.03.11 — 11:29

(18)сервер 1С 32-битный?

20 — 23.03.11 — 11:31

(19) скорее всего, не помню )

21 — 23.03.11 — 11:32

был бы 64-битный — не наблюдал бы

22 — 23.03.11 — 11:33

(21) я же говорю — это такая мелочь… ))

23 — 23.03.11 — 11:35

(17)да

24 — 23.03.11 — 11:35

Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005,

25 — 23.03.11 — 11:37

26 — 23.03.11 — 11:48

select * FROM dbo.Config WHERE DataSize > 125829120  сделал строчка есть

27 — 23.03.11 — 11:50

2(26) эта реплика требует какого-то ответа?

28 — 23.03.11 — 12:12

Сервер 1С 32-битный SQL 2005

29 — 23.03.11 — 12:13

а эта реплика требует ответа?

30 — 23.03.11 — 12:14

(29) +1
дальше последует описание аппаратной платформы и версии dll

31 — 23.03.11 — 12:15

2(30) при чем все укладывается в (25) — то есть ответ что делать — очевиден…

32 — 23.03.11 — 12:17

(31) ответ не очевиден,

33 — 23.03.11 — 12:18

2(32) отчего же не добавляешь?

34 — 23.03.11 — 12:19

(33) западло, пусть ТС лезет в поиск

35 — 23.03.11 — 12:32

2(34) помимо тех, что описаны по ссылке в (25) — я не нашел…

36 — 23.03.11 — 12:33

(35) плохо искал,
есть в базе знаний

37 — 23.03.11 — 12:35

(36) и самый прикол
ты в статье засветился 
и на момент её написания,
верный ответ знал

38 — 23.03.11 — 12:35

2(36) ктож виноват, что форумный поиск не показывает что у него есть в базе знаний

39 — 23.03.11 — 12:36

эта ошибка не связан с использованием 32-битной 1с?

40 — 23.03.11 — 12:37

41 — 23.03.11 — 12:43

(40) прочитал а также прочитал v8: Не сохраняется конфигурация в файл. понял что ошибка связана с превышением размера чего-то хранящегося в хранилище, поэтому думаю может тут уже скуль 2008 нужен чтоб проблем не было или сервак 64 -разрядный?

42 — 23.03.11 — 12:45

43 — 23.03.11 — 12:45

что по-твоему такое «сервер приложений»?

44 — 23.03.11 — 12:52

насколько я понимаю 1с использует трехзвену СУБД->сервер приложений->клиент

45 — 23.03.11 — 12:56

да, и тебе уже сказали, что нужно использовать 64-битный сервер 1С… и именно это написано и по ссылке в (25)

46 — 23.03.11 — 12:58

По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ  120 mb. v8: проблема совместимости серверов 1С и SQL

47 — 23.03.11 — 12:59

2(46) ну, так ты удалил свою запись, содержащую двоичные данные более 120 мб?

48 — 23.03.11 — 13:52

(47) нет не удалил

49 — 23.03.11 — 13:54

я вот не пойму 1с 8.2 с sql 2008 дружит или нет ?

50 — 23.03.11 — 14:04

(49) еще как дружит

51 — 23.03.11 — 14:10

52 — 23.03.11 — 14:11

йти на 64-битный сервер 1С

53 — 23.03.11 — 14:22

(52) удалю я запись а при следующем обновлении опять удалять?

54 — 23.03.11 — 14:23

может проблема в том что у меня sql 2005 sevice pack 2, а не service pack3?

55 — 23.03.11 — 14:24

56 — 23.03.11 — 14:25

2(54) нет, проблема в том, что ты просто не читаешь то что тебе пишут.

57 — 23.03.11 — 14:25

64-битный на 32-битную винду?

58 — 23.03.11 — 14:26

нет, на 64-битную винду или 64-битный линукс

59 — 23.03.11 — 14:28

это надо сервак новый купить….весело

60 — 23.03.11 — 14:48

(58) и ключ 1С не забыть — полноразрядный

61 — 23.03.11 — 14:54

(60) ключи от 8.1 32-разрядной не подойдут?

62 — 23.03.11 — 14:58

(61) на 64-битной оси 32-разрядный сервер 1С прекрасно себя чувствует, но для 64-разрядного сервера 1с нужно покупать другой ключ…

63 — 23.03.11 — 14:59

ключи к 64-разрядной от 32-разрядной не подойдут.

запись удалил, конфу снчала сохранил , потом загрузил.. база выгружается.
ВСЕМ СПАСИБО

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

 Ошибка исправлена в тестовой 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С.

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

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