Ошибка блокировки фоновое задание

Случается, что при работе с программой 1С возникает подобная ошибка — ошибка блокировки данных:

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

• Пользователи не вышли из системы 1С

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

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

В таком случае у пользователя остается висеть подобное окно:

Сеанс такого пользователя найти сложнее, так как он не отображается в окошке Активные пользователи. Более того, информация об ошибке не содержит какой-либо полезной информации:

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

• Зависшие сеансы

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

Способы завершения зависших сеансов в файловом варианте

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

• Перезагрузить сервер, на котором установлена файловая система 1С

Способы завершения зависших сеансов в клиент-серверном варианте

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

• Выделить нужные зависшие сеансы и удалить их через пункт контекстного меню;

*Если в меню Сеансы нет сеансов, их стоит поискать в меню Соединения. И попробовать аналогично удалить.

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

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

В клиент-серверном варианте частым источником возникновения ошибки исключительной блокировки информационной базы являются повисшие фоновые задания.

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

Чтобы их удалить можно попробовать следующие способы:

• Удалить их несколько раз подряд и проверить, не появляются ли они вновь.
• В свойствах базы установить флаг Блокировка регламентных заданий включена, и после этого еще раз попробовать удалить зависшее задание.

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

Какие бывают блокировки в 1С?

Давайте рассмотрим, как выглядит типичная монопольная блокировка в 1С.

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

Я думаю, вы прекрасно знаете, что в 1С есть два режима блокировок: автоматический и управляемый.

• В автоматическом режиме все просто:
  • При любом чтении ставится S-блокировка.
  • А при любой записи ставится X-блокировка – причем, блокировки есть только на сервере СУБД, 1С никаких блокировок не ставит.
• Гораздо больше интересен управляемый режим. Его главная особенность в том, что в 8.2 и в 8.3 блокировки работают по-разному.
  • Например, в 8.2 у вас любое чтение будет ставить S-блокировку. Причем, чтение – это не просто Запрос.Выполнить(), но и Ссылка.Реквизит, Ссылка.ПолучитьОбъект() и т.д. 
  • А в 8.3 без режима совместимости уже блокировок на чтение не будет. Таким образом, 8.3 безусловно выигрывает в плане параллельности работы.
  • Ну а дальше начинается самое интересное – например, для конструкции НаборЗаписей.Прочитать() в управляемом режиме 8.2 у вас будет S-блокировка на сервере СУБД (это естественно). Но кроме этого также будет разделяемая блокировка на сервере 1С, причем это проявляется и в 8.2, и в 8.3. И главная проблема в том, что эта разделяемая блокировка у вас будет длиться до конца транзакции – пока транзакция не закончится, данные будут блокированы.
    Поэтому рекомендация номер один – если набор записей вам нужен только для чтения, лучше использовать запрос, а не объектную модель. Тогда вы ничего блокировать не будете, а если и будете, то ненадолго.
  • Естественно, при любом изменении данных (запись, проведение, удаление) будет ставиться исключительная блокировка на сервере 1С и эксклюзивная на сервере СУБД.

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

Длительность блокировок в управляемом режиме

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

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

Что касается конструкции Запрос.Выполнить(), то если это 8.2, блокировка будет сниматься сразу после выполнения запроса, а если это 8.3 (либо в вашей СУБД MS SQL включен режим Read Committed Snapshot Isolation), тогда блокировки вообще не будет. Поэтому если у вас 8.2 или 8.3 в режиме совместимости с 8.2, я вам всячески рекомендую включить режим Read Committed Snapshot Isolation – у вас в любом случае повысится параллельность работы.

Вот типичный пример: можно сначала поставить блокировку, выполнить какие-то расчеты и проверки (посмотреть, заполнен ли реквизит и т.д.) и только потом транзакцию закончить – тогда у вас время блокировки будет долгим. Но лучше, если есть такая возможность, поступить по-другому: сначала сделать всякие расчеты (проверку заполнения и пр.), а блокировку наложить уже в самом конце. Тогда у вас время блокировки будет меньше, и, соответственно, риск возникновения ожиданий также снизится. Поэтому старайтесь наложение явных управляемых блокировок или любую запись в базу данных делать как можно ближе к концу транзакции.

