Как работают блокировки 1с

Обновлено: 08.07.2024

Автоматические транзакционные блокировки 1С и СУБД


В этом режиме все блокировки осуществляет СУБД. Программисты не могут никак повлиять на процесс. При этом разработчикам несколько проще выполнять свои действия, но пользователям не рекомендуется создавать здесь информационную систему (в особенности для СУБД PostgreSQL, Oracle BD, т.к. в процессе модификации сведений они заблокируют всю табличную часть).

Для различных СУБД в автоматическом режиме применяют такие степени изоляции:

1. SERIALIZABLE целиком на таблицу – файловый режим 1С, PostgreSQL, Oracle.

2. SERIALIZABLE на записи – MS SQL, IBM DB2 (работая с не объектными сущностями).

3. REPEATABLE READ на записи – MS SQL, IBM DB2 (с объектными).

Управляемые режимы транзакционных блокировок 1С и СУБД


При таком варианте вся ответственность должна ложиться на производителя программного продукта 1С. Отметим, что СУБД назначает повышенный уровень изоляции для транзакций — READ COMMITED.

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

Но существует ситуация, при которой две блокировки НЕ состыкуются ни при каких обстоятельствах:

1. Их сделали разные пользователи.

2. Несовместимые виды.

3. Установили на один ресурс.

Физическая реализация блокировок в СУБД


Мы говорим о таблице, находящейся в БД под именем «master». А таблица блокировок обозначается словом «syslockinfo».

В таблице есть четыре ячейки:

1. ИД блокирующей сессии SPID.

2. Что конкретно захвачено RES ID.

3. Типы блокировки — S, U или X MODE (их, конечно же, значительно больше, но в 1С применяют лишь эти три).

4. Состояние блокировки — есть два понятия: GRANT (установлена) и WAIT (в очереди).

Чтобы завершить транзакции на уровне SQL как правило применяют команду KILL и указывают идентификатор сессии: KILL SPID/

Какие типы блокировок 1С совместимы?


Единый семинар 1С для бухгалтеров и руководителей


Обучающие видеокурсы по 1С


Интервью со студенткой ОГУ уголовно-правового профиля

Отзывы о компании

ПАО "НИКО-БАНК" выражает свою благодарность за оперативную и грамотную работу.
В условиях постоянно меняющегося законодательства Банк заинтересован иметь полную и актуальную номативную базу. Это обеспечивается использованием Банком справочно-нормативной системы "Гарант".
Безусловным плюсом в работе компании "МастерСофт" является быстрое реагирование сотрудников при предоставлении документов по запросу Банка, принятых до обновления справочно-правовой системы.

Коллектив компании "АЭРОПОРТ ОРЕНБУРГ" выражает благодарность за взаимовыгодное сотрудничество с МастерСофт-ИТ. Оперативная поставка антивирусных программ Dr. Web обеспечила надежную защиту нашей компьтерной сети.
Особая благодарность сотрудникам Департамента продаж СЦ ИТ за профессиональный подход в решении всех возникающих задач.

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

Главный бухгалтер муниципального бюджетного учреждения дополнительного образования "Дворец творчества детей и молодёжи" Кетерер Татьяна Михайловна выражает благодарность специалистам МастерСофт:
"Я хотела бы объявить благодарность вашим сотрудникам. Работает с нами по программе "1С: Бухгалтерия бюджетного учреждения 8" непосредственно Шевлягина Юлия.
Так же огромная благодарность за отзывчивость, терпение и квалифицированную, своевременную помощь Набокиной Олесе и Ерёменко Татьяне (они нас сопровождают по программе "Зарплата и Кадры").
Им очень с нами тяжело, но они терпеливо продолжают сотрудничать. С вами очень надёжно. Конечно же наши ошибки есть и без вас мы бы вообще о них не знали и в суде, наверное, судились бы. А сейчас мы решаем вопросы. ".

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

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

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

Уровни изоляции транзакций

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

Read committed Snapshot (версионирование данных) - разрешено чтение старой версии данных, изменения по которым не завершены другими транзакциями. Штатно поддерживается базами данных: Postgre SQL и Oracle. Начиная с версии платформы 1С 8.3 реализован для работы с базами данных: MSSQL .

Repeatable read (повторяемое чтение) – запрет на изменение записей в транзакции, которые уже были считаны ранее в рамках остальных транзакций.

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

Разделение итогов регистров накопления

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

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

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

Механизмы контроля остатков в типовых конфигурациях 1С

Старая схема, далее OLD – формируется запрос к базе данных для выполнения контроля свободных остатков, в случае положительного решения, формируется движение по регистру. На данный момент применяется в Бухгалтерии 3.0 и в некоторых алгоритмах УТ 11, КА 2, ЕРП 2.

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

Новая схема, далее NEW – выполняется движение по регистру, затем проверяется наличие отрицательных остатков, в случае их наличия, операция откатывается. На данный момент применяется в УТ 11, КА 2, ЕРП 2.

Преимущества:

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

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

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

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

Режим автоматических блокировок

В данном случае используется описанный выше режим изоляции транзакций: Repeatable read .

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

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

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

Примечание: В случае работы с файловой базой и с P postgre SQL , блокировка накладывается целиком на всю таблицу.

Использовать режим контроля остатков - NEW совместно с автоматическим режимом блокировок имеет смысл только для регистров без разделения итогов, в этом случае, никаких дополнительных действий делать не нужно. При использовании регистров с разделением итогов может возникнуть d ea dlock на чтении данных, если запись в регистр производилась одновременно, и каким-то образом решить данную проблему не получится.

Режим управляемых блокировок

В данном случае, применяется режимы изоляции транзакций: Read committed и Read committed Snapshot .

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

