Ошибка блокировки объекта объект уже заблокирован приложение тонкий клиент

Опять блокировки объектов

Я

  

123GO

02.04.18 — 11:50

  

123GO

1 — 03.04.18 — 10:11

никто не вкурсе, в чем дело?(

  

tesseract

2 — 03.04.18 — 10:52

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

  

assasu

3 — 03.04.18 — 10:59

  

assasu

4 — 03.04.18 — 11:00

моя тема… все решилось как перешли на 8.3.10.2699

  

123GO

5 — 04.04.18 — 06:45

(2) от обменов ушли год назад из-за постоянных коллизий

  

123GO

6 — 04.04.18 — 06:47

(4) Спасибо, почитал тему. Думаю, должно получиться. Буду пробовать)

  

assasu

7 — 04.04.18 — 06:47

(5) делаете что-то не правильно . у нас распределенка из 7 магазинов, обмен каждые 30 минут . коллизии есть.. раз в квартал на 5 минут ..

  

hhhh

8 — 04.04.18 — 09:32

(5) ну это и есть коллизии. никуда вы не ушли, получается.

  

Сияющий в темноте

9 — 04.04.18 — 09:56

  

assasu

10 — 04.04.18 — 09:59

  

123GO

11 — 12.04.18 — 05:00

Переход на 8.3.10.2699 не решил проблему.

  

123GO

12 — 12.04.18 — 08:39

Причем если устанавливаю эту платформу на обычную рабочку и разворачиваю копию базы, все ок! С единственной разницей, что на веб публикуется платформа x64, а на рабочке x32.

  

123GO

13 — 12.04.18 — 08:54

А есть вообще разница какой дистрибутив публиковать?

  

123GO

14 — 12.04.18 — 10:34

В общем, если кому интересно. 8.3.10.2667 может и не была проблемной платформой. Проблема заключалась вот в чем — нужно было публиковать дистрибутив x32 (включите поддержку 32-разрядных приложений в IIS) и у меня не заработало пока не поменял режим управляемого конвейера пула со встроенного на классический. Плюс ушла проблема и на конфигурации Управление небольшой фирмой — я месяц назад плюнул на блокировки в тонком клиенте (программа ругалась на блокировку практически всех объектов СВОИМ же сеансом) и перевел пользователей в терминальный режим.

  

123GO

15 — 13.04.18 — 04:34

  

123GO

16 — 13.04.18 — 04:36