Наиболее частые причины блокировок

Запрос со сканом

Чаще всего ожидание на блокировке возникает в случае неоптимального запроса. Например, у вас есть пользователь Иванов, который в процессе проведения документа заблокировал несколько позиций номенклатуры – только то, что ему было нужно. И есть пользователь Петров, который выполнил в транзакции запрос со сканированием (Запрос.Выполнить()). И если при чтении этот запрос нарвется на номенклатуру, которая была заблокирована Ивановым, то в случае использования вами версии 8.2 (либо 8.3 в режиме совместимости с 8.2), он остановится и будет ждать по умолчанию 20 секунд. При этом пользователь Петров встанет в ожидание, что, ему, конечно, не понравится. Как решить эту ситуацию? Казалось бы, ответ очевиден – можно взять и переписать запрос так, чтобы он не читал лишних строк, тогда все будет замечательно.

А если этот запрос платформенный? Или этот запрос используется в типовой конфигурации, которую вы по очевидным причинам изменять не можете – что тогда делать? Какие есть варианты?

Выключить режим совместимости? Правильнее сказать – перекреститься, создать копию, недельку потестировать и потом выключить, потому что если вы сразу выключите, у вас могут случиться «веселые выходные», а может быть не только выходные.

Еще один вариант – это включить режим версионирования для MS SQL Server. Сразу оговорюсь, что описанная ситуация возможна только в СУБД-блокировочнике, потому что если у вас СУБД-версионник, там этой ситуации быть не может. А если вы включаете Read Committed Snapshot Isolation, тогда у вас MS SQL начинает работать почти как версионник. И ваш запрос не будет блокировать строки.

В 1С нет «волшебной таблетки», но включение режима Read Committed Snapshot Isolation – ближайший аналог этой «волшебной таблетки». Вы минимальными действиями сразу резко сможете снизить количество ожиданий в вашей базе. Для этого вам всего лишь нужно выполнить несколько строк приведенным на скриншоте скриптом в MS SQL сервере, и вы сразу получите очень хорошее повышение параллельности работы. Конечно, это имеет смысл только для управляемого режима блокировок в конфигурации 1С. Для автоматического режима включать на сервере СУБД режим RCSI смысла нет.

Отсутствие режима разделения регистров

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

Этот режим можно включить в конфигураторе в свойствах регистра на закладке «Прочее» – там есть галочка «Разрешить разделение итогов». Когда вы создаете новый регистр накопления, эта галочка уже по умолчанию включена. Тем самым, разработчики намекают, что использовать эту возможность очень удобно, потому что она помогает писать в регистр параллельно, даже если данные у вас пересекаются.

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

Перемещение границы последовательности при проведении

Если у вас используется последовательность, в которой сдвигается граница при проведении документов, то, скорее всего, у вас возникают ожидания на блокировках. Например, два документа, у которых измерение в последовательности совпадает, параллельно провестись не смогут – кто-то кого-то будет ждать.

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

Длительные транзакции

Старайтесь делать максимально короткие транзакции:

• Выносите всякие проверки и расчеты за пределы транзакции – любую запись, любое наложение блокировок надо делать в самом конце.
• Ни в коем случае никаких диалоговых окон в транзакции делать не нужно, особенно, если используется толстый клиент. Мы сталкивались с такими случаями, что у бухгалтера при проведении документа выскакивало диалоговое окно с кнопками «Да» и «Нет». И пока она решит, что нажать, пока с кем-нибудь посоветуется, пока кому-то позвонит – у нее это окно будет висеть, и все это время транзакция будет активна, и, соответственно блокировка тоже будет активна – ее время будет очень долгим. Так делать не нужно.
• Как можно еще ускорить время транзакции? Можно ускорить код, который там выполняется. Ускорить запросы, если вы это умеете делать. Это сразу даст резкий прирост производительности.
• Еще один вариант – это ускорить запись в регистры. Как? Можно программным путем, а можно аппаратным. Например, если вы купили нормальные SSD-диски, то скорость записи у вас естественно вырастет – даже запросы станут выполняться быстрее. И, соответственно, время транзакции также уменьшится. Это не значит, что одним апгрейдом дисков можно решить проблему блокировок, но хотя бы можно сгладить этот эффект – он будет уже не так заметен.