Использование режима контроля остатков NEW :

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

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

  • Без режима версионирования (MS SQL и 1С 8.2) – получим взаимоблокировку при попытке чтения данных, если запись в двух транзакциях была выполнена одновременно. При записи данных блокировка не будет возникать, так как используются разные строки СУБД (разделение итогов)
  • С режимом версионирования Snapshot (postgresql,oracleили 1С 8.3) – блокировка возникать не будет, но будут появляться отрицательные остатки, так как контроль будет выполнен без учета всех не завершенных транзакций.

Для исключения подобной ситуации необходимо перед записью в регистр установить флаг набора записей: БЛОКИРОВАТЬ ДЛЯ ИЗМЕНЕНИЯ. Данная конструкция дает команду при записи накладывать исключительную блокировку на записи таблицы остатков регистра без учета разделителя итогов, по своей сути, она просто напросто временно отключает разделение итогов для регистра накопления.

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

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

Если что-то упустил и в чем-то был не точен, буду руд увидеть это в комментариях к статье.

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

Ниже я распишу, как работают блокировки, и каких типов они бывают.

Типы блокировок 1С

Типы блокировок

Блокировки в 1С делятся условно на объектные и транзакционные.

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

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

Объектные блокировки 1С

Данный вид блокировок полностью реализован на уровне платформы 1С и никак не затрагивает СУБД.

Пессимистические блокировки

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

Оптимистические блокировки

Данная блокировка сравнивает версии объекта: если два пользователя открыли форму, и один из них изменил и записал объект, то второму при записи система выдаст ошибку, что версии объектов отличаются.

Транзакционные блокировки 1С

Механизм тразакционных блокировок 1С гораздо интереснее и более функционален, чем механизм объектных блокировок. В этом механизме активно участвуют блокировки на уровне СУБД.

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

  • проблема потерянного изменения;
  • проблема грязного чтения;
  • неповторяемость чтения;
  • чтение фантомов.

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

Автоматические транзакционные блокировки 1С и СУБД

Для разных СУБД в автоматическом режиме используются разные степени изоляции:

  • SERIALIZABLE на всю таблицу – файловый режим 1С, PostgreSQL, Oracle;
  • SERIALIZABLE на записи – MS SQL, IBM DB2 при работе с не объектными сущностями;
  • REPEATABLE READ на записи – MS SQL, IBM DB2 при работе с объектными сущностями.

Управляемые режим транзакционных блокировок 1С и СУБД

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

Две блокировки НЕ совместимы, если: установлены разными пользователями, имеют несовместимые виды (исключительная/разделяемая) и установлены на один и тот же ресурс.

Физическая реализация блокировок в СУБД

Физически блокировки представляют собой таблицу, которая находится в БД под названием master. Сама таблица блокировок носит имя syslockinfo.

Таблица условно имеет четыре поля:

Для завершения транзакции на уровне SQL можно использовать команду KILL с указанием идентификатора сессии:

Таблица совместимости разных типов блокировок

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

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

Типичные причины взаимоблокировок СУБД в 1С 8.3

Установка недостаточного уровня блокировки ресурса

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

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

Решением является установка максимально необходимого уровня изоляции.

Для автоматического режима:

Для управляемого режима блокировок необходима установка исключительной блокировки (X) вместо разделяемой (S).

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

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

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

Ошибка блокировок 1С при работе внутренних механизмов СУБД

Распараллеливание процессов

  • Intra-query parallelism caused your server command to deadlock
  • Transaction was deadlocked on thread communication buffer resources with another process and has been chosen as the deadlock victim

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

Также взаимоблокировки в 1С могут возникнуть по вине СУБД по следующей причине:

Обычно это происходит при следующих условиях:

Для решения данных проблем, соответственно, необходимо:

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

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

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

Как появляется взаимоблокировка в 1С

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

5 причин, вызывающих взаимоблокировки 1С и соответствующие им решения

1. Несоответствующий уровень блокировки ресурса

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

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

2. Захват ресурсов 1С в произвольной последовательности

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

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

1. Ботинки мужские демисезонные

1. Реализовано (блокировка от документа 2, ожидание)

2. Ботинки женские демисезонные

2. Возврат (блокировка от документа 1, ожидание)


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

3. Ошибка блокировок 1С при действии внутренних механизмов СУБД

Проблема 1 (распараллеливание процессов):

Распараллеливание процессов возникает из-за того, что СУБД имеет возможность произвольно распределить выполнение любого действия на разные процессоры системы. Если процессы, происходящие на разных процессорах, блокируют ресурсы, то происходит взаимоблокировка.

Решение:
Избежать этого типа взаимоблокировки поможет заблаговременная проверка возможности предоставления ресурса. Параметр max degree of parallelism в СУБД по умолчанию настроен на цифру «0». Если выставить параметр на «1», то параллельность процессов будет оптимизирована.

Проблема 2 (построение плана запроса с избыточными блокировками):

Когда в систему вводится сложный запрос, СУБД может внести погрешность в план запроса, который заблокирует «лишние» ресурсы, в результате чего возникнет взаимоблокировка. СУБД составляет неоптимальный план запроса если:

  • производится сканирование (table skan, index skan)
  • в наличии опция «ДЛЯ ИЗМЕНЕНИЯ»
  • активирован авторежим всех блокировок.

4. Неоптимальные запросы

Существуют случаи, при которых для возникновения взаимоблокировки достаточно некорректного запроса. Например, если для отбора в виртуальной таблице используется конструкция «ГДЕ». Фактически, при использовании этой конструкции система получает все записи, и только после выбирает нужные.

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

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

5. Условия по неиндексируемым полям

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

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

Это важно: некоторые типы объектов имеют свои нюансы при составлении индексов.

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

Заключение

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

Читайте также: