Ошибка блокировок при выполнении транзакции 1с. Как я диагностировал проблемы блокировок. Большое количество выполняемых операций

«Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки» — достаточно часто встречающая ошибка в 1С 8.3 и 8.2, связанная с конкуренцией за использование ресурсов в системе.

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

Получите 267 видеоуроков по 1С бесплатно:

Выполнение большого количества операций

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

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

Ошибка в конфигурации

Кроме ошибок в коде часто встречаются методически неверные решения. Например, — он сам по себе подразумевает последовательное проведение документов. Партионный учет можно заменить на РАУЗ — этим Вы серьезно повысите производительность системы.

Как исправить эту ошибку в 1С 8.3?

В любом случае, появление ошибки «Конфликт блокировок при выполнении транзакции» говорит о необходимости инспекции системы, особенно для средних и крупных информационных систем в клиент-серверном режиме работы (MS SQL, PostgreSQL и т.д.). Если это проигнорировать на раннем этапе, возможны необратимые последствия позже, когда работа системы будет особенно важна (в период сдачи отчетности).

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

Всем привет!

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

Очевидно, что здесь нет проблемы взаимоблокировок, здесь просто какой-то сеанс поставил блокировку и "забыл" убрать. При этом проблема грозила серьезными последствиями - не проводился документ Реализации товаров и услуг. В базе единовременно работает около 100 человек, и невозможно выполнить типовую и частую операцию!

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

Первый день - проблема появилась днем, поначалу казалось, что проблема в удаленном пользователе, который засел в Конфигураторе. Было похоже, что просто выполнение остановилось на точке, и блокировка, естественно, не снялась. Через пару часов удалось освободить конфигуратор, но проблема не ушла. Убивать принудительно конфигуратор было крайне нежелательно, возможно, в нем работали. После этого в ход пошел гугл. Нашел статью на этом сайте, в которой пишется, как найти блокировки в СУБД MS SQL, проверил, блокировок на уровне СУБД не было. Странно. Далее были попытки настроить тех. журнал. Настроил, а дальше что? За 15 минут пара гигов логов! Как их читать, что искать? Неизвестно.

Нашел статью, как посмотреть, что заблокировано через SQL Trace. Да даже если найду, дальше что? Мне нужен сеанс!

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

На третий день глянул вебинар, рассказали про интересный и эффективный способ поиска проблемы. Запомнил, но проблема больше не возникала. Прошла неделя и вот оно - опять блокировки! Потираю руки и начинаю действовать.

Первое - настраиваем журнал. Да, без него никак, но теперь я умею его читать. Ставим два события: первое TLOCK, второе TTIMEOUT. Первое отображает все события блокировки, второе показывает блокировки, которые не смогли установиться в отведенное им время. На самом деле, скорее всего, достаточно только TTIMEOUT.

Копируем файл техжурнала в отведенное место, летим в программу, вызываем блокировку, получаем сообщение и убираем или переименовываем файл техжурнала. Нам же не нужны тонны инфы о других блокировках!

Переходим в папку rphost_PID, находим текстовые файли и делаем поиск по слову TTIMEOUT. Видим строку:

К слову, папок rphost_PID может быть несколько, все зависит от того, сколько рабочих процессов запущено на сервере.

А дальше все просто: смотрим в конец строки - WaitConnections = 8239, это наш номер СОЕДИНЕНИЯ. Заходим в консоль сервера, переходим в Соединения, находим этот номер и смотрим номер сеанса. В моем случае на одного пользователя было два сеанса - сбойный и какой-то другой. Грохнул сеанс, на который указывал техжурнал. И о чудо! Все заработало, радости нет предела! Но, как выяснилось позже, сеанс был не зависший:), в нем работали. Поэтому на будущее - желательно связываться с пользователем и предупреждать.

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

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

Конфликт блокировок в 1С 8.3 и его значение

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

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

Причины возникновения ошибок блокировки в 1С

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

Если не брать идеальные варианты, то конфликты блокировок 1С встречаются по следующим причинам:

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

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

• Неоптимальные запросы;
• Запрос остатков в начале действий;
• Непонимание предназначения объектов конфигурации и их неправильное применение;
• Избыточность заложенных в системе или дополнительно разработанных блокировок.

Как исправить конфликт блокировок в 1С 8.3

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

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

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

Быстрое решение конфликта блокировок 1С

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

Для быстрого решения проблемы существуют два пути:

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

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

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

Большое количество выполняемых операций

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

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

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

Регламентные задания

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

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

«Зависшие сеансы»

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

По многочисленным комментариям на просторах интернета подобные ситуации чаще встречаются при использовании сетевых ключей защиты. Если ситуация с «зависающими сеансами» повторяется систематически, это причина произвести тщательную проверку и обслуживание системы и серверов (если база клиент-серверная).

Ошибки при написании конфигурации

Все типовые конфигурации разработаны квалифицированными специалистами и экспертами. Каждая система тщательно тестируется и оптимизируется для более быстрой и корректной работы в ней.

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

Большая вероятность, что конфликт блокировки возник именно из-за ошибок разработчика, если он возник после обновления программы. Для проверки можно просто «откатить» доработки, либо произвести рефакторинг кода.

Вопрос: УТ11.1. Пакетное создание Реализаций. Конфликт блокировок

Ответ:
не надо выключать) переведи их на ночь - там может и расчет себестоимости и индексы поиска считаются.

Вопрос: Конфликт блокировок при выполнении транзакции

Ответ: () Включи профайлер в это время на события Lock:Acquired и Lock:Escalation. Потом доложи что поймал.

Вопрос: Восстановление базы (конфликт блокировок)

