Ошибка блокировки документа при проведении

Содержание
1. Ошибка 1С: “Конфликт блокировок при выполнении транзакции”. В чем причина?
2. Ошибки в 1С из-за блокировок
2.1 Пример необходимой блокировки в 1С
2.2 Пример избыточной блокировки в 1С 
2.3 Как избавиться от избыточных блокировок в 1С

Ошибка 1С: “Конфликт блокировок при выполнении транзакции”. В чем причина?

Этот вопрос возник у нас на проекте по внедрению ЗУП2.5 с численностью 20000 и средним количеством одновременных пользовательских сессий 200.

На этапе опытной эксплуатации при расчете зарплаты пользователи начали интенсивно работать с документами «Начисление зарплаты сотрудникам организаций». Объем документов был порядка 2500 строк.  У пользователей начали появляться сообщения «Конфликт блокировок при выполнении транзакции», и расчет приходилось запускать заново.

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

Ошибки в 1С из-за блокировок

Пример необходимой блокировки в 1С

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

 Но если запустить эти документы параллельно, то они одновременно начислят НДФЛ, не подозревая о существовании друг друга, и в результате налог удвоится. Если блокировка настроена верно, то первый документ, запущенный на долю секунды раньше второго, успеет первым прочитать и заблокировать данные о фактически исчисленном налоге в регистре «НДФЛ расчеты с бюджетом» по сотруднику Пушкину А.С. Из этого запроса будет видно, что фактический налог за январь пока не начислялся и значит надо выполнить движение по регистру. Блокировка будет отпущена только после завершения записи в регистр. Второй документ, дойдя до запроса чтения фактически начисленного налога будет поставлен системой на ожидание до тех пор, пока первый документ не закончит транзакцию проведения, после чего он прочитает в запросе, что налог уже начислен и движение по регистру выполнять не надо. Это необходимая блокировка.

Конечно, этот пример притянут за уши для простоты объяснения. На самом деле логика ЗУП 2.5 такова, что для задвоения НДФЛ пользователям не нужно прикладывать особых усилий. НДФЛ рассчитывается до проведения документа, а при проведении содержимое табличной части просто заносится в регистры без всякой проверки. Пользователям между расчетом и проведением предоставляется возможность посмотреть будущий результат и при необходимости поправить руками. Конечно это большой плюс в пользу гибкости ЗУПа, но предъявляет высокие требования к профессиональному уровню расчетчиков. Поэтому вопрос предотвращения задвоения НДФЛ решается организационным путем или с помощью дополнительных проверочных отчетов. Конечно, в ЗУП2.5 есть регистры, которые рассчитываются и записываются одновременно при проведении документа, например «НДФЛ к зачету», но этот пример пришлось бы дольше объяснять ;).

Пример избыточной блокировки в 1С

А теперь представим другую ситуацию. При проведении документа выполняется запрос, который должен отобрать документы, в которых присутствует сотрудник из этого документа. Но запрос написан так, что сервер SQL вынужден находить нужные документы методом перебора. Для технических специалистов это означает, что вместо CLUSTERED INDEX SCAN выполняется TABLE SCAN, т.е. вместо сканирования таблицы индексов происходит сканирование самой таблицы. Причем в процессе перебора блокируются все записи, к которым прикоснулся запрос, даже те, в которых не присутствуют искомые сотрудники. И эта блокировка будет действовать до конца завершения проведения документа, что будет препятствовать параллельному проведению документов с другими сотрудниками. Это избыточная блокировка.

Как избавиться от избыточных блокировок в 1С

Лечение избыточных блокировок может идти двумя путями. Первый — это оптимизация запросов, выполняемых внутри транзакций и добавление необходимых табличных индексов в конфигураторе. Второй — это перевод выполнения SQL-запросов на более низкий уровень изоляции, когда при выполнении запросов записи в таблицах блокируются только на момент выполнения самого запроса, либо не блокируются вовсе. А необходимые блокировки устанавливаются средствами объекта «БлокировкаДанных» и выполняются на стороне сервера 1С.

Теперь немного теории про уровни изоляции на SQL сервере:

1.      В автоматическом режиме в транзакциях используется уровень изоляции SERIALIZABLE. Этот уровень накладывает блокировки типа X (запрещает чтение и запись) до конца транзакции на все данные, которых коснулись запросы или произошла запись данных.