Эскалация в многопоточном режиме

Я очень надеюсь, что многие из вас используют многопоточность для повышения производительности всяких загрузок, выгрузок, перепроведения документов, при свертке больших объемов данных. Это действительно мощная возможность, которая позволяет получить ускорение в несколько раз. Однажды мне необходимо было свернуть регистр, содержащий более 100 миллионов строк, причем, неактуальные остатки нужно было куда-то выгрузить, оставив в базе только некоторый актуальный промежуток времени. Я подумал и решил реализовать для этого случая многопоточную обработку. В результате у меня получилось, что эти потоки стали блокировать друг друга, хотя их данные вообще никак не пересекались (в каждом потоке были разные регистраторы) – тем не менее, возникало ожидание на блокировке.

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

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

Когда обычно в 1С возникает эскалация? Чаще всего это какая-то тяжелая операция – закрытие месяца, расчет себестоимости и пр. – когда у вас в одной гигантской транзакции начинает проводиться много документов, блокируется вся таблица и в это время никто работать не может – параллельность падает. Такие операции необходимо учитывать отдельно и проводить их в нерабочее время, потому что в параллельном режиме вы их обработать не сможете.

Ошибка платформы – блокировка при использовании разделителя области данных

В платформе есть несколько ошибок, которые приводят к излишним ожиданиям на блокировке. Например, есть ошибка, которая меня очень удивила. Ситуация следующая – мы собрали данные об ожиданиях и увидели, что строка Запрос.Выполнить() накладывает управляемую исключительную блокировку, чего в принципе быть не может и не должно. Когда мы это увидели, мы подумали, что инструмент «сбоит». Еще раз загрузили данные. Все перепроверили. Действительно, накладывает. Оказалось, что такая ошибка появилась в платформе 8.3.6. При чтении – неважно, Запрос.Выполнить() или Константа.Прочитать() – вообще при любом чтении – платформа накладывала управляемую исключительную (Х) блокировку на поле, которое является разделителем данных и параллельность сразу падала. Причем, блокировка была именно исключительной.

Вот такая платформенная ошибка.

К счастью для нас клиент, у которого эта проблема проявилась, вообще не использовал этот разделитель данных, поэтому мы просто у реквизита сняли признак того, что он является разделителем. И все, ошибка исчезла. Но исправлена она или нет, я до сих пор не знаю. Могу точно сказать, что в 1С про эту ошибку знают, но когда они ее исправят, мне, к сожалению, не известно. Поэтому будьте готовы, что у вас такое тоже может быть.

Ошибка платформы – скан индекса регистра расчета

Также мы часто сталкиваемся с ошибками платформы по работе с регистром расчета. С точки зрения производительности у него вообще проблем очень много, потому что регистр расчета – это единственный объект в 1С, который не имеет кластерного индекса. Поэтому, когда вы записываете в регистр расчета несколько сотен строк (если строк мало, то эта ошибка не воспроизводится), или чистите там движения (записываете туда пустой набор движений) – будет производиться скан индекса таблицы регистра расчета. А поскольку это запрос платформенный, вы его поправить никак не сможете, и, так как это – удаление (накладывается X блокировка), то включение режима Read Committed Snapshot тоже никак не меняет ситуацию.

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

Еще одна проблема регистра расчета проявляется при чтении и заключается в том, что платформенный запрос, который читает данные из регистра расчета, тоже сканирует индекс. Но здесь уже помогает именно включение либо Read Committed Snapshot, либо, если у вас 8.3, вы можете убрать режим совместимости с 8.2, тогда этой проблемы у вас уже не будет.

Ошибка платформы – невозможность параллельной записи в периодический независимый регистр сведений