Симптомы: при попытке отмены проведения сф получаем конфликт блокировок, даже если один пользователь в базе. ТИИ (проверка логической и ссылочной целостности) валится с конфликтом блокировок, создание бекапа через sql management studio - то же ("Превышено время ожидания типа кратковременной блокировки буфера 3 для страницы").

Хотим попробовать залить cf недельной давности, но что-то надежд мало.

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

Вопрос: УТ10. Конфликт блокировок

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

Если обработчиком кнопки "Ок" сделать свою процедуру, где последовательно запускать "ОбработкаПроведения", а потом процедуру, например, СформироватьПодчиненныеДокументы, затем РассчитатьЗарплату и т.п. Не уверен, что такой вариант поможет. Добавлять кнопки на которые навешивать формирование документов не подойдет, т.к. пользователи будут забывать про нее.

Ответ:

Нет, это не Рарус, это БитАвто

Вопрос: 1c конфликт блокировок при открытии формы документа

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

Вопрос: ошибка SQL2000 в процессе выполнения транзакции в 1С77

При выполнении транзакции произошла ошибка!
SQL State: HYT00
Native:0 Message: Время ожидания истекло.

в итоге провести документ не удается. Это может длиться 20 мин., а может и 1 час.
Как с этим бороться, где копать?

С Уважением,
Steve242

К сообщению приложен файл. Размер - 21Kb

Ответ:

штатный perfmonitor винды показал что на Терминальнике идет адовая загрузка системного диска C:\.
Все остальное: Память, CPU - на обоих серверах(терминальник и скуля) практически никаких аномальных всплесков не отображает.

я создал RAMdrive на 2Gb (из 12Gb, имеющихся на терминальном сервере физически) и пытаюсь перенаправить туда tempовые системные каталоги профилей пользователей терминала.
пока как-то так.

Вопрос: Еще раз, про Конфликт блокировок при выполнении транзакции

Проблема описана хорошо на форумах. Но для моего случая Решения не видел. Опишу мою проблему пошире.
УПП 1С:Предприятие 8.2 (8.2.19.90) редакция 1.3 (1.3.74.1)
возникает ошибка такая ошибка.... Везде. Почти при проводке каждого документа.
А Эта, ниже при...- выгрузике информационной базы в.Конфигураторе

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

Все после этого ПРОВОДКИ ЛЮБЫХ ДОКУМЕНТОВ приводит в ошибки блокировки.
Думаю что проблема в MSSQL . Помогите, кто встречался с этой проблемой. Может
поможет переход на новую версию.

Ответ:

попробуйте сделать dbcc checktable with no_infomsgs для таблицы этого регистра. По идее должны быть ошибки

Вопрос: Блокировки при подписке на РТиУ

Коллеги подскажите. Конф Упп 1.3.
Компания включает несколько фирм. Пусть фирма 1 - главная, фирма 2 - продажная. Есть подписка на проведение РТиУ в момент, когда из фирмы 2 происходит продажа внешним контрагентам. Подписка создает автоматическую перепродажу(из фирмы 1 в 2): создается еще одна РТиУ и расходный ордер, плюс создает поступление товаров и услуг в фирму 2.
Плюс я сделал еще подписку на эту РТиУ в момент перепродажи просто происходит запись в свой регистр определенных данных.

Так вот периодически у пользователя, который делает реализацию внешним контрагентам - происходит конфликт блокировок при выполнении транзакции. Главное день может не быть проблем - все проводится, а бывает просто пользователь замучает: не проводится и все(конфликт блокировок), регламентные в этот момент не выполняются(если выполняются, понятно что блок из за них). Я полагаю дело в подписках, т.к. проблема возникает у юзера, который как раз делает продажу из фирмы 2.
Как оптимизировать этот момент?
Подписки выполняются после события, как они могут влиять? Не могу понять, где косяк. Вообще все события происходят неявно в 1 транзакции? Может перепродажу надо сделать в другой надо? И вообще косяк в самом доке РТиУ или все таки в перепродажах(других РТиУ, РО, ПТиУ), которые создаются автоматом, как понять?

Ответ:

У меня только при закрытии бывает тр-тр-тр, видимо какой-то замок не "понимает" что он закрылся и тыркает сам себя N-ное число раз.

Вопрос: Linux, Postgres, Розница 2.0.5.1 Украина РИБ по магазину - ошибка блокировки...

"Ошибка записи данных в файл сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта()}: Error calling context method (ЗаписатьИзменения): Lock conflict during the transaction:
Maximum idle time for lock access has been exceeded due to the wait for the session"

Все последующие:

"Ошибка записи данных в файл сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта()}: Ошибка при вызове метода контекста (ЗаписатьИзменения): Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки"

Ни переиндексация, ни закрытие сеансов не помогает. Блокировок в 1С не стоит. Помогает только удаление базы и создание снова.
Как я понял блокировка проходит в СУБД? Использую Postgress на Linux, 1 база, 4Гб оперативки. Если я прав, вопрос - Неправильно настроен Postgress или нехватка памяти? Или может вообще проблема не в этом?

Ответ: () Так то свежий - это 8.3.10.2375

Вопрос: Ошибка блокировок при очистке регистра сведений

НаборЗаписей.Загрузить(РезультатЗапроса.Выгрузить()); НаборЗаписей.Очистить(); НаборЗаписей.Записать();
При попытке записать вываливается ошибка:

"Конфликт блокировок при выполнении транзакции".
Регистр не периодический, регистратору не подчинен.

В чем причина ошибки?

Ответ: ()"Я почему-то был уверен, что отбор применяется только в момент чтения, а записывается соответственно то, что попало в отбор." - где у тебя в коде хоть раз используется слово "отбор"?