2.      В управляемом режиме в транзакциях используется уровень изоляции ReadCommitted. Этот уровень на записанные данные также устанавливает блокировки типа X до конца транзакции. Но при выполнении запросов на данные накладывает блокировки типа S (запрещает запись и проверяет нет ли в этот момент параллельных записей), при завершении запроса блокировки снимаются не дожидаясь завершения транзакции.

3.      Если база данных переведена в режим  ReadCommitted SNAPSHOT, то в управляемом режиме при чтении данных не накладывается блокировка типа S, есть только блокировка типа X при записи.

Тоже самое чуть более подробно в таблице:

Обычно лечение начинают с понижения уровня изоляции, т.к. это не особо трудозатратно и дает быстрый результат. Достаточно перевести конфигурацию из «Автоматического» режима управления блокировкой данных в «Управляемый», и транзакции начнут выполняться на уровне изоляции типа ReadCommitted, вместо SERIALIZABLE или Repeatable Read.

Чтобы переключить базу данных в режим READ COMMITTED SNAPSHOT (RCSI) необходимо в «SQL Server Management Studio» в свойствах базы данных установить параметр «Is Read Committed Snapshot On» в значение «True»:

 

В некоторых источниках предлагают установить параметр «Allow Snapshot Isolation» в значение «True», но в этом нет необходимости, т.к. это приведет к включению другого режима изоляции SNAPSHOT, который не поддерживается платформой 1С (На момент написания статьи релиз платформы 8.3.9).

Режим управления блокировкой данных задается для неявных транзакций, которые выполняются при записи или при проведении документов, т.е. внутри  предопределенных процедур типа ПриЗаписи() или ОбработкаПроведения(). Но большинство «тяжелых» вычислений в типовой конфигурации ЗУП2.5 происходит при выполнении команды «Рассчитать». При этом в модуле объекта запускается процедура РассчитатьВсе(), внутри которой неоднократно повторяется конструкция НачатьТранзакцию() …ЗафиксироватьТранзакцию(). Это явно указанные транзакции, внутри которых происходит запись и очистка регистров и выполняются запросы. Нам необходимо убедиться, что при переключении конфигурации в управляемый режим в процедуре «РассчитатьВсе()» транзакции также начинают выполняться на уровне ReadCommitted.

Для этого проведем небольшой эксперимент: 

• Запустим SQL Server Profiler.

• Запустим «NEW TRACE».

• Выполним подключение к серверу SQL.

• В окне «Trace Properties» на закладке «General» выберем «Use the template» = «Blank», а на закладке «Events Selections» раскроем группу «Stored Procedures» и выберем «RPC:Complited». По кнопке «Column Filters» укажем имя базы и длительность выполнения запросов более 1.

  
• Кнопку RUN пока нажимать не будем, т.к. нам надо сначала запустить базу данных в режиме отладки и остановить выполнение расчета документа «Начисление зарплаты сотрудникам организаций» перед выполнением самого массивного запроса. Например, это будет команда
«Результат = Запрос.ВыполнитьПакет();» в функции «ПолучитьДанныеНДФЛПоРегистратору» в общем модуле «ПроведениеРасчетов». Здесь происходит выполнение основного запроса для расчета НДФЛ. Поставим на ней точку останова отладчика и запустим расчет в документе.

·         После того как отладчик остановится, нажмем кнопку RUN в Профайлере.

·         Теперь сделаем один шаг в отладчике кнопкой F11. Когда запрос будет выполнен и отладчик перейдет на следующий шаг, остановим чтение Профайлера кнопкой «Pause Selected Trace».

·         Теперь найдем самый длительный запрос по колонке Duration и внимательно изучим текст запроса. Если при обращении к реальной (а не временной) таблице после слова WITH стоит SERIALIZABLE, то мы имеем дело с автоматическим режимом блокировки. Если ничего не стоит – то с управляемым.

  

Если в хинте запроса (Hint – это параметр после слова WITH, позволяющий влиять на план выполнения запроса) не указан уровень изоляции, то выполняется уровень изоляции, установленный по умолчанию для текущей SQL-сессии. Определить уровень изоляции, действующий по умолчанию для текущих сессий можно в «SQL Server Management Studio» с помощью команды

