Конфликт блокировок при выполнении транзакции. |
Я |
12.10.21 — 06:46
Делаю фоновое проведение документа. Когда начинаю его проводить выходит ошибка:
Проведение документа Расчет себестоимости выпуска. ДлительныеОперации.ВыполнитьСКонтекстомКлиента
Задание завершено с ошибками {ОбщийМодуль.ПроцедурыРасчетаСебестоимостиРасширеннаяАналитика.Модуль(921)}: Ошибка при вызове метода контекста (Записать)
СтруктураНаборыЗаписей.УчетЗатрат.Записать(Ложь);
по причине:
Конфликт блокировок при выполнении транзакции:
Microsoft SQL Server Native Client 11.0: Lock request time out period exceeded.
HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=38, Severity=10, native=1222, line=1
Подскажите куда смотреть? Как убрать блокировку?
1 — 12.10.21 — 06:50
Запускай в профилировщике скуля трассировку с событием deadlock, он тебе покажет, запись каких данных сталкивается лбами
2 — 12.10.21 — 06:58
(1) А если до скуля доступа нет, то по другому никак?
3 — 12.10.21 — 07:07
(2) Можно техжурнал настроить, а потом его просмотреть.
ТутЪ есть видео, в картинках показывают
https://www.youtube.com/results?search_query=1с+анализ+блокировок
Но если нет доступа и к ТЖ, то остаётся только ставить свечи и поливать сервер святой водой (литр на гигагерц)
4 — 12.10.21 — 07:17
(3) думаешь литра будет достаточно?
5 — 12.10.21 — 07:20
(4) Святой воды — да. А того, о чём ты подумал — нет.
6 — 12.10.21 — 07:22
(5) я о святой воде и думал)))) Каждый думает в меру своей распущенности )))
7 — 12.10.21 — 07:26
(0) батенька, да Вы извращенец. Это расчет себестоимости. Он накладывает блокирвку на основные регистры и ни кто работать не может.
Или у Вас ошибка вылетает когда только 1 человек в базе ?
8 — 12.10.21 — 07:32
(7) Да, ошибка вылазит когда 1 человек в базе.
9 — 12.10.21 — 08:55
(0) И еще один момент. Если в коде отключить форму прогресса выполнения (ДлительныеОперацииКлиент.ОжидатьЗавершение(Результат, , ПараметрыОжидания);) то тогда документ проводится в фоне без проблем.
10 — 12.10.21 — 09:14
(8) Проверяйте работающие фоновые задания.
11 — 12.10.21 — 09:37
(1) deadlock? с какого х..?
12 — 12.10.21 — 09:38
наверняка несколько фоновых запускается
13 — 12.10.21 — 10:05
(11) с телефона читал топик. Событие профилировщика будет timeout
14 — 12.10.21 — 10:09
поищи в ошибках ерп. наверняка уже зарегистрирована
15 — 12.10.21 — 10:13
(1) Я тебе без профайлера скажу, что это регистр УчетЗатрат.
16 — 12.10.21 — 10:15
Фига себе. А какой же там таймаут?
17 — 12.10.21 — 10:18
(12) Фоновое одно. Это уже проверил
18 — 12.10.21 — 10:24
(15) спасибо, кэп, только нужно выяснить кого он там ожидал
19 — 12.10.21 — 10:26
Сейчас, кстати, начала падать в другом месте:
{ОбщийМодуль.КорректировкаСтоимостиУчетЗатрат.Модуль(108)}: Ошибка при получении значения атрибута контекста (ОтражатьВУправленческомУчете)
Если РегламентныйДокумент.ОтражатьВУправленческомУчете Тогда
по причине:
Конфликт блокировок при выполнении транзакции:
Microsoft SQL Server Native Client 11.0: Lock request time out period exceeded.
HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=33, Severity=10, native=1222, line=1
20 — 12.10.21 — 10:27
Я дал ссылки на видео, где разбирается, как искать взаимоблокировки. Там одно, на полчаса. За это время уже можно было бы посмотреть.
21 — 12.10.21 — 10:28
(20) это НЕ взаимоблокирвоки
22 — 12.10.21 — 10:29
(21) ТЫ УВЕрен?
23 — 12.10.21 — 10:30
(22) ты путешь lock timeout и deadlock
24 — 12.10.21 — 10:31
25 — 12.10.21 — 10:33
(23) Я не путаю. Но начать с видео, чтобы иметь хотя бы представление — имеет смысл.
26 — 12.10.21 — 10:34
Тем более падает основной процесс на превышении. А почему превышение? Потому что кто-то другой держит и не отдаёт.
27 — 12.10.21 — 10:34
(18) другую транзакцию с этим же самым регистром. Откуда вы беретесь?
Профайлер ничем не поможет, нужно собирать ТЖ с контекстом выполнения, чтобы был стек вызовов, тогда только можно будет понять.
28 — 12.10.21 — 10:36
(27) «нужно собирать ТЖ »
Слышал про поговорку про кол и тесать? Так тут именно такая ситуация.
29 — 12.10.21 — 10:38
(27) вообще-то я это и имел ввиду
30 — 12.10.21 — 10:40
Даже не знаю, как в современной конфиге, ситуация докатилась до СУБД таймаута, может плохой план запроса при чтении и скан всей таблицы.
31 — 12.10.21 — 10:41
На длинных блокировках частенько можно и без всяких ТЖ, профайлеров и стеков вызовов догадаться о сути проблемы тупо в мониторинге сиквельных процессов. Глянув какой процесс какой ожидает и что в обоих происходит. Но не всегда, конечно.
32 — 12.10.21 — 11:13
(24) парсит 1сом ТЖ такая себе идея. На этом прогорел 1сный ЦУП. Там, где bash-утилиты отрабатывают за минуты, доблестный ЦУП может пыхтеть часами, а то и днями
33 — 12.10.21 — 11:44
(32) Писать ерунду, не вникая в подробности — не меньшее зло. Вы крайне близки к попаданию в список.
34 — 12.10.21 — 11:47
(30) эскалация же
35 — 12.10.21 — 11:48
(34) Да, это очень может быть.
Вот тут автору поможет профайлер с фильтром на эскалацию, а потом, если подтвердиться, ключ
-t1211
36 — 12.10.21 — 12:30
(0)А не фоновое проведение нормально отрабатывает?
37 — 12.10.21 — 12:34
(33) сам же ерунду и пишешь
38 — 12.10.21 — 12:58
##молча добавляет Конструктора в список к Г1С и Ливингстарам.
39 — 12.10.21 — 13:00
Сначала в себе разберись. То ему в скульной блокировке профилировщик не помощник, потом вдруг помощник
40 — 12.10.21 — 13:02
(39) искать другую сторону не помощник. искать эскалацию — помощник
41 — 12.10.21 — 13:11
(40) проливать информацию, почему возникла блокировка — помощник
42 — 12.10.21 — 13:12
(41) этой инфы будет явно не достаточно и поэтому и смысла этого делать нет
43 — 12.10.21 — 13:16
(42) а я что, где-то писал «только профилировщик и ничего более»? Так-то логично первым делом узнать подробности у скуля, что же ему не понравилось. И только потом нырять в ТЖ. Я тебе даже больше скажу, скуль тебе подскажет SPID и номер транзакции, по которым ты потом быстренько найдёшь инфу в ТЖ
44 — 12.10.21 — 13:19
(43) SQL profiler без отборов тебе выдаст портянку в подмиллион строк в продуктивной системе, при этом, тормознет ее нехило и с ненулевым шансом, подвесит. Ты репу почешешь и скажешь — не смогла.
А ИР в (24) разбирает гиговые ТЖ за несколько минут, через внешние компоненты, но ты, скорее всего, даже его не щупал.
45 — 12.10.21 — 13:20
Поэтому, в список, в список.
Вы особенно и опасны, что извлекаете из себя околоправильные вещи, с умным видом, которые оказываются вредными.
46 — 12.10.21 — 13:24
(44) да-да-да, как бы не миллиард. Внезапно, есть событие lock:timeout, которое выводит _только_ таймауты. Профэссор, блин
На кой нужен этот ИР, когда с ТЖ прекрасно работается bash-утилитами?
47 — 12.10.21 — 13:26
(46) так нужен то не таймаут. таймаут — вот он в (0). нужен тот кто установил. а их миллионы может быть
48 — 12.10.21 — 13:26
(46) вопрос из серии: зачем гуй, когда можно все командами
49 — 12.10.21 — 13:27
(48) вопрос простой — зачем набирать две строки непонятных символов (видео из ссылки выше), ошибаясь в каждой, если можно у гуе галками расставить?
50 — 12.10.21 — 13:27
(47) у него что там, гугловские запросы к регистру идут?
51 — 13.10.21 — 04:48
(36) Не фоновое проводится без проблем. И без ожидания завершения (как я писал выше (9)), тоже проводится.
pechkin
52 — 13.10.21 — 09:08
Отключи эскалацию и попробуй еще раз
В многопользовательских системах важную роль играет правильная организация структуры и настройка блокировок. Если ее нет, пользователям придется часто сталкиваться с ошибками, вызванными конкуренцией за определенные ресурсы системы. Но существует проблема конфликта блокировок, знакомая многим пользователям. Почему возникает конфликт блокировок 1С и как его устранить?
Конфликт блокировок в 1С 8.3 и его значение
Для большинства пользователей сообщение о конфликте блокировок 1С означает лишь ошибку, мешающую им выполнять свою работу. Они хотят поскорее избавиться от этой проблемы и осаждают IT-отдел жалобами на то, что «1С не работает».
Но для системных администраторов и разработчиков такое сообщение говорит о возможном наличии проблем в структуре конфигурации. Перед тем как пытаться угодить пользователям и убрать блокировки, необходимо проанализировать ситуацию и понять причину возникновения сообщения об ошибке.
Причины возникновения ошибок блокировки в 1С
Показательные нагрузочные тестирования демонстрируют, что сервер 1С выдерживает параллельную работу более чем пяти тысяч пользователей. Но идеальные условия подобных экспериментов недостижимы в повседневных условиях крупных и средних компаний. Чтобы добиться аналогичного быстродействия и безошибочности, конфигурация должна быть идеально разработана и заточена под конкретные бизнес-процессы предприятия.
Если не брать идеальные варианты, то конфликты блокировок 1С встречаются по следующим причинам:
Одновременная работа пользователей с большим объемом данных. Эта первопричина продиктована внутренними механизмами 1С. Они предполагают запрет изменения данных, вовлеченных в транзакцию, запущенную от имени другого пользователя;
Ошибки и недочеты в конфигурации. В структуре типовых решений от компании «1С» учтены рекомендации по максимизации производительности. Но сторонние разработчики не всегда придерживаются высоких стандартов, и в их коде часто можно встретить следующие недочеты:
- Неоптимальные запросы;
- Запрос остатков в начале действий;
- Непонимание предназначения объектов конфигурации и их неправильное применение;
- Избыточность заложенных в системе или дополнительно разработанных блокировок.
Как исправить конфликт блокировок в 1С 8.3
Системное сообщение «конфликт блокировки при выполнении транзакции 1С 8.3» не характеризует конфигурацию в качестве неверно спроектированной. Но если подобные сигналы игнорировать, то существует вероятность в самый ответственный момент, например, при сдаче квартальной или годовой отчетности получить большие проблемы. В лучшем случае – тормозящую систему и недовольных пользователей. В худшем – неправильные данные на выходе, что может повлечь за собой штрафные санкции от контролирующих органов.
Решением проблемы конфликта блокировок в 1С 8.3 может стать перевод конфигурации на управляемый (ручной) режим управления блокировками. Реализованный в версии 8.1, механизм в руках грамотных специалистов решает проблему конфликта блокировок при транзакции в 1С.
Но стоит иметь в виду, что это действие снизит уровень защиты данных от изменения в процессе чтения их другими пользователями. Поэтому, если вы не готовы самостоятельно контролировать все блокировки в системе, не торопитесь изменять настройки конфигурации.
Быстрое решение конфликта блокировок 1С
В работе администратора или разработчика может произойти ситуация, когда нет времени на проверку ошибки и поиск первопричин проблемы. Например, необходимо сдать отчет или подать данные к определенному времени, а ошибки блокировок 1С препятствуют этому.
Для быстрого решения проблемы существуют два пути:
- Найти и завершить сеанс, заблокировавший необходимые данные. В небольших компаниях, где количество пользователей 1С не превышает пары десятков человек, это оптимальный вариант решения;
- Если вы контролируете систему, в которой работают сотни сотрудников, поиск нужного сеанса без специализированного программного обеспечения может затянуться надолго. В этом случае намного эффективнее будет перезагрузить сервер.
Эти решения радикальные и направлены только на быстрое решение проблемы и освобождение данных для срочной сдачи отчетов. Искоренить ее можно только разобравшись в причине, из-за которой возник конфликт блокировок при выполнении транзакции 1С. После таких действий необходимо найти уязвимые места в системе, оптимизировать конфигурацию или работу сотрудников. Использовать подобные меры на постоянной основе при регулярных конфликтах блокировок на транзакциях не рекомендуется.
Содержание
1. Ошибка 1С: “Конфликт блокировок при выполнении транзакции”. В чем причина?
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С 8.3 и 8.2
Не редко при работе в 1С возникает ошибка «Конфликт блокировок при выполнении транзакций: Превышено максимальное время ожидания предоставления блокировки». Суть ее кроется в том, что несколько сеансов пытаются одновременно выполнить похожие действия, затрагивая один и тот же ресурс. Сегодня мы разберемся как исправить данную ошибку
Причины и способы решения проблемы
Большое количество выполняемых операций
Первым делом при поиске причин следует уточнить, сколько же одновременно работающих пользователей находится в той информационной базе, в которой выдается подобная ошибка. Как мы знаем, максимальное их количество может быть довольно большим. Это и тысяча, и пять тысяч.
Механизм блокировок и транзакций описан в руководстве разработчика. Их используют при обращении нескольких сеансов к одним и тем же данным одновременно. Логично, что одни и те же данные не могут изменяться разными пользователями в один и тот же момент.
Так же следует проверить, не запущено ли у кого-то из пользователей обработки по массовому изменению данных. Это может быть как групповое проведение документов, закрытие месяца и тому подобное. В таком случае после окончания работы обработки ошибка пропадет сама по себе.
Регламентные задания
Не редки случаи, когда причина ошибки кроется в регламентном задании, которое обрабатывает большое количеств данных. Рекомендуется подобные вещи делать ночью. Задайте расписание выполнение таких регламентных заданий во внерабочее время.
Таким образом, и пользователи будут работать в стабильной системе, и сами регламентные задания будут завершаться успешно, так как снизится вероятность возникновения конфликтов с пользовательскими сеансами.
«Зависшие сеансы»
Проблема «зависших сеансов» пользователей знакома практически каждому, кто сталкивался с обслуживанием 1С. Пользователь мог уже давно выйти из программы, или закрыть какой-либо документ, но его сеанс по-прежнему остается в системе. Проблема чаще всего единичная и достаточно завершить подобный сеанс через консоль администратора. Такие же проблемы могут возникнуть и с фоновыми заданиями.
По многочисленным комментариям на просторах интернета подобные ситуации чаще встречаются при использовании сетевых ключей защиты. Если ситуация с «зависающими сеансами» повторяется систематически, это причина произвести тщательную проверку и обслуживание системы и серверов (если база клиент-серверная).
Ошибки при написании конфигурации
Все типовые конфигурации разработаны квалифицированными специалистами и экспертами. Каждая система тщательно тестируется и оптимизируется для более быстрой и корректной работы в ней.
Получите понятные самоучители по 1С бесплатно:
В связи с этим причина ошибки может крыться в неоптимальном коде, написанном сторонним разработчиком. Это может быть «тяжелый» запрос, который будет блокировать данные на длительный промежуток времени. Так же нередки случаи построения алгоритмов с низкой производительностью и нарушением логики.
Большая вероятность, что конфликт блокировки возник именно из-за ошибок разработчика, если он возник после обновления программы. Для проверки можно просто «откатить» доработки, либо произвести рефакторинг кода.
Конфликт блокировок при выполнении транзакции 1С 8.3 как исправить?
1С – крайне сложная система, имеющая в распоряжении большое количество самых разных настроек, нюансов и особенностей функционирования. И многие знают, что сложность системы прямо пропорциональна количеству всевозможных ошибок и проблем, которые должны решать программисты, техники, кассиры, бухгалтеры и иные должностные лица, чья работа связана с 1С.
Хорошо, если в организации, использующей систему 1С, есть собственный IT-отдел, ведь в таком случае программисту достаточно лишь перейти в нужный кабинет или этаж, чтобы исправить ситуацию. А если его нет, то как решить проблему с, к примеру, конфликтом блокировок при совершении транзакции?
Из-за чего появляется конфликт
Помимо того, что сложность системы прямо пропорциональна количеству ошибок, количество и сложность ошибок напрямую зависит от того, сколько именно пользователей работает в системе. Чем чаще и больше работников юридического лица обращается к одному на всех серверу 1С по работе, тем больше система должна выполнить операций, что и влияет на частоту и сложность ошибок.
Если дело касается серверной 1С версии в большой организации, в ней могут одновременно работать несколько десятков или сотен человек, причем иногда могут быть ситуации, при которых двое или большее количество работников обращаются к одному и тому же документу. К примеру, один сотрудник начисляет работникам зарплату, второй высчитывает налоги, третий занимается расчетом больничного. Для правильности подобных вычислений система 1С позволяет работать с документами (или одним документом) в разное время даже при одновременном выполнении операций.
Если говорить проще, то в рамках рассматриваемой ситуации первый работник начисляет зарплату и после этого проводит документ. Пока система 1С не определит это, документ, с которым работает следующий сотрудник (это тот, который занимается высчитыванием налогов), не будет проводиться внутри системы и будет стоять в очереди (сама система при этом временного его заблокирует). И третий работник, который выплачивает больничные, также будет находиться в очереди.
В том случае, если таких очередей и связанных с ними блокировок очень много, время блокировки каждого последующего документа будет увеличиваться до совсем астрономических показателей. И как раз в таком случае система 1С будет выдавать ошибку конфликта блокировок при совершении транзакции. Однако появление такого конфликта в системе может быть связано и с другими причинами.
Конфликт блокировок при проведении транзакции
Распространенные причины конфликта блокировки в 1С
Среди основных причин можно выделить:
- Слишком большое количество одновременного выполняемых операций. Помимо основной причины, описанной выше, проблема может касаться и запущенного у кого-то из работников процесса обработки данных по массовому изменению. Может быть, кто-то запустил групповое проведение документов, закрытие месяца и иные процедуры. Если причина кроется в этом, то проблема разрешится сама по себе – сразу после того, как групповое проведение данных закончится.
- Регламентные задания. Также частой причиной появления конфликта является появление регламентное задание, в рамках которого обрабатывается очень много самых разных информационных данных. Для того, чтобы подобных проблем в течение рабочего дня не было, стоит выполнять регламентные задания ночью.
- Зависший сеанс. Не менее распространенная проблема «зависших сеансов» пользователей известна практически любой компании, работающей в 1С. Суть ее кроется в том, что пользователь мог уже давным-давно выйти из программы или же завершить работу с каким-либо документом, но сама система все равно не отключает его и думает, что он все еще находится внутри системы. Подобная проблема носит единичный характер и может быть разрешена с помощью администраторской консоли. Также та же проблема может появится при выполнении фоновых заданий. Еще, согласно комментариям, ситуации с зависшим сеансом встречаются при применении сетевых защитных ключей. Если «зависание» повторяется время от времени, необходимо проверить обслуживание серверов и системы.
Перечисленные причины и основные методы их решения являются самыми распространенными.
Неверно написанная конфигурация
Различные типовые конфигурации создаются экспертами и специалистами с соответствующей классификацией. При этом каждая созданная система тестируется и оптимизируется для достижения максимально быстрой и корректной работы.
Но нельзя отменять и человеческий фактор, поэтому иногда проблема может заключаться в неправильном, неоптимизированном или просто забагованном коде, в особенности если его написал неопытный или сторонний разработчик.
Ошибка может крыться в тяжелом запросе, который при активации будет «тормозить» или вовсе блокировать данные на некоторое время. Также частым являются случаи формирования алгоритмов с недостаточной производительностью или с нарушением компьютерной логики.
Один из факторов того, что проблема кроется именно в неправильном коде – это то, что программа перестала работать как надо не спонтанно, а после одного из обновлений. В качестве средства проверки в таком случае можно откатить версию или заняться рефакторингом кода.
Ручное управление блокировками
При желании пользователь (лучше, чтобы это был администратор) может отключить в системе 1С функцию включения блокировок рабочих документов даже в том случае, если этими документами пользуется одновременно 2 или большее количество сотрудников. В таком случае проблем, связанных с конфликтом блокировок, не будет.
Однако не стоит торопиться и сразу отключать функцию блокирования, ведь существует и активна данная функция не просто так. Она существует и активна по умолчанию для того, чтобы программа успевала выполнять вычисления любых документов и гарантировала корректный результат этих вычислений. Поэтому функцию блокирования стоит отключать лишь в том случае, если сотрудники, работающие с финансовой документацией, подойдут к работе ответственно и будут осознавать возможные риски появления неправильных вычислений.
Методика ручного отключения блокировки подойдет в том случае, если обработать документ и решить проблему необходимо максимально оперативно, а вероятность того, что что-то пойдет не так, или вычисления будут неверными, снижена до минимальной. В таком случае можно, к примеру попросить всех работников, использующих 1С, временно перестать им пользоваться. А еще можно отключить их на время.
Отключение пользователей
Как и было отмечено выше, конфликт блокировки при совершении транзакции может быть вызван тем, что один и тот же документ обрабатывается несколькими пользователями. А это значит, что если отключить всех пользователей от системы или документа на некоторое время, один из пользователей сможет быстро провести документ. Правда, это может сделать только тот пользователь, у которого в 1С есть право на просмотр всех тех пользователей, которые на данный момент работают с определенным документом, а также право на завершение сеансов таких пользователей.
Однако и здесь есть риск (пускай и небольшой) того, что проблема снова появится. Появиться она может в том случае, если хотя бы один пользователь на момент его временного отключения от документа выполнял какие-либо важные операции и вычисления в финансовом документе.
Можно ли быстро разрешить конфликт блокирования
Если посмотреть на анализируемую проблему со стороны разработчика или сисадмины, стоит отметить, что всегда и на любом предприятии может произойти ситуация, при которой практически нет времени на проверку появляющейся ошибки и на поиски проблем. К примеру, если нужно «здесь и сейчас» сдать какой-нибудь отчет в бухгалтерию или подать какие-либо данные к определенному часу. В таком случае можно воспользоваться быстрым решением.
Для того, чтобы быстро разрешить конфликт, связанный с блокированием 1С, можно пойти по одному из двух путей:
- Отыскать и принудительно завершить все те сеансы (или один сеанс), из-за которого необходимые документы и данные блокируются. В маленьких организациях, где суммарное количество сотрудников, работающих с 1С, не превышает 1-2 десятков граждан, завершение сеанса является оптимальным вариантом.
- Если есть доступ к системе и ее контролю, а в самой компании работает несколько сотен человек, решение проблемы может затянуться на несколько часов или, в худшем случае, на несколько дней. В такой ситуации оптимальным вариантом будет перезагрузка аппаратного обеспечения и серверного оборудования.
Однако оба решения являются радикальными и могут помочь только при быстром решении проблему (если это необходимо), ведь при их использовании часть данных документа, из-за которого произошел конфликт, может быть утеряна. Поэтому на постоянной основе такие меры лучше не использовать. Лучше вместо этого попробовать найти первопричину появления конфликта и устранить ее.
Заключение
Конфликт блокировок – достаточно распространенная проблема при выполнении работы с 1С, в особенности если речь идет о большой компании. Существует множество способов решения проблемы – как эффективных, так и экстренных. Оптимальный и правильный вариант действий при любой проблеме с 1С – обратиться к специалисту.
Конфликт блокировок при выполнении транзакции 1С 8.3 как исправить?
1С представляет собой сложную систему, в которой есть огромное количество настроек, особенностей и нюансов. А чем сложнее система, тем выше вероятность возникновения ошибок и проблем, решать которые приходится бухгалтерам, кассирам и другим сотрудникам, которые работают на 1С. Либо можно дождаться программиста 1С. Хорошо, если в компании есть свой IT-отдел, когда программисту достаточно только перейти на другой этаж, чтобы решить вашу проблему. Но если этого нет, то приходится ждать решения проблемы долгое время, ожидая специалиста со стороны.
В этой статье мы рассмотрим появление ошибки «Конфликт блокировок при выполнении транзакции» в 1С 8.3. Вы узнаете, как можно попытаться исправить её самостоятельно и быстро, без ожидания стороннего специалиста.
От чего возник конфликт блокировок проведения транзакции
Как было уже сказано: 1С — это сложная система. И она усложняется тем больше, чем больше количество её пользователей в компании. Чем больше сотрудников обращаются к общему серверу 1С для выполнения своей работы, тем больше операций нужно выполнять системе одновременно, и тем выше вероятность появления ошибок.
Когда речь идёт о серверной версии в большой компании, одновременно работать с документами может десятки и даже сотни сотрудников. Среди этих людей могут быть и те, кто работает с документом, например, касающимся одного сотрудника. Допустим, один начисляет ему зарплату, второй налоги, третий высчитывает больничный. Для того, чтобы гарантировать правильность таких вычислений, система 1С будет работать с документами по отдельности, в разное время, даже если сотрудники выполняют операции одновременно.
Таким образом, один сотрудник начислит зарплату и проведёт документ. Пока система не вычислит это, документ второго сотрудника, который насчитывает налог, не будет проведён и окажется в очереди, то есть временно заблокированным. Когда третий сотрудник насчитает выплаты по больничным, он также встанет в очередь на проведение, после документа по начислениям зарплаты и налогов, то есть тоже будет временно заблокирован.
Так вот, когда этих блокировок становится слишком много, когда время блокировки увеличивается до неадекватного, 1С выдаёт ошибку конфликта блокировок при проведении транзакции. Зная природу этой проблемы, можно попытаться решить её.
О конфликте блокировок при выполнении транзакции вы также можете узнать в видео ниже:
Перевод управления блокировками в ручной режим
Ручной (или управляемый) режим отключит у системы необходимость включения блокировок документов, если им пользуется два или более сотрудников одновременно. Таким образом, сообщение о конфликте блокировок при выполнении транзакции исчезнет и всё заработает.
Но ведь блокировки устанавливаются не просто так. Как мы описали выше, они необходимы для того, чтобы гарантировать верное вычисление всех документов. Поэтому, с переводом управления блокировками в ручной режим вы не только избавитесь от конфликта блокировок транзакции, но ещё и увеличите риск появления неверных вычислений.
Метод подходит в случае, если решить проблему нужно срочно, и вероятность ошибок вычислений низка. Например, если есть возможность попросить всех сотрудников, имеющих доступ к 1С, временно не пользоваться программой и не проводить никакие документы.
Чтобы исключить риск неправильных вычислений, лучше всего проверить после этого всё вручную.
Отключение других пользователей от 1С
- Как мы поняли выше, «Конфликт блокировок при выполнении транзакции» вызываются тем, что несколько пользователей работают с одним документом.
- Таким образом, если этих пользователей отключить, то можно будет снять очередь на проведение документов и и провести свой документ, который ранее был заблокирован.
- Этот метод подойдёт в том случае, если у вас в системе 1С есть права на просмотр пользователей, работающих с тем же документом, что и вы, и возможность завершения их сеансов.
- Завершив их сеанс, вы можете провести свои вычисления без блокировок.
Тут также есть риск появления ошибок. Ведь другие пользователи в момент завершения их сеансов, могли выполнять какие важные операции в документе. И после их выхода их системы эти вычисления останутся незавершёнными и не сохранёнными.
И также рекомендуется всё проверить после завершения проводки.
Как сделать, чтобы ошибка конфликта блокировок при выполнении транзакции больше не появлялась в 1С 8.3
Описанные выше два способа подходят лишь как временные варианты, как говорится «поставить систему на костыли». То есть, можно быстро решить проблему, чтобы выполнить срочные действия, но всегда так делать не получится. Не будете ведь вы всегда переводить систему в ручной режим с рисками для вычисления операций, и не станете каждый раз отключать сеансы других пользователей, которые тоже могут быть заняты важной работой
.
Чтобы навсегда избавиться от конфликта блокировок при выполнении транзакции, следуют уже пригласить программиста, так как для этого потребуется специальный опыт.
Спасибо за ответ. Но вот про это я не понял
Цитата: ilyay от 03 окт 2016, 15:10
Во-первых, если транзакция завершилась, то данные есть, а если не завершилась, их нет. Промежуточного состояния не может быть.
Как не может? Вот я беру тестовую базу, открываю в двух экземплярах. В одном окне запускаю любую длительную транзакцию, ну просто для примера
НачатьТранзакцию();
Ном = Справочники.Номенклатура.Выбрать();
сч=0;
Пока Ном.Следующий() И сч<10000 Цикл
сч = сч + 1;
Об=Ном.ПолучитьОбъект();
Об.Наименование = Об.Наименование + "1234";
Об.Записать();
КонецЦикла;
ОтменитьТранзакцию();
Процесс пошёл. Система начинает массово перезаписывать номенклатуры. Каждый раз срабатывает моя подписка «Перед записью», она получает нужные мне доп.данные, пишет их в регистр. Если в это время во втором окне открыть консоль запросов и написать мой запрос из фонового задания (ВЫБРАТЬ * ИЗ РегистрСведений.<ИмяРегистра>) то данные вполне себе есть. Я могу их спокойно считывать, обрабатывать, и пересылать «кривые» наименования с «1234» в другую базу. И это не смотря на то, что транзакция ещё не завершилась. Когда же транзакция отменится все записи из регистра исчезнут, как будто их там и не было. Но всё то время, что шла транзакция, они там были и были доступны для чтения… И если фоновое задание в этот период сработает то оно их прочитает и перешлёт неверные наименования. Разве нет?
Цитата: ilyay от 03 окт 2016, 15:10Не проверяйте время окончания транзакции (это технологически неверно). Вы видите, что транзакция закончилась, лезете в базу, а в этот момент там параллельно началась другая транзакция.
Я получаю время не окончания, а начала самой ранней из активных транзакций. Именно из-за того что я описал выше я и решил отделить те записи, по которым транзакция, возможно, ещё не завершена (и они могут впоследствии «исчезнуть» из регистра, если транзакция к которой они относятся будет отменена) и те, которые уже ТОЧНО зафиксированы.
Цитата: ilyay от 03 окт 2016, 15:10Если режим блокировок управляемый, тогда устанавливайте их явно: БлокировкаДанных = Новый БлокировкаДанных и т.д.
Я читал про эту возможность, но, честно говоря, никогда не ставил блокировки данных вручную. У нас есть несколько «самописных» регистров, куда пишутся данные, нигде ничего подобного не написано насчёт блокировок. Всё работает. Попробую, если ничего другого не получится.
Цитата: ilyay от 03 окт 2016, 15:10Скорее всего, взаимная блокировка возникает, потому что вы не блокируете данные (в режиме исключительно), которые собираетесь изменять, до чтения их запросом. Надо Заблокировать-Прочитать-Записать в транзакции.
Спасибо, попробую. А если я заблокирую все записи в регистре, а в этот момент сработает очередное «ПередЗаписью» и запрос | ВЫБРАТЬ ЕСТЬNULL(МАКСИМУМ(Номер), 0) КАК Номер
| ИЗ РегистрСведений.<ИмяРегистра>» попытается прочитать этот регистр, то что будет? Не будет ли в этом случае ошибка, из-за того что регистр не доступен для чтения?
Добавлено: 04 окт 2016, 16:15
Ну вот. Я разобрался где ошибка, всё оказалось проще, чем я думал. Ошибся я в запросе к SQL серверу. Он возвращает дату начала транзакции иногда как дату, а иногда как строку!, в формате месяц-день-год-время-PMAM. Почему так, я пока не понял. Когда тестировал на отладке всегда возвращалась дата-время. Отсюда урок — нужно в подобных запросах не забывать писать CONVERT(datetime,<Дата>,13). А в 1С проверять ТипЗнч, которое я получил. Потому что 1С запросу с условием «ГДЕ ДатаВерсии < &ДатаВерсии» всё равно что я ему подсунул дату или любую абракадабру в виде строки. Он всё равно выполняется без ошибок, только ничего не фильтурет и выдаёт все записи. Поэтому и блокировка, что я пытался стереть записи, по которым ещё шла транзакция.