В многопользовательских системах важную роль играет правильная организация структуры и настройка блокировок. Если ее нет, пользователям придется часто сталкиваться с ошибками, вызванными конкуренцией за определенные ресурсы системы. Но существует проблема конфликта блокировок, знакомая многим пользователям. Почему возникает конфликт блокировок 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С. После таких действий необходимо найти уязвимые места в системе, оптимизировать конфигурацию или работу сотрудников. Использовать подобные меры на постоянной основе при регулярных конфликтах блокировок на транзакциях не рекомендуется.
27.02.21 — 07:04
Несколько дней назад начала тормозить УТ 11. Долго проводит документы, периодически выдает конфликт блокировок, например:
Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки
{ОбщийМодуль.ОбщегоНазначенияУТКлиент.Модуль(1957)}: Результат = Форма.Записать(ПараметрыЗаписи);
{Документ.РеализацияТоваровУслуг.Форма.ФормаДокумента.Форма(8061)}: ОбщегоНазначенияУТКлиент.ОбработатьЗаписьОбъектаВФорме(ЭтотОбъект, ПараметрыДляЗаписи);
по причине:
Ошибка при выполнении обработчика — ‘ОбработкаПроведения’
по причине:
Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки
{ОбщийМодуль.ПроведениеСерверУТ.Модуль(355)}: Объект.Движения.Записать();
{Документ.РеализацияТоваровУслуг.МодульОбъекта(1238)}: ПроведениеСерверУТ.ЗаписатьНаборыЗаписей(ЭтотОбъект);
по причине:
Ошибка при выполнении обработчика — ‘ПередЗаписью’
по причине:
Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки
{РегистрСведений.ГрафикПлатежей.МодульМенеджера(12)}: Блокировка.Заблокировать();
{РегистрНакопления.РасчетыСКлиентами.МодульНабораЗаписей(157)}: РегистрыСведений.ГрафикПлатежей.УстановитьБлокировкиДанныхДляРасчетаГрафика(
{ОбщийМодуль.ПроведениеСерверУТ.Модуль(355)}: Объект.Движения.Записать();
{Документ.РеализацияТоваровУслуг.МодульОбъекта(1238)}: ПроведениеСерверУТ.ЗаписатьНаборыЗаписей(ЭтотОбъект);
по причине:
Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки
База на SQL, активных пользователей 6-7, документов реализаций в день до 150, в самом большом документе 50 позиций. В общем, объемы ни о чем. Сервер этот должен тянуть все и не задумываться:
https://yadi.sk/i/6y3VzqmAsfQQig
На этом же сервере стоит центральная розница с таким же объемом документов и все нормально работает, то есть вроде как проблема именно в этой базе. ТИИ делали, не помогло. Создали в СКЛ новую базу и загрузили через ДТ в нее. То же самое. Что еще посмотреть можно?
1 — 27.02.21 — 07:05
Диск там ССД м2, в общем к нему тоже никакой очереди нет.
2 — 27.02.21 — 07:09
Вот такая ошибка бывает:
Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки
{ОбщийМодуль.ОбщегоНазначенияУТКлиент.Модуль(1957)}: Результат = Форма.Записать(ПараметрыЗаписи);
{Документ.РеализацияТоваровУслуг.Форма.ФормаДокумента.Форма(8061)}: ОбщегоНазначенияУТКлиент.ОбработатьЗаписьОбъектаВФорме(ЭтотОбъект, ПараметрыДляЗаписи);
по причине:
Ошибка при выполнении обработчика — ‘ОбработкаПроведения’
по причине:
Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки
{РегистрСведений.АналитикаУчетаПоПартнерам.МодульМенеджера(20)}: НаборЗаписей.Прочитать();
{Документ.РеализацияТоваровУслуг.МодульМенеджера(5589)}: Запрос.УстановитьПараметр(«АналитикаУчетаПоПартнерам», РегистрыСведений.АналитикаУчетаПоПартнерам.ЗначениеКлючаАналитики(Запрос.Параметры));
{Документ.РеализацияТоваровУслуг.МодульМенеджера(2274)}: УстановитьПараметрЗапросаАналитикаУчетаПоПартнерам(Запрос);
{Документ.РеализацияТоваровУслуг.МодульМенеджера(1702)}: ТекстЗапросаТаблицаСебестоимостьТоваров(Запрос, ТекстыЗапроса, Регистры);
{Документ.РеализацияТоваровУслуг.МодульОбъекта(1190)}: Документы.РеализацияТоваровУслуг.ИнициализироватьДанныеДокумента(Ссылка, ДополнительныеСвойства);
по причине:
Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки
3 — 27.02.21 — 07:16
ДЛя этого существует техжурнал.
4 — 27.02.21 — 07:18
Причем по ЖР вижу, что в момент, когда я ловлю конфликт блокировок, в базе ничего не происходит:
https://yadi.sk/i/N2Ff1tJ5bZJRTA
5 — 27.02.21 — 07:24
(3) Попрошу админа, чтобы настроил. Может там что путного увидим.
7 — 27.02.21 — 07:49
(3) в ТЖ вот так:
44:41.647003-0,EXCP,5,process=rphost,p:processName=UT,OSThread=14248,t:clientID=26,t:applicationName=1CV8C,t:computerName=TERMSERV,t:connectID=120222,SessionID=10,Usr=Скондакова Ирина,AppID=1CV8C,DBMS=DBMSSQL,DataBase=sqlservUT,Exception=DataBaseException,Descr=’Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки’,Context=’Форма.Записать : Документ.РеализацияТоваровУслуг.Форма.ФормаДокумента
Документ.РеализацияТоваровУслуг.МодульОбъекта : 822 : ЗаполнитьВидыЗапасов(Отказ);
Документ.РеализацияТоваровУслуг.МодульОбъекта : 2698 : ЗапасыСервер.ЗаполнитьВидыЗапасовПоТоварамОрганизаций(ЭтотОбъект, МенеджерВременныхТаблиц, Отказ, ПараметрыЗаполнения);
ОбщийМодуль.ЗапасыСервер.Модуль : 593 : УстановитьБлокировкуРегистров(ДокументОбъект, МенеджерВременныхТаблиц);
ОбщийМодуль.ЗапасыСервер.Модуль : 5514 : Блокировка.Заблокировать();’
44:41.662216-0,EXCP,2,process=rphost,p:processName=UT,OSThread=14248,t:clientID=26,t:applicationName=1CV8C,t:computerName=TERMSERV,t:connectID=120222,SessionID=10,Usr=Скондакова Ирина,AppID=1CV8C,Exception=afd2b550-0d52-4e03-b448-15ed68d87ac5,Descr=»srcDocumentLogFormObjController.cpp(884):
afd2b550-0d52-4e03-b448-15ed68d87ac5
0d2200af-1696-4395-91e5-2872675e6d3d: Ошибка при выполнении обработчика — ‘ПередЗаписью’
8d366056-4d5a-4d88-a207-0ae535b7d28e: Ошибка при вызове метода контекста (Заблокировать)
{ОбщийМодуль.ЗапасыСервер.Модуль(5514)}: Блокировка.Заблокировать();
{ОбщийМодуль.ЗапасыСервер.Модуль(593)}: УстановитьБлокировкуРегистров(ДокументОбъект, МенеджерВременныхТаблиц);
{Документ.РеализацияТоваровУслуг.МодульОбъекта(2698)}: ЗапасыСервер.ЗаполнитьВидыЗапасовПоТоварамОрганизаций(ЭтотОбъект, МенеджерВременныхТаблиц, Отказ, ПараметрыЗаполнения);
{Документ.РеализацияТоваровУслуг.МодульОбъекта(822)}: ЗаполнитьВидыЗапасов(Отказ);
f08d92f8-9eb2-4e19-9dd9-977d907cec2d
dc31263e-ecbf-41bd-9b3a-7b55897d5fd6: Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки»
44:41.725101-0,EXCP,2,process=rphost,p:processName=UT,OSThread=14248,t:clientID=26,t:applicationName=1CV8C,t:computerName=TERMSERV,t:connectID=120222,SessionID=10,Usr=Скондакова Ирина,AppID=1CV8C,Exception=580392e6-ba49-4280-ac67-fcd6f2180121,Descr=»srcVResourceInfoBaseImpl.cpp(1129):
580392e6-ba49-4280-ac67-fcd6f2180121: Неспецифицированная ошибка работы с ресурсом
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
afd2b550-0d52-4e03-b448-15ed68d87ac5
0d2200af-1696-4395-91e5-2872675e6d3d: Ошибка при выполнении обработчика — ‘ПередЗаписью’
8d366056-4d5a-4d88-a207-0ae535b7d28e: Ошибка при вызове метода контекста (Заблокировать)
{ОбщийМодуль.ЗапасыСервер.Модуль(5514)}: Блокировка.Заблокировать();
{ОбщийМодуль.ЗапасыСервер.Модуль(593)}: УстановитьБлокировкуРегистров(ДокументОбъект, МенеджерВременныхТаблиц);
{Документ.РеализацияТоваровУслуг.МодульОбъекта(2698)}: ЗапасыСервер.ЗаполнитьВидыЗапасовПоТоварамОрганизаций(ЭтотОбъект, МенеджерВременныхТаблиц, Отказ, ПараметрыЗаполнения);
{Документ.РеализацияТоваровУслуг.МодульОбъекта(822)}: ЗаполнитьВидыЗапасов(Отказ);
f08d92f8-9eb2-4e19-9dd9-977d907cec2d
dc31263e-ecbf-41bd-9b3a-7b55897d5fd6: Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки»
8 — 27.02.21 — 09:39
Что сделали недавно, обновление релиза например?
9 — 27.02.21 — 09:49
Ну сделай вместо 20 сек ожидания 60 сек. А так кури скл, регламенты если не можешь переписать заполнение запасов чтобы за 2 сек пролетало )
10 — 27.02.21 — 10:55
(9) Лучше наоборот, 0. Тогда будет видней.
Было видео, как чел анализировал блокировки в 1с…
11 — 27.02.21 — 10:56
(0) rls есть?
12 — 27.02.21 — 11:05
(8) В январе обновляли платформу. Работало нормально. Щас 8.3.18.1208, думаем попробовать обновить.
13 — 27.02.21 — 11:05
похоже кто-то взаиморасчёты восстанавливает или простот месяц закрывает
14 — 27.02.21 — 11:06
(11) Нет
15 — 27.02.21 — 11:10
(13) Нет, работают только бухи, занимающиеся первичкой. Месяц в этой базе вообще никто никогда не закрывал и не собираются. База по сути нужна только для контроля остатков.
16 — 27.02.21 — 11:12
(10) а ноль это что? 0сек или бесконечность? Если ноль — вторая сессия всегда вылетит 100%
17 — 27.02.21 — 11:13
(15) и фоновых тоже на эту тему нет?
а ля предварительный расчёт
18 — 27.02.21 — 11:13
кстати период итогов какой?
19 — 27.02.21 — 11:14
(15) погляди на РЗ -отключи временно ненужные.
20 — 27.02.21 — 11:16
21 — 27.02.21 — 11:16
по хорошему нужно цуп поставить чтобы видеть 2 сторону блокировок.
или по тж искать всех кто в тот момент ставил блокировки
22 — 27.02.21 — 11:16
(17) Фоновых активных тоже нет
23 — 27.02.21 — 11:18
ну предварительная себестоимость есть, а говорил чтотне нужна
24 — 27.02.21 — 11:54
(0) сравните настройки бд. возможны различия
25 — 27.02.21 — 12:25
(0)
1. По журналу регистрации проверить, что происходит в этот момент времени. Возможно идет перепроведение документов или еще какая-то ресурсоемкая операция.
2. На стороне SQL посмотреть кто кого блокирует.
3. После того, как найден «виновник» — ищем причину. Возможно, кривой запрос. Или количество объектов для обработки выросло, что привело к повышению ресурсов для обработки. Либо что-то случилось с индексами на стороне SQL (запрос не попадает в индекс).
Вопрос тут гораздо шире и сложнее, чем «ТИИ делали,из ДТ загружали в новую базу». — это всё их разряда «Колесо пинал? Стекло протирал?».
26 — 27.02.21 — 12:34
+25 В (4) вижу, что у пользователя ДмитрийК в сеансе 43 висит активная транзакция (серые события в ЖР). Что он там делает?
Есть основания полагать — что он твой враг.
27 — 27.02.21 — 12:38
Некоторые в транзакции любят че-нить спросить у пользователя и ждать его ответа, как пример.
28 — 27.02.21 — 13:11
Давай уже автор колись,ведь не типовая ут же
29 — 27.02.21 — 13:14
(23) Имею в виду, месяц не закрывают, так как на СБ не смотрят.
30 — 27.02.21 — 13:16
(26) Это мой пользователь. Серые транзакции, это которые отменились, после того как я получил отказ из за конфликта блокировок.
31 — 27.02.21 — 13:18
(28) Не типовая. База не моя, попросили посмотреть. Это только сравнивать с типовым цф и искать доработки. По расширениям бегло прошелся, там криминала никакого не нашел.
32 — 27.02.21 — 13:18
(29) а зачем тогда задание работает? и всякие свертки запасов?
33 — 27.02.21 — 13:21
(32) Ну зачем то кто то включил. Они вроде все ночью отрабатывают. Не должны днем мешать
34 — 27.02.21 — 13:25
Причина тормозов УТ11 в УТ11, а точнее в сущности управляемых форм! Поставили новую, чистую, типовую, естественно не в файловом режиме — справочник НСИ, пустой! открывается секунд 5!
Что же это такое то а?? Насовали динамических списков, круто. А как на этом всем ехать то? Сами думайте? Ох. Извините.
35 — 27.02.21 — 13:27
Тестовую базу поднял? Чтоб без ущерба основной можно было вычленить виновника и почистить его?
— Сделать замеры в тестовой.
— Набросать обработку в тестовой и грохнуть ГрафикПлатежей
— Еще раз сделать замеры.
Если не поможет, то посмотреть на другие подобные РС. Скорей всего, что трабла именно в РС, т.е. на оборотные и остаточные регистры смотрят гораздо чаще. Хотя, могут в и них быть.
36 — 27.02.21 — 13:31
самый верный способ сейчас поднять цуп, чтобы увидеть полную картину блокировок
37 — 27.02.21 — 13:40
Еще не удивлюсь, если база будет подвисать и неадекватно проводить реализацию даже в монопольном режиме.
Так что вполне вероятно, что все поиски виновника тормозов и блокировок от них же можно завершить простым замером производительности
Поднятие ЦУП — это как из пушки по воробьям. Ну нет там такого при работе 6-7 пользователей, чтобы оправдались усилия по разворачиванию ЦУП
38 — 27.02.21 — 18:09
(37) цуп нужен чтобы найти того кто блокирует,
можно и вручную конечно поискать
39 — 27.02.21 — 18:10
чтобы в 1 сеансе были блокировки это нужно проведение на фоновых изобрести
40 — 27.02.21 — 18:15
(39) так понятно, что в монопольном сеансе у него блокировка не возникнет. Всего 6 пользователей. Поступление, перемещение, отгрузка или реализация. Это же не 30-40, у которых документы из самых разных участков учета.
Это что в проведении в одного будет тормозить, на том и блокировка будет зависать.
А ведь можно и заблокировать нечто при открытии формы. Но вряд ли. У него в сообщении топика список прямо уже показан.
41 — 27.02.21 — 18:17
График платежей, который никто не чистил никогда… А запрашивается с начала времен в периодике и левом соединении в запросе…
42 — 27.02.21 — 18:27
а что с итогами?
43 — 27.02.21 — 18:39
Эта платформа 1208 кривая из за нее тормоза, в 1с даже сами косяк этого релиза признали
44 — 27.02.21 — 20:33
(43) А ты дивный или диванный?
45 — 27.02.21 — 20:41
Все просто. Таблица итогов регистров разъелась из-за не закрытых регистров. А они не закрываются из-за не выполнения регламента в базе, например закрытия месяцев. В результате блокировка вызывает эскалацию блокировки до уровня таблицы. Закройте месяцы, обслужить базу, пересчитать итоги и будет счастье. Но и конечно самостоятельно проверьте чтобы регистры закрывались.
46 — 27.02.21 — 21:05
https://forum.infostart.ru/forum68/topic254158/
Не знаю можно ли ветки тут с других форумов постить
47 — 27.02.21 — 21:13
(46) Тормоза и блокировки — разные вещи. Хотя и из второго следует первое.
48 — 27.02.21 — 22:53
(47) скорее всего там звёзды сложились обновление платформы и допилы конфигурации
49 — 01.03.21 — 19:52
Обновление платформы на 8.3.18.1289 ничего не дало. В РС «График платежей» 8650 записей. Это много? Как его нужно чистить? Нужно ли?
50 — 01.03.21 — 19:54
Кстати, итоги рассчитаны на актуальную дату. Сейчас на 28.02
51 — 01.03.21 — 19:56
52 — 01.03.21 — 20:52
нашли уже 2ю сторону блокировок?
53 — 01.03.21 — 21:19
(52) Нет. Обязательно ЦУП поднимать? Как еще поискать можно?
54 — 01.03.21 — 21:43
смотреть тж кто что блокировал когда был таймаут
55 — 01.03.21 — 21:44
собственно цуп это и делает
56 — 01.03.21 — 22:00
судя по коду УстановитьБлокировкиДанныхДляРасчетаГрафика
скорее всего блокируется ТаблицаОбъектовОплаты — выгрузите её в отладчике в первом сеансе и посмотрите что прилетает туда во втором
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить(ИмяТаблицы);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.ИсточникДанных = ТаблицаОбъектовОплаты;
ЭлементБлокировки.ИспользоватьИзИсточникаДанных(ИмяПоля, «ОбъектОплаты»);
Блокировка.Заблокировать();
57 — 02.03.21 — 00:37
Для начала нужно понять, что блокировка управляемая и сервер СУБД не виноват
А дальше искать, как расследуются таймауты на управляемых блокировках
shiling
58 — 30.07.21 — 08:34
Зафиксирую решение, так как в поиске выдает ветку
Описание:
При проведении документа «Приобретение товаров и услуг» в клиент-серверном режиме может возникать конфликт блокировок при выполнении транзакции
Превышено максимальное время ожидания предоставления блокировки
{ОбщийМодуль.ОбщегоНазначенияУТКлиент.Модуль(1957)}: Результат = Форма.Записать(ПараметрыЗаписи);
{Документ.ПриобретениеТоваровУслуг.Форма.ФормаДокумента.Форма(8497)}: ОбщегоНазначенияУТКлиент.ОбработатьЗаписьОбъектаВФорме(ЭтотОбъект, ПараметрыДляЗаписи);
Способ обхода:
Изменить расчеты с онлайн на оффлайн и вернуть обратно на онлайн
(НСИ и Администрирование — Настройки НСИ и разделов — Казначейство и взаиморасчеты — Взаиморасчеты — выбор значения в поле Взаиморасчеты).
Иногда при работе в 1С может возникнуть ошибка «Конфликт блокировок при выполнении транзакции: превышено максимальное время ожидания предоставления блокировки». Рассмотрим как исправить данную ошибку.
Содержание
- Конфликт блокировок при выполнении транзакции в 1С: причины и пути их устранения
- Причина 1. Одновременная работа пользователей с большим объемом данных
- Причина 2. Зависшие блокировки в 1С
- Причина 3. Ошибка в конфигурации
Причина 1. Одновременная работа пользователей с большим объемом данных
При одновременной работе нескольких пользователей с одной и той же информационной базой могут возникнуть ситуации, когда несколько пользователей пытаются внести в данные какие-то изменения. И в таких случаях, если не предусмотреть возможности подключения специальных механизмов системы, могут возникнуть проблемы с информационной базой, ее целостностью. При обращении нескольких сеансов к одним и тем же данным одновременно используются механизмы блокировок и транзакций.
Блокировка — это информация о том, что данный объект занят пользователем для выполнения какого-то действия. Смысл блокировки в запрете определенных действий над объектом на ограниченное время. Благодаря этим запретам сохраняется целостность и непротиворечивость информационной базы, предсказуемость работы пользователей.
Механизм объектных блокировок — обеспечивает конкурентный доступ пользователей к данным 1С, как правило, это работа пользователей в формах — создание новых объектов, их редактирование, удаление и др.
Для согласованного изменения данных в 1С применяется механизм транзакций, а для конкурентного доступа к данным — механизм транзакционных блокировок. Если транзакции нужно получить доступ к элементу, то она блокирует элемент и продолжает удерживать блокировку элемента до тех пор, пока не освободит элемент. Это происходит либо в ходе выполнения транзакции, либо по ее окончании как успешном, так и не успешном.
Поэтому, при одновременном чтении и изменении одних и тех же данных могут возникнуть проблемы одновременного доступа, о чем программа 1С и сообщает в ошибке. Это временная ошибка и когда другой пользователь завершит работу с этим объектом, ошибка не будет появляться.
Причина 2. Зависшие блокировки в 1С
Иногда возникают такие ситуации, что пользователь уже давно закрыл документ, вышел из программы, а его сеанс по-прежнему остается в системе. Т.е. какой-то сеанс поставил блокировку и не убрал ее. Такие ситуации чаще встречаются при использовании сетевых ключей защиты.
Оптимальный вариант решения проблемы — это найти и завершить сеанс, заблокировавший необходимые данные. В этом нам помочь может раздел Администрирование — Обслуживание, где можем посмотреть активных пользователей и при необходимости заблокировать их работу, т.е. отключить.
При большом количестве компьютеров, проблему можно решить завершив подобный сеанс через консоль администратора. С ее помощью можно управлять подключенными сеансами определенной информационной базы, управлять блокировками. В консоли администрирования можно посмотреть такие зависшие сеансы и удалить их. Эта утилита входит в состав 1С Предприятия.
Запустить ее можно из папки common — 1CV8Servers.
Причина 3. Ошибка в конфигурации
Конфигурации, разработанные фирмой 1С, учитывают все рекомендации по улучшению производительности. Но в программах сторонних разработчиков могут быть ошибки производительности в коде конфигурации, порождающие избыточные блокировки. Это является самой распространенной причиной ошибок конфликта блокировок, которые могут нарушить работу всех пользователей, постоянно блокируя нормальную работу в системе.
Если такого рода ошибки появляются часто, то разобравшись в причине, из-за которой возникает конфликт блокировок в 1С, необходимо их ликвидировать — определить уязвимые места в системе, оптимизировать конфигурацию, а также работу пользователей.
См. также:
- Недостаточно памяти 1С: как исправить
- Неверный формат хранилища данных 1С 8.3: как исправить
- Ошибка формата потока 1С 8.3: как исправить
- Ошибка СУБД: файл базы данных поврежден в 1С 8.3
- Не найден файл внешней компоненты в 1С 8.3: как исправить
Если Вы еще не являетесь подписчиком системы БухЭксперт8:
Активировать демо-доступ бесплатно →
или
Оформить подписку на Рубрикатор →
После оформления подписки вам станут доступны все материалы по 1С Бухгалтерия, записи поддерживающих эфиров и вы сможете задавать любые вопросы по 1С.
Подписывайтесь на наши YouTube и Telegram чтобы не пропустить
важные изменения 1С и законодательства
Помогла статья?
Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно
Содержание
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С.
Связаться с нами можно по телефону +7 499 350 29 00.
Услуги и цены можно увидеть по ссылке.
Будем рады помочь Вам!
Не редки случаи, когда причина ошибки кроется в регламентном задании, которое обрабатывает большое количеств данных. Рекомендуется подобные вещи делать ночью. Задайте расписание выполнение таких регламентных заданий во внерабочее время.
Таким образом, и пользователи будут работать в стабильной системе, и сами регламентные задания будут завершаться успешно, так как снизится вероятность возникновения конфликтов с пользовательскими сеансами.
«Зависшие сеансы»
Проблема «зависших сеансов» пользователей знакома практически каждому, кто сталкивался с обслуживанием 1С. Пользователь мог уже давно выйти из программы, или закрыть какой-либо документ, но его сеанс по-прежнему остается в системе. Проблема чаще всего единичная и достаточно завершить подобный сеанс через консоль администратора. Такие же проблемы могут возникнуть и с фоновыми заданиями.
По многочисленным комментариям на просторах интернета подобные ситуации чаще встречаются при использовании сетевых ключей защиты. Если ситуация с «зависающими сеансами» повторяется систематически, это причина произвести тщательную проверку и обслуживание системы и серверов (если база клиент-серверная).
Ошибки при написании конфигурации
Все типовые конфигурации разработаны квалифицированными специалистами и экспертами. Каждая система тщательно тестируется и оптимизируется для более быстрой и корректной работы в ней.
В связи с этим причина ошибки может крыться в неоптимальном коде, написанном сторонним разработчиком. Это может быть «тяжелый» запрос, который будет блокировать данные на длительный промежуток времени. Так же нередки случаи построения алгоритмов с низкой производительностью и нарушением логики.
Большая вероятность, что конфликт блокировки возник именно из-за ошибок разработчика, если он возник после обновления программы. Для проверки можно просто «откатить» доработки, либо произвести рефакторинг кода.