SEL ECT CASE transaction_isolation_level 

WHEN 0 THEN ‘Unspecified’ 

WHEN 1 THEN ‘ReadUncommitted’ 

WHEN 2 THEN ‘ReadCommitted’ 

WHEN 3 THEN ‘Repeatable’ 

WHEN 4 THEN ‘SERIALIZABLE’ 

WHEN 5 THEN ‘SNAPSHOT’ END AS TRANSACTION_ISOLATION_LEVEL 

FR OM sys.dm_exec_sessions

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

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

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

Настройка  управляемых блокировок – это тема для отдельной статьи. Вкратце скажу, что программно управляемые блокировки устанавливаются с помощью объекта «БлокировкаДанных». Сами управляемые блокировки работают уже не на уровне SQL сервера, как в случае с автоматическими блокировками, а на уровне сервера 1С. Для определения необходимых и достаточных управляемых блокировок надо понимать логику программы одновременно на уровне бизнес-процессов и на уровне архитектуры таблиц СУБД.

Но на мой взгляд, для таких конфигураций, как ЗУП2.5 вообще нет смысла использовать какие-либо блокировки, лучше использовать проверочные отчеты для выявления нарушения целостности данных — на практике это самый быстрый способ расчета зарплаты. Особенно на крупных предприятиях, где точно есть сотрудники с внутренним совмещением в обособленных подразделениях, а за каждым ОП закреплен отдельный расчетчик, что и является причиной задвоения НДФЛ. Какой бы не был вышколенный персонал, сама идеология конфигурации допускает возможность задвоения НДФЛ. Поэтому лучше не мешать пользователям работать параллельно во время массированных месячных расчетов, а по завершении точечно и быстро исправить небольшой процент ошибок, чем заставлять их сидеть и нервничать в очереди из-за страха допустить хотя бы одну ошибку. В этом проекте мы использовали самописный отчет «Проверка НДФЛ», который отображал сотрудников с некорректным НДФЛ.

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

Валерий Федоров

Руководитель проектов ООО “Кодерлайн”

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

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

От чего возник конфликт блокировок проведения транзакции

Как было уже сказано: 1С — это сложная система. И она усложняется тем больше, чем больше количество её пользователей в компании. Чем больше сотрудников обращаются к общему серверу 1С для выполнения своей работы, тем больше операций нужно выполнять системе одновременно, и тем выше вероятность появления ошибок.

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

Вам может быть это интересно: Преобразование значения к типу Число не может быть выполнено 1С 8.3 — как исправить?

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

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

О конфликте блокировок при выполнении транзакции вы также можете узнать в видео ниже:

Перевод управления блокировками в ручной режим

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

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

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

Чтобы исключить риск неправильных вычислений, лучше всего проверить после этого всё вручную.

Отключение других пользователей от 1С

1. Как мы поняли выше, «Конфликт блокировок при выполнении транзакции» вызываются тем, что несколько пользователей работают с одним документом.
2. Таким образом, если этих пользователей отключить, то можно будет снять очередь на проведение документов и и провести свой документ, который ранее был заблокирован.
3. Этот метод подойдёт в том случае, если у вас в системе 1С есть права на просмотр пользователей, работающих с тем же документом, что и вы, и возможность завершения их сеансов.
4. Завершив их сеанс, вы можете провести свои вычисления без блокировок.

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

И также рекомендуется всё проверить после завершения проводки.

Как сделать, чтобы ошибка конфликта блокировок при выполнении транзакции больше не появлялась в 1С 8.3

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

.

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

Проблема может заключаться в следующем:

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

Могут быть и другие причины.

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

Я

   kupreeff

15.05.15 — 09:44

Имеется обработка, в которой создаются документы.

В момент работы обработки, в базе работают пользователи. Они работают с данным видом документа, но пересечений по объектам нет (т.е. пользователь не открывает те документы, которые участвуют в обработке).

Обработка спотыкается при записи документа и выдает сообщение: Конфликт блокировок при выполнении транзакции. Можно ли это как-то обойти, чтобы обработка при записи документа ожидала, пока освободится блокируемая таблица?

   ИС-2

