Конфликт блокировок при выполнении транзакции в 1С 8.3 (8.2)

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

Причины конфликта блокировок

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

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

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

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

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

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

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

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

Получите понятные самоучители по 1С бесплатно:

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

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

Другие статьи по 1С:

К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.

Источник

Конфликт блокировок при выполнении транзакции 1С 8.3: как исправить

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

Конфликт блокировок при выполнении транзакции в 1С: причины и пути их устранения

Причина 1. Одновременная работа пользователей с большим объемом данных

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

Блокировка — это информация о том, что данный объект занят пользователем для выполнения какого-то действия. Смысл блокировки в запрете определенных действий над объектом на ограниченное время. Благодаря этим запретам сохраняется целостность и непротиворечивость информационной базы, предсказуемость работы пользователей.

Механизм объектных блокировок — обеспечивает конкурентный доступ пользователей к данным 1С, как правило, это работа пользователей в формах — создание новых объектов, их редактирование, удаление и др.

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

Получите понятные самоучители 2021 по 1С бесплатно:

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

Причина 2. Зависшие блокировки в 1С

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

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

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

Запустить ее можно из папки common — 1CV8Servers.

Причина 3. Ошибка в конфигурации

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

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

Если Вы еще не являетесь подписчиком системы БухЭксперт8:

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

Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно

Похожие публикации

Карточка публикации

Вы можете задать еще вопросов

Доступ к форме «Задать вопрос» возможен только при оформлении полной подписки на БухЭксперт8

Нажимая кнопку «Задать вопрос», я соглашаюсь с
регламентом БухЭксперт8.ру >>

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

Содержание

Вы можете задать еще вопросов

Доступ к форме «Задать вопрос» возможен только при оформлении полной подписки на БухЭксперт8

Нажимая кнопку «Задать вопрос», я соглашаюсь с
регламентом БухЭксперт8.ру >>

Источник

Конфликт блокировок при выполнении транзакции в 1С 8.3 и 8.2

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

Причины и способы решения проблемы

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

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

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

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

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

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

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

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

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

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

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

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

Получите понятные самоучители по 1С бесплатно:

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

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

Источник

Конфликт блокировок при выполнении транзакции 1С 8.3 как исправить?

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

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

Из-за чего появляется конфликт

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

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

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

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

Конфликт блокировок при проведении транзакции

Распространенные причины конфликта блокировки в 1С

Среди основных причин можно выделить:

Перечисленные причины и основные методы их решения являются самыми распространенными.

Неверно написанная конфигурация

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

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

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

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

Ручное управление блокировками

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

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

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

Отключение пользователей

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

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

Можно ли быстро разрешить конфликт блокирования

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

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

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

Заключение

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

Источник

Анализ и устранение взаимоблокировок

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

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

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

Менеджер взаимоблокировок работает следующим образом:

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

Другой важной особенностью взаимоблокировок является тот факт, что взаимоблокировка почти всегда «распределена» по нескольким различным строкам кода конфигурации. При этом на начальном этапе анализа пользователю известна только одна строка кода. Это может быть, например, последняя строка, выполненная «жертвой» перед тем, как ее транзакция была отменена менеджером взаимоблокировок (эта строка доступна в информации об ошибке) или строка кода конфигурации, которую выдал ЦУП в дереве аналитической информации.

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

Известны следующие типичные причины возникновения взаимоблокировок в системах на платформе «1С:Предприятие 8»:

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

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

Текущая версия ЦУП показывает схемы взаимоблокировок только в том случае, если исследуемая информационная база работает с использованием MS SQL Server 2005.

Повышение уровня блокировки ресурса в рамках одной транзакции

Общие сведения

Повышение уровня блокировки в рамках одной транзакции является наиболее распространенной причиной возникновения взаимоблокировок.

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