(10) Прям в точности как у assasu. Только мне переход на 8.3.10.2699 не помог(. Есть еще идеи по этому поводу? Может какая настройка в сервере 1с или sql?

  

igorPetrov

17 — 13.04.18 — 04:39

(16) Обмены, обмены…

(17) Даже если это будет работать через РИБ, блокировки у подразделений все равно останутся

Содержание
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 сервер сам принимает решение, что надо укрупнить область наложения блокировок вплоть до блокировки целиком всей таблицы. В результате работа пользователей останавливается, и все ждут завершения проведения одного документа – виновника эскалации, либо когда по таймауту снимутся взаимные блокировки, либо произойдет перезагрузка сервера. В каких случаях возникает эскалация и как с этим бороться тоже тема для отдельной статьи.

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

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

Опять блокировки объектов

Я

   123GO

02.04.18 — 11:50

Магазины работают на тонких клиентах, Розница 2.2 опубликована через IIS, платформа уже поменялась с 8.3.10.2561 на 8.3.10.2667. Но все равно, каждый раз при редактировании ЛЮБОГО документа: Ошибка блокировки объекта. Объект уже заблокирован:

пользователь: .., приложение: Тонкий клиент. ВАЖНО: варианты на выбор ЗАВЕРШИТЬ РАБОТУ или ПЕРЕЗАПУСТИТЬ.

То есть база закрывается и пользователю нужно снова открывать 1с.

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

   123GO

1 — 03.04.18 — 10:11

никто не вкурсе, в чем дело?(

   tesseract

2 — 03.04.18 — 10:52

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

   assasu

3 — 03.04.18 — 10:59

   assasu

4 — 03.04.18 — 11:00

моя тема… все решилось как перешли на 8.3.10.2699

   123GO

5 — 04.04.18 — 06:45

(2) от обменов ушли год назад из-за постоянных коллизий

   123GO

6 — 04.04.18 — 06:47

(4) Спасибо, почитал тему. Думаю, должно получиться. Буду пробовать)

   assasu

7 — 04.04.18 — 06:47

(5) делаете что-то не правильно . у нас распределенка из 7 магазинов, обмен каждые 30 минут . коллизии есть.. раз в квартал на 5 минут ..

   hhhh

8 — 04.04.18 — 09:32

(5) ну это и есть коллизии. никуда вы не ушли, получается.

   Сияющий в темноте

9 — 04.04.18 — 09:56

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

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

   assasu

10 — 04.04.18 — 09:59

вы не обратили внимание на это :

[ ВАЖНО: варианты на выбор ЗАВЕРШИТЬ РАБОТУ или ПЕРЕЗАПУСТИТЬ. ]

   123GO

11 — 12.04.18 — 05:00

Переход на 8.3.10.2699 не решил проблему.

   123GO

12 — 12.04.18 — 08:39

Причем если устанавливаю эту платформу на обычную рабочку и разворачиваю копию базы, все ок! С единственной разницей, что на веб публикуется платформа x64, а на рабочке x32.

   123GO

13 — 12.04.18 — 08:54

А есть вообще разница какой дистрибутив публиковать?

   123GO

14 — 12.04.18 — 10:34

В общем, если кому интересно. 8.3.10.2667 может и не была проблемной платформой. Проблема заключалась вот в чем — нужно было публиковать дистрибутив x32 (включите поддержку 32-разрядных приложений в IIS) и у меня не заработало пока не поменял режим управляемого конвейера пула со встроенного на классический. Плюс ушла проблема и на конфигурации Управление небольшой фирмой — я месяц назад плюнул на блокировки в тонком клиенте (программа ругалась на блокировку практически всех объектов СВОИМ же сеансом) и перевел пользователей в терминальный режим.

   123GO

15 — 13.04.18 — 04:34

   123GO

16 — 13.04.18 — 04:36

(10) Прям в точности как у assasu. Только мне переход на 8.3.10.2699 не помог(. Есть еще идеи по этому поводу? Может какая настройка в сервере 1с или sql?

   igorPetrov

17 — 13.04.18 — 04:39

(16) Обмены, обмены…

(17) Даже если это будет работать через РИБ, блокировки у подразделений все равно останутся

Ошибка блокировки объекта. Объект уже заблокирован

Автор demon3, 23 янв 2018, 07:33

0 Пользователей и 1 гость просматривают эту тему.

---

---

---

---

---

Виталий Заглянувший Сообщений: 141 Авторитет: 0 Регистрация: 31.05.2011

При переходе на платформу 8.3.15.1830 стала возникать ошибка блокировки. Появляется в момент когда документ или элемент справочника открыли 2 пользователя и один начинает записывать. При этом выдает сообщение о блокировки и 2 варианта Завершить или Перезапустить 1С. Раньше была просто кнопка ОК и можно продолжать работать. Это особенность новой платформы или можно избежать как-то? режим совместимости изменить или в коде прописать?

Виталий Заглянувший Сообщений: 141 Авторитет: 0 Регистрация: 31.05.2011	Уточню, что возникает когда один из пользователей сделал изменения и записал, заблокировав объект, но не закрыл, а второй открывает делает изменения и записывает

Светлана Сулименко Посетитель Сообщений: 8911 Авторитет: 265 Регистрация: 16.10.2012	#3 0 22.01.2020 09:17:50 Виталий, мы не тестировали работу Альфа-Авто на указанной версии платформы 1С, рекомендуемая версия платформы 1С для актуального релиза (5,1,18,07) 8,3,14,1779.