Очень старая ошибка, про которую в 1С тоже прекрасно знают, но, тем не менее, она до сих пор не исправлена – это невозможность параллельной записи в периодический независимый регистр сведений. Казалось бы, если у вас периоды разные (измерения совпадают, но периоды разные), вы могли бы записывать туда данные параллельно. Но этого не происходит, хотя должно бы быть. Потому что на сервере 1С накладывается излишняя блокировка по дате. На проектах эта ситуация встречается не часто – регистр сведений очень редко становится «узким местом» для блокировок. Обычно проблемы возникают из-за регистра накопления, либо из-за  регистра бухгалтерии. Но, тем не менее, если вы с этим столкнетесь, можете попробовать сделать период измерением. Да, конечно, в этом случае никаких виртуальных таблиц (срез первых, срез последних) этот регистр сведений формировать уже не будет, но зато вы сможете спокойно писать в него параллельно, а запрос для получения среза первых/последних можно и самим формировать.

Рекомендации

Какие можно дать рекомендации?

• Во-первых, переходите на управляемый режим блокировок. Я думаю, это довольно очевидно, потому что если у вас используется автоматический режим, вы можете даже не удивляться вопросам «Почему у нас параллельность работы маленькая, почему много блокировок?»  Сначала перейдите на управляемый режим, и, если после этого у вас проблемы останутся, тогда уже можно будет дальше разбираться.
• Когда перевели конфигурацию в управляемый режим блокировок, обязательно должен быть включен режим СУБД Read Committed Snapshot Isolation. Это прямо Must Have –сразу будет резкий прирост по параллельности работы.
• Используйте разделитель итогов для регистров. Там, где нет контроля остатков, обязательно нужно включить, чтобы не было ожиданий.
• И НаборЗаписей.Прочитать() – старайтесь вообще для чтения не использовать, потому что при этом будет наложена управляемая блокировка, которая будет «висеть» до конца транзакции. Зачем вам это нужно? Читайте данные запросом, и блокировок тогда вообще не будет, если у вас 8.3 без режима совместимости или включен режим Read Committed Snapshot.

• По поводу границы последовательности – тоже постарайтесь принять по умолчанию, что границу двигать только регламентным заданием в нерабочее время. При проведении не двигать.
• Большие транзакции делить на несколько. Чем проводить миллион документов в одной транзакции, лучше сделать мелкие транзакции по 100 документов, по 1000 документов – еще лучше, если в многопоточном режиме. Это будет более стабильно.
• Всякие расчеты, проверки и пр. делайте за пределами транзакции. Время транзакции должно быть минимальным, как можно меньше.

Пример решения проблемы блокировок

Как еще можно избавиться от излишних ожиданий?

Допустим, у вас есть торговые представители, которые после окончания рабочего дня (в 6 часов вечера), отправляют документы в базу. А там, как только эти документы через мобильный интернет приходят, они сразу пытаются загрузиться и провестись. В результате, если торговые представители заказали один и тот же товар с одного и того же склада, возникает ожидание, потому что они обращаются к одним и тем же данным, и поскольку там есть контроль остатков, разделитель итогов не поможет и кому-то кого-то придется ждать.

Как этого можно избежать? Можно при загрузке документы создавать, но не проводить, а потом написать механизм, который, например, реализует это дальнейшее проведение в многопоточном режиме, где каждый поток будет проводить документы по своему складу. Разнести, таким образом, эти процессы во времени: первый поток проводит документы по одному складу, второй поток – по второму складу и т.д. Тогда проблема будет решена.

Блокировки и оборудование

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

Как влияет на оборудование оптимизация блокировок? Например, вы с автоматического режима перешли на управляемый, или взяли и включили Read Committed Snapshot. Пока система ждет, она оборудование не использует и оно у вас в этом случае простаивает. А как только у вас система заработала на полную мощность, ожиданий нет, у вас сразу идет резкий прирост, резкая нагрузка на оборудование. И, в зависимости от того, в каком состоянии оно у вас на данный момент находится, это может быть критично. Например, если сервер у вас был загружен на 80%, а вы еще и блокировки свои устранили, он вообще может «лечь». Это обязательно нужно учитывать.

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

Инструмент для анализа блокировок

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

Это обработка «Текущие блокировки MS SQL Server и 1С» – она показывает вам, кто заблокировал, что заблокировал, какие конкретно данные именно в терминах 1С. Я эту обработку недавно выложил на Инфостарт – можете ее скачать, посмотреть.

Здесь – открываете, заполняете настройки.