Затем транзакция Т1 изменяет ресурс Р1 и пытается его записать. При этом устанавливается эксклюзивная блокировка на этот ресурс. Однако эта блокировка не может быть установлена одновременно с разделяемой блокировкой от транзакции Т2, поэтому она устанавливается в состояние ожидания. Транзакция Т1 прекращает работу и ждет, пока будет снята разделяемая блокировка, установленная транзакцией Т2.

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

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

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

Применительно к данному случаю перед чтением ресурса необходимо было заблокировать его в эксклюзивном режиме. Тогда картина изменилась бы следующим образом:

В данном случае обе транзакции, перед тем как читать ресурс Р1, устанавливают на него эксклюзивную блокировку. Одна из транзакций (Т1) успевает сделать это первой. К моменту времени t1 ресурс Р1 оказывается заблокированным в эксклюзивном режиме и транзакция Т2, которая не может установить свою блокировку, становится в ожидание на блокировке.

Особенности взаимоблокировок данного вида

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

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

Для возникновения взаимоблокировки данного вида необходимо одновременное выполнение следующих условий:

Автоматический режим. Чтение без опции «ДЛЯ ИЗМЕНЕНИЯ» и последующая запись в рамках одной транзакции

Рассмотрим следующий пример.

Обратите внимание на то, что проведение документа выполняется в неявной транзакции, которая автоматически открывается «1С:Предприятием». Таким образом, весь текст обработчика проведения будет выполнен в рамках одной транзакции.

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

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

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

Для того чтобы избежать возникновения взаимоблокировки, необходимо сделать чтение остатков блокирующим. Для этого используется опция «ДЛЯ ИЗМЕНЕНИЯ».

Необходимо изменить функцию «ПроверитьОстатки» следующим образом:

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

Предположим, что в коде конфигурации определена следующая процедура

В транзакции считывается элемент справочника «Контрагенты». Чтение реализовано в объектной технике. При выполнении этой строки кода «1С:Предприятие» выполнит запрос к базе данных, который автоматически установит разделяемую блокировку для данного контрагента.

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

В этом случае процедура будет выглядеть следующим образом:

Управляемый режим. Чтение без установки блокировки (либо с установкой разделяемой блокировки) и последующая запись

Если в примере 1 перевести конфигурацию в управляемый режим блокировки данных в транзакции, то опция «ДЛЯ ИЗМЕНЕНИЯ» будет игнорирована «1С:Предприятием», и необходимой эксклюзивной блокировки перед чтением остатков не произойдет. Кроме того, разделяемая блокировка, которая автоматически установится на уровне СУБД, будет снята после завершения выполнения запроса (то есть до конца транзакции). Такая ситуация может привести к нарушению бизнес-логики системы.

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

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

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

Для данного примера измененный текст функции должен быть следующим:

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

Если в данном случае установить режим блокировки «Разделяемый», то при одновременной работе нескольких пользователей возможно возникновение взаимоблокировки на уровне «1С:Предприятия».

Захват ресурсов в разном порядке

Общие сведения

Захват ресурсов в разном порядке является второй наиболее распространенной причиной возникновения взаимоблокировок.

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

Схема возникновения взаимоблокировки для двух ресурсов такова. В начале две конкурирующие транзакции (Т1 и Т2) захватывают два разных ресурса – Р1 и Р2. Устанавливаемые при этом блокировки не мешают друг другу (так как заблокированы разные ресурсы), поэтому к моменту времени t1 обе транзакции успешно блокируют ресурсы и продолжают работу.

Затем транзакция Т1 пытается заблокировать ресурс Р2. Однако это невозможно, поскольку он уже заблокирован транзакцией Т1. В свою очередь, транзакция Т2 пытается заблокировать ресурс Р2, но это также невозможно, поскольку он уже захвачен транзакцией Т1.

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

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

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

При блокировании ресурсов в одинаковом порядке картина изменится следующим образом:

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