1 — 15.05.15 — 09:52

если sql, то можно увеличить время ожидания блокировки на сервере (к админам). Но где-то в самой 1c видел такую настройку

   kupreeff

2 — 15.05.15 — 10:19

(1) не sql

   Cyberhawk

3 — 15.05.15 — 10:20

(0) «обойти, чтобы обработка при записи документа ожидала» она и ожидает, 20 секунд по умолчанию

   Cyberhawk

4 — 15.05.15 — 10:21

Метод объекта Заблокировать() в попытке даст тебе пищу для размышлений

   H A D G E H O G s

5 — 15.05.15 — 10:22

(2) Никак. На файловой блокируется вся таблица документа — только проводить в цикле, в попытке «попасть» в промежуток, когда никто другой не проводит.

   H A D G E H O G s

6 — 15.05.15 — 10:22

(4) Не даст.

   H A D G E H O G s

7 — 15.05.15 — 10:23

(1) Администрирование->Параметры ИБ в конфигураторе

   kupreeff

8 — 15.05.15 — 10:24

(4)Заблокировать() блокирует целиком таблицу?

   ИС-2

9 — 15.05.15 — 10:25

(2) можно в наглую заблокировать всю таблицу, но тогда у пользователей будут блокировки

   H A D G E H O G s

10 — 15.05.15 — 10:26

(8) нет.

(9) Это, если ему дадут это сделать.

   kupreeff

11 — 15.05.15 — 10:29

(9) можно и в наглую. а как? прости за наглость

   Serg_1960

12 — 15.05.15 — 10:29

(0) Если записать но не проводить — то Объект.ОбменДанными.Запись() — даже коврик из под ног юзвера выдергивает

   H A D G E H O G s

13 — 15.05.15 — 10:30

(12) То есть?

   kupreeff

14 — 15.05.15 — 10:31

(7) есть такое дело! что там лупануть, чтобы ни себя не людей не обидеть? Сейчас там 20 сек. Неужто этого мало? А может дело в том, что документы эти открыты в момент записи моего документа?

   Serg_1960

15 — 15.05.15 — 10:31

Тьфу, не Запись — Загрузка = Истина. Оговорился. Тяпница

   H A D G E H O G s

16 — 15.05.15 — 10:32

(15) И какой эффект это производит?

   kupreeff

17 — 15.05.15 — 10:32

(12) я не провожу, я их записываю. А не поленишься еще раз другими словами написать? Спасибо.(В 8-ке туп я, как вы поняли)

   H A D G E H O G s

18 — 15.05.15 — 10:33

(14) Нет. Тебе мешают только проводящиеся документы. Вообще, там у вас у всех должны быть конфликты блокировок.

   kupreeff

19 — 15.05.15 — 10:36

(18) сказть им, чтоб пока я тут мудохаюсь, не проводили этот документ?

   H A D G E H O G s

20 — 15.05.15 — 10:36

   H A D G E H O G s

21 — 15.05.15 — 10:37

Сколько пользователей в базе?

   kupreeff

22 — 15.05.15 — 10:38

(21) да это обработка на один раз, переношу из другой программы данные.

   Serg_1960

23 — 15.05.15 — 10:42

   H A D G E H O G s

24 — 15.05.15 — 10:43

(23) Ясно.

   Альбатрос

25 — 15.05.15 — 10:44

(23) куясе…

   Serg_1960

26 — 15.05.15 — 10:45

(24) Это в ответ на «А может дело в том, что документы эти открыты в момент записи моего документа?»(14)

   ИС-2

27 — 15.05.15 — 10:59

(11) хороший вопрос. Например, выбрать в запросе 1 документ с блокировкой таблиц (см. закладку Дополнительно, галка Блокировать таблицы для изменения). Не — как тогда самому писать.

Задаю вопрос.

Как можно заблокировать таблицу документов для всех пользователей, кроме себя?

   H A D G E H O G s

28 — 15.05.15 — 11:09

   Serg_1960

29 — 15.05.15 — 11:33

«Блокировка = Новый БлокировкаДанных;» спачет отца русской демократии?

Имхо, в файловой версии блокировки на уровне таблиц и любое блокирование любой записи = блокирование всей таблицы записей.

(29) нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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