Если хотите увидеть блокировки 1С, включаете флаг «Отображать блокировки 1С» — у вас в течение одной минуты должен включиться технологический журнал. И после этого, когда минута прошла – вы сможете увидеть, какие именно блокировки у вас наложены в базе данных на текущий момент(например, в момент, когда вы встанете на точке останова после строки Движения.Записать() и пытаетесь провести два документа, которые пересекаются по данным – и в первом и во втором документе используется один и тот же товар).

Итак, мы ставим точку останова и теперь по очереди проводим первый документ, а потом в другом пользовательском сеансе проводим второй документ – он, естественно, встает в очередь. Получается ожидание.

Как эту ситуацию отображает обработка? Она показывает, что пользователь Петров заблокирован пользователем Администратор. И при этом вы можете увидеть, что именно заблокировал Администратор и что именно заблокировал Петров.

Нежирным шрифтом показаны блокировки СУБД – можно увидеть, в какой таблице, в каком индексе, какой состав индекса, какой статус блокировки («установлена» или «ожидание»).

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

Жирным шрифтом отображаются блокировки 1С – также можно поглядеть, что именно было заблокировано.

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

***************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2023 DEVELOPER. Больше статей можно прочитать здесь.

В 2023 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2023 в Москве.

Выбрать мероприятие.

Содержание:

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

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

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

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

2.     Причины блокировки базы 1С

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

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

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

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

Александр Суворов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фоновое задание не дает обновится

Я

   aleks100

30.11.19 — 16:12

   ДенисЧ

1 — 30.11.19 — 16:14

Не отрубил задание какое-то.

Консоль заданий что говорит?

   vde69

2 — 30.11.19 — 16:22

   Провинциальный 1сник

3 — 30.11.19 — 16:22

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

   aleks100

4 — 30.11.19 — 16:34

конфигурация в файловом варианте

   aleks100

5 — 30.11.19 — 16:36

(1) первый запуск после обновления

   aleks100

6 — 30.11.19 — 16:42

выполняется задание слияние индекса Слияние индекса полнотекстового поиска доступа

   aleks100

7 — 30.11.19 — 16:43

как узнать какое именно фоновое задание блокировало?

   ДенисЧ

8 — 30.11.19 — 17:13

(7) см (6)

   aleks100

9 — 30.11.19 — 17:55

(8) закончил это задание, посмотрел  в обработке регламентных заданий и потом только обновилось нормально

   aleks100

10 — 30.11.19 — 17:55

это задание видимо блокировало

   rphosts

11 — 30.11.19 — 18:54

(3) вариант 1: зашёл, заблокирвоал другим вход, снёс пассажиров из консоли.

варант 2: заблокировал с кодом разблокировки, зашёл с кодом разблокировки, снёс пассажиров из консоли

   Провинциальный 1сник

12 — 30.11.19 — 18:58

(11) Если заблокировать начало сеансов — то фоновое задание обновления ИБ не запустится. Пробовал.

   rphosts

13 — 30.11.19 — 19:08

(12) впихуй в код процедуры ПриНачалеСеанса или как там его… ну например если это не BackGround и время входа ну пусть 22:00 — 04:00 — Отказ = Истина.

   Провинциальный 1сник

14 — 30.11.19 — 19:13

(13) Не, ну это уж слишком. Речь о типовом обновлении типовой конфигурации. Как-то не продумано это.

   rphosts

15 — 30.11.19 — 19:15

(14) вы не вкурили расширения?

   Провинциальный 1сник

16 — 30.11.19 — 19:18

(15) То есть, чтобы установить штатное обновление, нужно предварительно расширение писать с костылями?

   Провинциальный 1сник

17 — 30.11.19 — 19:22

Реально не хватает в сервере 1с специального «режима обслуживания», когда запускаются только сеансы администратора и фоновые задания, иницированные им. А то они гордятся что от монопольного режима ушли, а толку то? Всё равно он нужен. Ну или пусть пишут процедуры обновления без требования включения монопольного режима попеременно с фоновыми заданиями.

   rphosts

18 — 30.11.19 — 19:24

(16) в типовых есть ограничение на время работы пользователей?

   Aleksey

19 — 30.11.19 — 19:39

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