Транзакция Т1 продолжает работу, выполняет все необходимые действия (при этом, в частности, захватывает ресурс Р2) и завершается. После завершения транзакции все установленные ей блокировки автоматически снимаются и транзакция Т2 продолжает работу. Ей также никто не мешает, и она успешно выполняет все необходимые действия, включая установку блокировок на ресурсы.

Особенности взаимоблокировок данного вида

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

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

Как правило, для анализа взаимоблокировок данного вида необходимо использовать информацию, предоставляемую «Центром управления производительностью».

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

Типичные причины возникновения взаимоблокировок данного вида таковы:

Захват ресурсов без учета порядка

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

Однако можно сформулировать несколько несложных правил, выполнение которых позволит значительно снизить риск возникновения взаимоблокировок данного вида:

Предположим, что в конфигурации определены два вида документов: «РеализацияТоваров» и «ПоступлениеТоваров». Документы записывают движения в два регистра накопления: «ТоварыНаСкладах» и «ТоварыОрганизаций». При этом движения заполняются и записываются в явном виде в обработчиках проведения документов.

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

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

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

Обратите внимание на то, что ресурсы захватываются (блокируются) не только при записи движений. Полный перечень операций, при которых происходит захват ресурсов:

Захват ресурсов в разном порядке в соответствии с требованиями алгоритмов обработки данных

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

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

Например, при работе в автоматическом режиме мы можем выполнить запрос с опцией «ДЛЯ ИЗМЕНЕНИЯ» к виртуальной таблице остатков регистра «ТоварыОрганизаций» в обработчике проведения документа «РеализацияТоваров». В качестве условия в этот запрос следует передать набор значений измерений, который будет изменяться в этой транзакции (то есть выборку из табличной части документа). В этом случае последовательность установки блокировок будет такая же, как в документе «ПоступлениеТоваров»: сначала будет блокироваться регистр «ТоварыОрганизаций», а затем «ТоварыНаСкладах». Взаимоблокировка при этом будет исключена.

При работе в управляемом режиме вместо запроса с опцией «ДЛЯ ИЗМЕНЕНИЯ» следует прописать в коде обработчика проведения явную блокировку пространства «РегистрНакопления.ТоварыОрганизаций» по соответствующему набору значений измерений.

Непредсказуемый порядок захвата ресурсов в СУБД при выполнении сложных запросов

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

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

Неоптимальная работа запроса

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

Ошибка блокировок при работе внутренних механизмов MS SQL Server

Известны случаи возникновения взаимоблокировок при работе внутренних механизмов MS SQL Server. О возникновении таких взаимоблокировок говорят следующие сообщения об ошибках:

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

Соответственно, для устранения такой взаимоблокировки необходимо исключить любое из трех условий:

Анализ взаимоблокировок при помощи ЦУП

Как уже было отмечено выше, взаимоблокировки не всегда поддаются анализу на основании одной строки кода – той, в которой было получено сообщение об ошибке взаимоблокировки. Если исследуемая база работает с использованием MS SQL Server 2005, то есть возможность получить детальную информацию по взаимоблокировке с помощью Центра управления производительностью.

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

Для получения информации по взаимоблокировке необходимо выполнить следующую последовательность действий:

1. Настроить права доступа и подключиться к исследуемой информационной базе в режиме мониторинга (см. руководство по использованию ЦУП).

2. Добавить показатель «Анализ взаимоблокировок» в список показателей ЦУП.

3. Включить запись этого показателя.

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

4. Воспроизвести взаимоблокировку в исследуемой информационной базе либо дождаться, пока взаимоблокировка возникнет во время работы пользователей. О возникновении взаимоблокировки можно судить по значениям показателя «Количество взаимоблокировок».

Внимание!
После включения записи аналитического показателя ЦУП начинает сбор информации примерно через 1 минуту. Необходимо выдержать паузу между включением записи показателя и воспроизведением взаимоблокировки.

5. Выключить запись показателя «Анализ взаимоблокировок». После выключения записи ЦУП начнет разбор и анализ собранной информации. Этот процесс может занять длительное время.

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

7. Нажать кнопку «Анализ».

8. В форме анализа проблем производительности выбрать закладку «Код конфигурации», раскрыть первую вершину дерева и двойным щелчком открыть форму анализа взаимоблокировок:

9. Будет открыта форма списка взаимоблокировок, в которых участвует выбранный источник проблем – строка кода конфигурации. Группы взаимоблокировок объединяют одинаковые (по схеме) взаимоблокировки, произошедшие в разное время. Поскольку в системе может наблюдаться множество различных взаимоблокировок, следует проанализировать каждую группу. Из группы следует выбирать наиболее простую взаимоблокировку.

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

10. Провести анализ схемы взаимоблокировки и причин ее возникновения.

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

Далее приведены примеры анализа взаимоблокировок двух основных видов:

Примеры получены на измененной конфигурации УПП при помощи теста «Продажи» и доступны для самостоятельного изучения в демонстрационной базе ЦУП.

Повышение уровня блокировки ресурса в рамках одной транзакции

Рассмотрим пример взаимоблокировки, возникшей в результате повышения уровня блокировки ресурса в рамках одной транзакции:

Во взаимоблокировке участвуют два процесса (транзакции):

Для каждого процесса показана хронология событий, которая привела к возникновению взаимоблокировки.

Вначале оба процесса выполняют запросы, в результате которых успешно устанавливаются две блокировки:

Затем оба процесса пытаются выполнить два других запроса, но при установке блокировок возникает взаимное ожидание, то есть взаимоблокировка:

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

1. Во взаимоблокировке участвует один ресурс – регистр накопления «ТоварыВРезервеНаСкладах»:

2. Процессы являются однотипными, то есть выполняются одинаковые прикладные действия и, соответственно, работает один и тот же код конфигурации:

Откроем конфигурацию исследуемой базы и проанализируем запрос, который исполняется в строке 506 модуля набора записей регистра накопления «ТоварыКПередачеСоСкладов». При этом нас будет интересовать только обращение к заблокированному ресурсу – регистру «ТоварыВРезервеНаСкладах».

Ниже приведен сокращенный текст процедуры КонтрольСвободныхОстатков_Реализация(), из которой вызывается интересующий нас запрос.

При выполнении данного запроса идет чтение остатков регистра ТоварыВРезервеНаСкладах. При этом будет установлена разделяемая блокировка, так как опция «ДЛЯ ИЗМЕНЕНИЯ» применена только к регистру «ТоварыКПередачеСоСкладов».

Затем проанализируем код, который исполняется во второй интересующей нас строке: модуль набора записей регистра накопления «ТоварыВРезервеНаСкладах», строка 395. Нас по-прежнему будут интересовать только обращения к регистру «ТоварыВРезервеНаСкладах».

При выполнении этого запроса также производится чтение остатков регистра «ТоварыВРезервеНаСкладах», но они читаются с опцией «ДЛЯ ИЗМЕНЕНИЯ», то есть при этом будет установлена эксклюзивная блокировка.

Таким образом, регистр «ТоварыВРезервеНаСкладах» блокируется в рамках одной транзакции сначала разделяемой блокировкой, а затем эксклюзивной. Это и является причиной возникновения данной взаимоблокировки.

Для исправления этой ошибки необходимо изначально заблокировать остатки регистра «ТоварыВРезервеНаСкладах» с максимальным необходимым уровнем изоляции, то есть с опцией «ДЛЯ ИЗМЕНЕНИЯ». При этом код процедуры изменится следующим образом:

Захват ресурсов в разном порядке

Рассмотрим пример взаимоблокировки, возникшей в результате захвата ресурсов в разном порядке:

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

1. Во взаимоблокировке участвуют несколько (в данном случае два) ресурсов. При этом они захватываются в разном порядке.

2. Процессы являются разнотипными, то есть выполняются разные прикладные действия и, соответственно, разный код конфигурации.

Рассмотрим действия, которые выполняют эти два процесса, и блокировки, которые при этом устанавливаются.

1. Действия и блокировки процесса 1:

1.1. Процесс 1 выполняет запрос контроля остатков в строке 506 модуля набора записей регистра накопления «ТоварыКПередачеСоСкладов». Рассмотрим фрагменты кода процедуры «КонтрольСвободныхОстатков_Реализация», обращая внимание только на обращения к таблице «ТоварыНаСкладах.Остатки».

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

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

Открыв форму выполнения запроса, мы увидим полный стек вызовов кода конфигурации. Из этого стека становится понятно что интересующий нас запрос выполнялся при проведении документа «РеализацияТоваровУслуг» (в коде тестовой обработки соответствующая переменная имеет имя «Реализация»).

1.2. Следующее действие, выполненное процессом 1, имеет этот же стек вызова, но он заканчивается на строке «Реализация.Записать».

Это означает, что оба действия были выполнены в результате проведения одного документа «РеализацияТоваровУслуг», но первое действие было вызвано в явном виде из кода конфигурации, а второе – выполнено автоматически платформой.

Посмотрим, какой SQL-запрос был сгенерирован платформой при выполнении этого действия.

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

2. Действия и блокировки процесса 2:

Процесс 2 выполняет одно-единственное действие – запись и проведение документа «РасходныйОрдер». Оба действия, имеющие отношение к взаимоблокировке, выполняются платформой автоматически при проведении документа.

2.1. Первое действие: обновление остатков регистра накопления «ТоварыКПередачеОрганизаций»:

В результате этого действия устанавливается эксклюзивная блокировка на соответствующие остатки регистра «ТоварыКПередачеОрганизаций». Именно эта блокировка мешает процессу 1 установить аналогичную блокировку при выполнении действия 1.2.

2.2. Второе действие: обновление остатков регистра накопления «ТоварыНаСкладах»:

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

Итак, процесс 1 ожидает окончания транзакции процесса 2, в то время как процесс 2 ожидает окончания транзакции процесса 1. Получаем взаимоблокировку по причине захвата ресурсов в разном порядке. Процесс 1 захватил сначала регистр накопления «ТоварыНаСкладах», а затем регистр «ТоварыКПередачеОрганизаций». Процесс 2 захватил эти же регистры, но в обратном порядке.

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

Можно было бы попробовать изменить порядок записи движений в документе «РасходныйОрдер», прописав в обработчике проведения этого документа следующий код:

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

Поэтому в данном случае рекомендуется другой способ устранения взаимоблокировки – установка искусственной блокировки. Поскольку процесс 2 (проведение документа «РасходныйОрдер») выполняет захват ресурсов автоматически, будем считать именно этот порядок правильным. Процесс 1 («РеализацияТоваровУслуг») захватывает ресурсы в неправильном порядке – сначала блокируется регистр «ТоварыНаСкладах», затем – «ТоварыКПередачеОрганизаций». Именно этот порядок должен быть изменен.

Для этого следует выполнить запрос с опцией «ДЛЯ ИЗМЕНЕНИЯ» к таблице остатков регистра «ТоварыКПередачеОрганизаций». Этот запрос должен быть выполнен перед запросом в строке 506 модуля набора записей регистра «ТоварыКПередачеСоСкладов». Условия запроса должны быть такими, чтобы считать (и, соответственно, заблокировать) все остатки, которые будут изменены при записи набора записей в действии 1.2.

Существует еще один вариант устранения этой взаимоблокировки. Блокировки, устанавливаемые процессом 1 (документ «РеализаяТоваровУслуг»), возникают только при работе в автоматическом режиме. Характерным признаком таких блокировок является значение поля режим = «Range…»:

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

Источник