UPD 09.07.2024 добавлено воспроизведение блокировки в случае установки управляемой блокировки перед чтением набора записей регистра сведений.
UPD 10.07.2024 добавлена тестовая база с примером.
С недавнего времени я начала заниматься работами по оптимизации 1с, и решила написать несколько статей на эту тему, чтобы не забыть то, чему я научилась. Своеобразную базу знаний, поэтому если подобная задача уже где-то разбиралась, то прошу прощения. Заодно, возможно, кому-нибудь это поможет в работе. Любая критика статьи приветствуется.
Сегодня я разберу deadlock СУБД.
Итак, имеется программа доработанная программа 1С Медицина.Больничная аптека 2.0. режим управления блокировки данных — управляемый, платформа 8.3.10.2252, режим совместимости 8.3.8.
При проведении документов "Заказ поставщику" возникает deadlock на СУБД со следующим текстом:
Ошибка при вызове метода контекста (Записать): Ошибка при выполнении обработчика — ‘ОбработкаПроведения’: {РегистрСведений.ИзмененияЕдиницИзмеренияНоменклатуры.МодульМенеджера(72)}:
Ошибка при вызове метода контекста (Записать): Конфликт блокировок при выполнении транзакции: Microsoft SQL Server Native Client 11.0: Transaction (Process ID 87) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. HRESULT=80004005, SQLSrvr: SQLSTATE=40001, state=34, Severity=D, native=1205, line=1
Для начала настроим SQL profiler на сбор дедлоков. И довольно быстро ловим необходимое:
Видим, что дедлок возникает на одном ресурсе — InfoRg8072, по структуре данных видим, что это регистр сведений ИзмененияЕдиницИзмеренияНоменклатуры:
Таблица: РегистрСведений.ИзмененияЕдиницИзмеренияНоменклатуры, Имя таблицы хранения: InfoRg8072, Назначение: Основная
— поля:
Период (Period)
Номенклатура (Fld8073)
ЕдиницаИзмерения (Fld8074)
Документ (Fld8075)
Ответственный (Fld8076)
Ошибка (Fld8077)
ОбластьДанныхОсновныеДанные (Fld385)
— индексы:
ByPeriod
Период + Номенклатура + ЕдиницаИзмерения + Документ (Period + Fld8073 + Fld8074 + Fld8075)
ByDims
Номенклатура + ЕдиницаИзмерения + Документ + Период (Fld8073 + Fld8074 + Fld8075 + Period)
Метод пристального взгляда на код ничего не дал, поэтому я настроила ЦУП и поймала дедлок, чтобы проанализиро вать что именно происходит. ЦУП поймал блокировку: 
Посмотрим на содержимое блокировок процесса 1. Итак, смотрим на первую блокировку — U (блокировка обновления).
Запрос:
SELECT TOP 1
T1._Fld385
FROM dbo._InfoRg8072 T1
WHERE ((T1._Fld385 = ?)) AND (T1._Fld8073RRef = ? AND T1._Fld8074RRef = ? AND T1._Fld8075_TYPE = 0x08 AND T1._Fld8075_RTRef = 0x000000B6 AND T1._Fld8075_RRRef = ?)
План:
|—Top(TOP EXPRESSION:((1)))
|—Clustered Index Seek(OBJECT:([HP_w_sql_001].[dbo].[_InfoRg8072].[_InfoRg8072_ByDims] AS [T1]), SEEK:([T1].[_Fld385]=[@P1] AND [T1].[_Fld8073RRef]=[@P2] AND [T1].[_Fld8074RRef]=[@P3] AND [T1].[_Fld8075_TYPE]=0x08 AND [T1].[_Fld8075_RTRef]=0x000000B6 AND [T1].[_Fld8075_RRRef]=[@P4]) ORDERED FORWARD)
Ничего криминального не видно…
Смотрим дальше, еще одна блокировка U:
Запрос:
SELECT TOP 1
T1._Fld385
FROM dbo._InfoRg8072 T1
WHERE ((T1._Fld385 = ?)) AND (T1._Fld8075_TYPE = 0x08 AND T1._Fld8075_RTRef = 0x000000B6 AND T1._Fld8075_RRRef = ?)
План:
| |—Top(TOP EXPRESSION:((1)))
| |—Index Seek(OBJECT:([HP_w_sql_001].[dbo].[_InfoRg8072].[_InfoRg8072_ByPeriod] AS [T1]), SEEK:([T1].[_Fld385]=[@P1]), WHERE:([HP_w_sql_001].[dbo].[_InfoRg8072].[_Fld8075_RRRef] as [T1].[_Fld8075_RRRef]=[@P2] AND [HP_w_sql_001].[dbo].[_InfoRg8072].[_Fld8075_TYPE] as [T1].[_Fld8075_TYPE]=0x08 AND [HP_w_sql_001].[dbo].[_InfoRg8072].[_Fld8075_RTRef] as [T1].[_Fld8075_RTRef]=0x000000B6) ORDERED FORWARD)
А вот тут уже интереснее.
Видно, что тут использовался индекс, поскольку оператор Index Seek, но посмотрев повнимательнее, видим, что seek идет только по разделителю данных, ([_Fld385]=[@P1]), а у после seek идет where, это означает, что данным полям индекс использовать не удалось и происходит сканирование данных.
Почему не был использован индекс? Потому что в составном индексе крайне важен порядок следования полей. И если условия отбора есть в индексе, но не стоит в самом начале или идут не подряд, то индекс не может использоваться. В нашем случае есть вот такой индекс:
Номенклатура + ЕдиницаИзмерения + Документ + Период (Fld8073 + Fld8074 + Fld8075 + Period)
А запросе у нас есть отбор только по полю Документ (Fld8075). А перед этим в составном индексе есть еще и поле Номенклатура и ЕдиницаИзмерения, поэтому данный индекс не может использоваться.
Итак, получается первым запросом у нас блокируется одна запись из регистра _InfoRg8072, а потом блокируется почти весь регистр (рамках разделителя) до окончания транзакции.
Посмотрев второй процесс, можно обнаружить точно такие же запросы.
А что будет если два человека будут проводить документы с разными данными? Первый успешно блокирует блокировкой U одну запись из регистра, второй так же блокирует другую запись из этого же регистра, а дальше каждый из них пытается заблокировать весь регистр целиком, но не могут, потому что первый ждет второго, а второй — первого, что приводит к дедлоку.
Итак, почему же не используется индекс? Давайте посмотрим на индексы регистра _InfoRg8072
— индексы:
ByPeriod
Период + Номенклатура + ЕдиницаИзмерения + Документ (Period + Fld8073 + Fld8074 + Fld8075)
ByDims
Номенклатура + ЕдиницаИзмерения + Документ + Период (Fld8073 + Fld8074 + Fld8075 + Period)
Мы видим, что есть индекс, где первым полем идет Fld8075 отсутствует, а значит происходит сканирование данных.
Теперь давайте посмотрим код 1с:
Вот код, который отрабатывает при записи документа Заказ поставщику:
При выполнении строки
НаборЗаписей.Записать(Истина);
Выполняется первый запрос. (использующий индексы)
При проведении документа выполняется вот этот код:
При выполнении строки
НаборЗаписей.Записать(Истина);
Выполняется второй запрос. (не использующий индексы)
Как видно, здесь не стоят отборы по номенклатуре и единицы измерения, а есть только отбор по документу, поэтому подходящего индекса нет, он не используется.
Мы видим типичный дедлок захвата ресурса в разном порядке:
Первый пользователь захватывает ресурс 1 в регистре сведений,
Второй пользователь захватывает ресурс 2 в регистре сведений,
Дальше первый пытается захватить весь регистр (поскольку в плане запроса скан), но не может — натыкается на захват ресурса 2.
Второй так же пытается захватить весь регистр, но не может, поскольку натыкается на захват ресурса 1.
Итого — дедлок
Теперь решение этой проблемы.
Вариант 1.
Перенести измерение "Документ" наверх. В этом случае индекс будет строиться следующим образом:
ByDims
Документ + Номенклатура + ЕдиницаИзмерения + Период (Fld8075 + Fld8073 + Fld8074 + Period)
Вариант 2.
Проиндексировать измерение "Документ". Тогда в добавиться дополнительный индекс такого вида:
ByDims
Документ + Период + Номенклатура + ЕдиницаИзмерения (Fld8075 + Period + Fld8073 + Fld8074)
В обоих вариантах индекс будет использоваться, поскольку поле "Документ" находится в начале индекса.
По ряду причин был выбран второй вариант и после индексации измерения документ, дедлоки больше не возникали.
UPD 09.07.2024
В комментариях был задан хороший вопрос, а не возник ли дедлок по причине чтения в транзакции записей регистра, а затем его записи. Мол, это хрестоматийный пример дедока.
Но есть следующие проблемы.
1. Это пример дедлока на управляемой блокировке. А в моем примере блокировка СУБД
2. При проведении документа в коде ставится отбор по документу, чтобы воспроизвести такую блокировку мне нужно провести в двух сессиях один и тот же документ, что невозможно.
3. Для успокоения совести я провела следующий эксперимент.
а) Убрала индексирование измерения "документ"
б) Добавила управляемую блокировку в код (по просьбам, установив отбор по и номенклатуре):
г) Провела два документа с разными данными в разных сессиях, и на одном из них поймала дедлок СУБД:
Как видно, дедлок воспроизводится, несмотря на установку управляемой блокировки.
UPD 10.07.2024
Я подготовила для вас модельную базу, на которой воспроизводится дедлок. Там используется точно такой же код, который представлен в статье, специально, чтобы вы могли поупражнятся в оптимизации кода и установить какие угодно транзакции и блокировки.
PS
1. не забудьте развернуть базу в клиент-серверном варианте.
2. Дедлок возникает, если поставить точку останова в строке 40 модуля документа заказ поставщику.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
deadlock на СУБД
ээ.. а куда подевался Read Committed Snapshot Isolation?
Вы меня извините, но индексы и блокировки друг с другом не связаны.
Природа deadlock же состоит именно в порядке выполнения операций над отбираемыми (а не сканируемыми) строками.
Изменив план запроса, вы, видимо, сократили время блокировок и тем самым снизили вероятность взаимной блокировки. Но сама проблема никуда не делась, поскольку никакими индексами ее полностью убрать нельзя.
Я бы лишний раз подумал, прежде чем менять порядок полей в регистре или добавлять еще один индекс. Таким решением можно избавиться от одной редкой проблемы и получить себе ворох новых. Другие документы делающие движения в регистр могут начать это делать медленнее за счет еще одного индекса и за счет сломавшихся их собственных «оптимизированных» запросов.
(1) Read Committed Snapshot Isolation есть, но в этом случае ставится U-блокировка, а не S, поэтому строки блокируются в не зависимости от уровня изоляции транзакции
(4) Полностью согласен.
И, самое главное, причину взаимоблокировки новые индексы не устранят.
(2) Вы меня извините, но связаны. Неоптимальные запросы одна из причин избыточных блокировок и как одно из следствий — дедлоков. Про это можно почитать, например, вот тут:
(4) А я подумала. Это была доработка в конфигурации, я проверила, где именно она используется и каким образом. Именно поэтому отмела первый вариант, потому что в этом случае один из часто использующихся запросов будет выполнятся медленнее. А проблема на самом деле была очень нередкой, она возникала при каждом параллельном проведении документа «Заказ поставщику». То есть даже два пользователя не могли одновременно проводить документы с разными данными.
(6) Устраняют. Неоптимальные запросы одна из основных причин избыточных блокировок. И, как следствие, дедлоков.
Статья не совсем полная, как мне кажется. В начале указано, что при проведении документов возникает взаимоблокировка. То есть в одном сеансе проведение вызывает взаимоблокировку?
И еще, я лично ожидал увидеть здесь природу дедлока, т.е. не просто показ графа, а именно природу возникновения. Например, из-за разного порядка записи движений, пересечения блокируемых полей в разном порядке и т.п. А в статье только профайлер, ЦУП и, как мне кажется, не совсем верные выводы о том, что нужно делать. Действительно, Вы уменьшили время выполнения запроса, но не решили тем самым проблему, а просто снизили вероятность возникновения взаимоблокировки.
Кстати, в Вашем случае вполне вероятно помог бы отказ от объектного чтения регистра в процедуре УдалитьПризнак…
и наложением исключительной блокировки перед заполнением.
(9)
Повышение уровня блокировки ресурса в рамках одной транзакции. Вот Ваш вариант в данном случае
(5)
Насколько мне известно, U-блокировка ставится в автоматическом режиме и наличии оператора «ДЛЯ ИЗМЕНЕНИЯ». RCSI точно включено (проверить можно запросом из )?
(9) Думаю, в контексте данной статьи это утверждение истинно в случае не использования RCSI.
Если используется Read Committed, то блокировка возникает из-за разного порядка захвата ресурсов. Пусть для примера в регистре всего 2 записи. Первая транзакция сперва меняет первую запись, в этот момент вторая транзакция меняет вторую запись. Далее обе эти транзакции выполняют частичный скан таблицы — в этот момент и возникает deadlock. Добавив ещё один индекс по документу, Вы избавились от частичного скана, но проблема взаимоблокировки не устранили. Если попробовать провести два документа по 10к записей в табличной части, то ошибка должна воспроизвестись (из-за эскалации).
Сможете сделать cf с данным регистром, документом и обработкой проведения для тестирования (или выслать полный листинг обработки проведения)?
Подписки какие-то по данному документу имеются?
Думаю стоит дополнить статью информацией о том, как настраивать профайлер.
А также стоит наверное все же разъяснить это
По ряду причин был выбран второй вариант и после индексации измерения документ, дедлоки больше не возникали.
Что ряд причин это ни что иное как уже существующий код в других местах конфигурации, который использует индекс именно в этой последовательности
И если сдвинуть измерение «Документ» выше других то индекс перестроится к виду:
и соответственно начнет работать в этом куске кода корректно, но приведет к не оптимальной работе (а возможно и другим дедлокам) в других участках кода где используется этот индекс, т.к. произойдет аналогичная ситуация, которая описана в этой статье — там начнет производится сканирование таблиц вместо поиска по индексу.
Именно по этой причине правильнее добавить индекс по отдельному измерению «Документ» дополнительно.
А так за статью конечно плюс!
(0) проще грохнуть этот сомнительный регистр, код кривой, индексы кривые… шутка
«Итак, получается первым запросом у нас блокируется одна запись из регистра _InfoRg8072, а потом блокируется почти весь регистр (рамках разделителя) до окончания транзакции.»
Как Вам уже верно заметили — блокируется действительно только одна запись, а затем идет частичный скан таблицы, потому что индексы использовать не удалось и среди сканируемой области как раз и попадается точно также заблокированная запись — вот и дедлок.
Плюсую за отдельный индекс по измерению «Документ».
А еще можно чуть изменить прикладную логику. Вторую процедуру (судя по ее названию) — вполне можно вынести в регламентное задание. Регистрировать где-нибудь проводимые документы (в плане обмена, отдельном регистре и т.д.) и затем обрабатывать.
Мне одному кажется что не обязательно делать запись в цикле ?
И нафига его вообще читать если все равно потом перезаписывать.
Или это учебный пример ?
Ну а то что дедлок с индексами никак не связан — это уже выше сказали, дедлок — это повышение уровня транзакции, его вы не поймали.
Спасибо, видимо я не внятно написала, раз для остальных это неочевидно. Если вы не против, я добавлю это в свой текст.
(17) У меня не стояла задача критиковать код коллеги, честно говоря, у меня тоже много к нему вопросов)
Это реальный пример из рабочей базы.
А дедлок с индексами связан, выше я объяснила почему.
Это дедлок не повышения уровня транзакции, у вас, видимо, путаница в терминологии, вы имели ввиду повышение режима блокировки, но это все равно не он)
Это дедлок захвата ресурса в разном порядке. Еще раз попробую объяснить:
Первый пользователь захватывает ресурс 1 в регистре сведений,
Второй пользователь захватывает ресурс 2 в регистре сведений,
Дальше первый пытается захватить весь регистр (поскольку в плане запроса скан), но не может — натыкается на захват ресурса 2.
Второй так же пытается захватить весь регистр, но не может, поскольку натыкается на захват ресурса 1.
Итого — дедлок. Пожалуй, добавлю это объяснение в текст
(19)
Повышение уровня блокировки ресурса в рамках одной транзакции если уже быть до конца точным
В методических примерах на расследование взаимоблокировок точно такой же код
Посмотрите на ИТС
Индексы тут не при чем
то что индекс сканируется это плохо, но отсюда не следует что он в конфликте блокировок
С каких интересно пирогов сканирование индекса начало захват ресурса на взаимоблокировку делать ?
Это было бы блокировкой, второй кто ожидает отвалился бы таймауту
А вы как раз читаете и пишете набор записей в цикле — это классический пример взаимоблокировки с повышением уровня
только там в отладчике ставится точка останова, а вам коллега подогнал такой вот пример
И причину дедлока вы не поймали, а поймали его хвост — его было видно и в сообщении ошибки 1С, можно было с КИП и профайлером не заморачиваться
(20) Я не исключаю, что вы правы, и действительно, там есть еще один дедлок, но пользователями он не ловится. Когда у меня будет время я проверю это. Но в статье обсуждается не этот дедлок.
Давайте пойдем по другому.
По тексту видно, что дедлок возник на блокировках СУБД.
Когда читается набор записей регистра, какая блокировка накладывается? Управляемая S.
Когда записывается набор записей регистра, какая блокировка накладывается? Управляемая X.
Получаем дедлок на управляемых блокировках, а у здесь дедлок на СУБД.
Вы же не будете спорить, что сканирование индекса приводит к избыточным блокировкам? Избыточные блокировки часто являются причиной дедлока.
(21)Сканирование индекса просто увеличивает время транзакции и тем что вы добавили индекс вы это время просто сократили и теперь у вас перестали во времени пересекаться люди записывающие документы.
Как только они пересекутся во времени — вы тут же поймаете точно такой же дедлдок.
Проверит можете элементарно на двух рабочих местах проведя документы одновременно.
А при хорошем коде (привет вашему коллеге) дедлок вы не поймаете, второй пользователь просто встанет в ожидание на блокировке и дождется его если только у вас документ 20 сек не будет проводиться.
Отсюда некоторая мораль — вы не обсуждаете код ваших коллег, а берете костылик в виде добавочного индекса и подпираете им код кривенький код ваших коллег.
Т.е. базе вашей и так нехорошо живется, а вы ей еще один индекс подбросили.
А на регистре сведений и не один наверняка.
А почему бы вашему коллеге не взять все поля в отбор — он же по номенклатуре пишет сведения ?
Вспоминается…
Трубоукладчики — очень вежливые люди и всегда пропускают асфальтоукладчиков вперёд.
У вас с вашим коллегой точно такая же история.
Вместо того чтобы сказать — Вася поправь свой код, на что ушло бы 5 мин, вы тоже произвели немаленькие работы с КИП даже и в результате количество косяков в вашей базе увеличилось.
(19) Задумался, откуда у Вас U блокировка и наткнулся на интересную статью, которая в полной мере объясняет Вашу ситуацию.
В одной сессии мы установили монопольную блокировку (X) на одну(или диапазон) из строк таблицы. В другой сессии мы пытаемся обновить другую строку(или диапазон) этой же таблицы и запускаем запрос на обновление с неоптимальным планом, что приводит к сканированию всей таблицы. SQL Server будет устанавливать блокировку обновления (U) на каждую просканированную строку, но в итоге не сможет завершить операцию, т.к. попытается прочитать строку, на которой уже была установлена монопольная блокировка (X). И при этом неважно, что мы хотим обновить совершенно другую строку, для SQL Server необходимо прочитать строку, чтобы установить на нее блокировку обновления (U), и после этого проверить, нужно ли ее обновить.
Можете спросить у автора разрешение внести выдержки в свою статью.
В Вашем примере, конечно, напрашивается индекс по полю документ, в случае использования текущей архитектуры регистра в других местах, например, отчетах. Если нет, то можно и перенести наверх. А можно было бы и переписать логику удаления признака ошибки
(22) на самом деле, есть в ее словах доля истины. Здесь пример, прямо, как из методички
(24)Попытка увеличения уровня блокировки ресурса в последующих операциях (например — чтение и последующая запись)
Последовательность действий, приводящая к взаимной блокировке:
Транзакция Т1 выполняет запрос к таблице остатков регистра Р1 и устанавливает разделяемую блокировку на прочитанные записи.
Транзакция Т2 выполняет запрос к таблице остатков регистра Р1 и устанавливает разделяемую блокировку на прочитанные записи. Поскольку разделяемые блокировки совместимы, то ей удается это сделать.
Транзакция Т1 записывает движения документа и пытается обновить записи в таблице остатков регистра Р1. Для этого требуется установить на эти записи эксклюзивную блокировку. Ей это не удается потому, что на эти записи наложена транзакцией Т2 разделяемая блокировка , не совместимая с эксклюзивной. Транзакция Т1 приходится ждать, когда транзакция Т2 закончится и снимет установленную блокировку.
Транзакция Т2 записывает движения документа и пытается обновить записи в таблице остатков регистра Р1. Для этого требуется установить на эти записи эксклюзивную блокировку. Ей это не удается потому, что на эти записи наложена транзакцией Т1 разделяемая блокировка , не совместимая с эксклюзивной. Транзакция Т2 приходится ждать, когда транзакция Т1 закончится и снимет установленную блокировку.
Можно заметить, что этот процесс никогда бы не закончился, если бы одна из транзакций не была отменена Microsoft SQL Server принудительно.
Избежать подобной ситуации можно, используя при выполнении запроса к таблице остатков регистра Р1 оператор «ДЛЯ ИЗМЕНЕНИЯ». В этом случае на прочитанные записи будет установлена блокировка более высокого уровня — блокировка обновления. Такая блокировка совместима с разделяемой, что позволит транзакциям, осуществляющим чтение данных, на которые установлена блокировка обновления, обращаться к этим данным беспрепятственно. А когда понадобится их обновить, то проблем быть не должно, так как блокировки обновления между собой несовместимы, и, значит, другие транзакции, читающие эти данные для последующего изменения (и естественно тоже запросившие их с блокировкой обновления), будут ждать, пока эти данные поменяются, не препятствуя другим сессиям.
(22) Мой коллега уволился 5 дней назад (С)
Вы не правы.
Вот цитата с сайта
Отсутствие необходимого индекса для запроса означает перебор всех записей таблицы, что в свою очередь приводит к избыточным блокировкам, т.е. блокируются лишние записи. Кроме того, чем дольше выполняется запрос из-за отсутствующих индексов, тем больше время удержания блокировок.
Это достаточно авторитетный источник?
Вот еще цитата с ИТС:
[IS-QUOTE]Проверит можете элементарно на двух рабочих местах проведя документы одновременно.
Воспроизвести ваш пример дедлока не получится.
Я не могу одновременно с двух рабочих мест провести один и тот же документ. (отбор же стоит по документу). Именно поэтому он и не возникает в рабочей базе.
(23) Да, U блокировка возникает именно оттуда. Дальше в транзакции происходит удаление данных.
DELETE FROM T1
FROM dbo._InfoRg8072 T1
WHERE (T1._Fld8075_TYPE = 0x08 AND T1._Fld8075_RTRef = 0x000000B6 AND T1._Fld8075_RRRef = ?) AND (T1._Fld385 = ?)
Кстати, тоже со сканированием. Возможно, что если бы я использовала этот запрос вопросов было бы меньше, зато так интереснее))
Все. Вспомнил где я видел это
Показать
Не напоминает код вашего коллеги? Только вместо паузы у него цикл по таблице документа )
А это как раз пример с ИТС про ошибку взаимоблокировки на управляемых блокировках
(26)Вы путаете блокировки и взаимоблокировки.
блокировки ждут окончания, а взаимоблокировки сразу рубятся сервером.
Поэтому при сканировании таблиц в общем случае просто все будет медленно работать.
А так как у вас написан код — он будет крашиться
И проводить не обязательно не один и тот же документ
(28) Напоминает) Только есть одна проблема. В коде отбор ставится по документу. Который в данный момент проводится.
И второй пользователь не может провести такой же документ (с такой же ссылкой). Больше этот код (кроме как при проведении) не используется.
Хорошо, только ради вас, я воспроизведу дедлок СУБД, установив управляемую блокировку перед чтением регистра. Это будет достаточным доказательством?
(29) Если я проведу другой документ, то откуда взятся дедлоку? Читаются разные записи, записываются тоже.
В вашем примере с ИТС читаются, а потом записываются одни и те же записи у первой и второй транзакции.
(30)Лестное предложение )
Только область блокировки задайте правильно — по номенклатуре из табличной части
и на мой взгляд — вуаля — взаимоблокировку вы не словите
(31) Добавила воспроизведение дедлока в статью после установки управляемой блокировки.
Не понял, так запись в регистр идёт как при записи документа, так и при его проведении?
ЗЫ: ДвиженияДокументовПоРегистру(Документ) нужно переписать, там наблюдаются признаки параноидной шизофрении.
(35) Явно начинать транзакцию абсолютно необязательно в данном случае. Повторю, идет запись и проведение документа. А значит транзакция уже начата.
И да, я тоже ссылаюсь на ИТС, а не на сайты в интернете.
Вот еще раз дублирую:
(25) Конструкция «ДЛЯ ИЗМЕНЕНИЯ» будет проигнорирована в управляемом режиме блокировок
(17)
И нафига его вообще читать если все равно потом перезаписывать.
Одному 🙂
Вы явно невнимательный человек или вовсе не программист 1С.
Еще раз посмотрите внимательно на код 🙂 И подумайте
Во первых набор записей читается чтобы проверить условие, есть-ли вообще что-то в регистре сведений по этому измерению «Документ»?
Во вторых набор записей читается для того, чтобы изменить там всего один реквизит и если вы его запишите без чтения то тупо затрете все данные в регистре которые там были…
Далее проверка условия — Если есть какие-то записи по документу в регистре тогда все записи набора перебираются в цикле и им устанавливается значение реквизита «Ошибка» в ЛОЖЬ.
После чего уже когда цикл завершился производится целиком запись всего набора а не запись в цикле как вы написали.
Показать
(34) не совсем понимаю где вы там усмотрели признаки шизофрении, по моему там все в порядке учитывая, что регистр наверняка не подчинен регистратору и не периодический (лишь в этом случае можно считать этот код бредом), в противном случае писать в регистр нужно набором записей, учитывая еще то, что при этом нужно проверить некоторые условия (см. код процедуры) то вполне оправдано проверять их после чтения набора записей.
А как вы бы оптимизировали этот «параноидально шизофреничный» по вашему мнению код?
(36)А вы попробуйте. Как говорил товарищ Берия: Попытка не пытка.
И по вашему любая функция из модуля документа выполняется в транзации ?
(39)
1. Запись набора записей в цикле можно легко переделать
2. В чем смысл устанавливать отбор по измерениям «Номенклатура» и «ЕдиницаИзмерения», если потом идёт перезаполнение ПРЕДЫДУЩЕГО НАБОРА (ведь чтения нет)? И как можно это расценивать, если запись произойдёт все-равно с теми измерениями, что установлены в отборе данными ПО ТЕКУЩЕЙ СТРОКЕ ТЧ, соответственно это что не на есть признаки ШИЗОФРЕНИИ. ТАК ПОНЯТНО?!
ЗЫ: и это пишет программист с 10+ летним стажем?!
(39)
Вспоминается…
Я презрение глаголы. Злость на людей, которые их похвала
Да там полностью кривой код в принципе.
Плюсом к этому идет «улучшение» от автора публикации в виде индекса по документу, который там нафиг не нужен.
Просто топик стартер дама и это не позволяет мне в полной мере выразить восхищение, а коллега вот не постеснялся
(41) я уже писал в (15), но видима 🙂
(41) ахахах ))) сейчас перечитал процедурку, и увидел что во первых реально чтения там вообще нет (и условие Количество()>0 никогда не сработает), а также запись действительно в цикле что увеличивает нагрузку на порядок… Бред. Согласен шизофрения программиста на лицо.
(3)
Это утверждение, конечно же, неверно — потому как уровень изоляции RCSI прописывается в свойствах базы данных на уровне MSSQL. Ну или я не понимаю, что вы имеете в виду под словом «работает».
(12)
Я тут покопал более глубоко — и.. Нет, не только в автоматическом режиме.. Как раз-таки RCSI их и накладывает.
Вообще, вот эти две статьи во многом прояснили для меня механизм работы RCSI:
(44) Почему же не сработает? Ещё как сработает. Просто это бессмысленно.
Условие выполнится на следующей итерации, т.е. со второй строки ТЧ.
И даже если бы было сначала чтение — все равно логики тут нет:)
(48)
я уж не знаю что там хотел и имел в виду программист который писал код, но я комментирую то что есть,
Лично для Вас повторяю во второй раз, судя из кода — чтобы проверить условие
именно для этого и читается набор записей.
Не все равно. Если записей в регистре нет, то и записывать его не будут.
Вы опять за свое? Глаза переведите выше через один пост в (38) и посмотрите еще раз внимательно в код. Где вы там узрели запись вы цикле????!!! о_О Запись вынесена за пределы цикла!
В четвертых где вы увидели в комментируемом мной куске кода изменение отборов? Используются одни и те же. А точнее один «Документ»
тут на самом деле вопрос не ко мне видимо, потому что про захват ресурсов я ничего не говорил
Уж не внимательный это 100%
(21)
Как в snapshot может появиться s-блокировка?
Без snapshot сканирование индекса с S-блокировкой (или неоптимальный план => эскалация) — согласен.
(40) а лучше демо-пример, чтобы мы сами могли попробовать:)
Автор правильно заметила, что здесь возникает дедлок из-за захвата ресурсов в разном порядке. Решение в принципе неплохое. На мой взгляд для решения этой проблемы, необходимо обеспечить одинаковый захват ресурсов в обеих процедурах. Т.е. или при записи отключить отборы по номенклатуре и ЕИ, или при проведении добавить отборы по номенклатуре и ЕИ. На мой взгляд первый вариант предпочтительнее, т.к. убирает ещё и запросы в цикле и делает однократную запись в РС. С учётом того, что добавлен индекс по документу, процедура после доработки должна работать быстрее.
(45) Я про возможные ожидания программиста 1С и того результата, который он получит. RCSI конечно же будет работать, если его включили, но видно это будет только при соблюдении определенных условий.
В целом круто. У меня в организации вообще нет ни одного человека, кроме меня, кто бы залез хотя бы настолько глубоко в 1С. Сама тема непростая, в ней необходимо хорошо разбираться, чтобы представить себе полную цепочку событий со своими нюансами.
(12) Да, абсолютно точно.
Это как разработчик может поставить эту блокировку. А сама СУБД вольна выбирать что хочет.
В данном случае у нас вначале читаются U блокировкой записи, а затем удаляются X блокировкой.
Вот тут хорошо описан этот вариант.
(40)
Еще раз: я выложила эту статью не для того, чтобы обсудить чей-то код, а для того чтобы обсудить способ поимки дедлока.
Те «способы» его поимки, которые вы предлагаете — это тыканье палочкой в код с надеждой, что на этот раз тычок что-то даст. Но чтобы найти дедлок нужно использовать не метод тыка, а специальные инструменты, такие как ЦУП, ТЖ и пофайлер.
Но в целом, все ваши предложения вы теперь можете попробовать на практике. Если получится избежать дедлока с помощью управляемой блокировки с сохранением параллельности работы и без изменения логики программы — мое увОжение.
Дорогие коллеги. Я подготовила для вас модельную базу, на которой воспроизводится дедлок. Там используется точно такой же код, который представлен в статье, специально, чтобы вы могли поупражнятся в оптимизации кода и установить какие угодно транзакции и блокировки.
PS
1. не забудьте развернуть базу в клиент-серверном варианте.
2. Дедлок возникает, если поставить точку останова в строке 40 модуля объекта заказа поставщику.
(42) (43) В книге «Настольная книга эксперта по технологическим вопросам» написано, что не стоит бросаться оптимизировать код, который не вызывает проблем и это как раз такой случай, вы потратите время, а дедлок все равно будет воспроизводиться.
Можете это проверить на модельной базе.
(57) Мне лень упражняться :). Вот совет по оптимизации могу дать!
(52) Предполагаю, что вы правы, я до конца не разобрала тот бизнес-процесс в рабочей базе, где используется этот код. Но чисто теоретически я могу придумать ситуацию, где отборы должны стоять именно таким образом.
В любом случае, это интересный модельный пример.
(46)
Вообще, вот эти две статьи во многом прояснили для меня механизм работы
Статьи хорошие — там объясняется объединение снэпшотов (то есть запись/обновление/вставка в базу).
Мне не понятен конкретно вот этот абзац (с выборкой из базы с U-блокировкой):
Запрос:
SELECT TOP 1
T1._Fld385
FROM dbo._InfoRg8072 T1
WHERE ((T1._Fld385 = ?)) AND (T1._Fld8075_TYPE = 0x08 AND T1._Fld8075_RTRef = 0x000000B6 AND T1._Fld8075_RRRef = ?)
План:
| |—Top(TOP EXPRESSION:((1)))
| |—Index Seek(OBJECT:([HP_w_sql_001].[dbo].[_InfoRg8072].[_InfoRg8072_ByPeriod] AS [T1]), SEEK:([T1].[_Fld385]=[@P1]), WHERE:([HP_w_sql_001].[dbo].[_InfoRg8072].[_Fld8075_RRRef] as [T1].[_Fld8075_RRRef]=[@P2] AND [HP_w_sql_001].[dbo].[_InfoRg8072].[_Fld8075_TYPE] as [T1].[_Fld8075_TYPE]=0x08 AND [HP_w_sql_001].[dbo].[_InfoRg8072].[_Fld8075_RTRef] as [T1].[_Fld8075_RTRef]=0x000000B6) ORDERED FORWARD)
Показать
(55)
При снэпшотах пишущие не блокируют читающих как раз потому, что никакие блокировки при чтении не устанавливаются — чтение идет из снэпшота.
(56)
Процедура УдалитьПризнакНаличияОшибкиПриПроведенииДокументов(Документ) Экспорт // Вариант без изменения индексов придётся блокировать весь РС { Блокировка = Новый БлокировкаДанных; ЭлементБлокировки = Блокировка.Добавить(«РегистрСведений.ИзмененияЕдиницИзмеренияНоменклатуры»); ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный; Блокировка.Заблокировать(); // } …Показать
В данном случае транзакции будут проходить последовательно.
(55) U-блокировка устанавливается при выполнении удаления:
Rows Executes StmtText
—- ——— ———
2 1 Clustered Index Delete(OBJECT:([testdeadlock].[dbo].[_InfoRg38].[_InfoRg38_2] AS [T1]), OBJECT:([testdeadlock].[dbo].[_InfoRg38].[_InfoRg38_1] AS [T1]))
2 1 |—Top(ROWCOUNT est 0)
2 1 |—Index Scan(OBJECT:([testdeadlock].[dbo].[_InfoRg38].[_InfoRg38_1] AS [T1]), WHERE:([testdeadlock].[dbo].[_InfoRg38].[_Fld41RRef] as [T1].[_Fld41RRef]=[@P1]) ORDERED FORWARD)
В приложении трассировка с дедлоком и обычным проведением.
(57) А можно прямо в комментарии ссылку на файлообменник?)
(65) Да, конечно:
(63) Мощно)))
Только параллельности работы не будет.
(13) Добавила модельную базу, можете воспроизвести.
(68), спасибо — уже воспроизвёл (см. комментарий 64).
Посмотрел Ваше решение — при больших объемах (документы более 10к строк) эскалации нет, вариант рабочий (хотя и придётся обслуживать доп. индекс).
При этом сама структура РС мне не нравится — возможно, стоило сделать документ регистратором. Код доверия не вызывает (например, в «ДвиженияДокументовПоРегистру» после установки отборов нет чтения регистра; движения в регистр попадают при записи, а не при проведении; период движения — текущая дата, а не дата документа или хотя бы дата сеанса).
(67) Да, будет последовательное выполнение. Думаю, что решить проблему через. упр. блокировки по другому в данном случае не получится — область блокировки должна быть не меньше области изменяемых данных (а у нас частичный скан индекса).
(69) Не спорю, у меня код доверия тоже не вызывает.
Я этот бизнес-процесс почти не знаю, но вроде бы идея в том, что вначале документ записывается, потом номенклатура в этом документе проверяется другими лицами и, если есть ошибка в номенклатуре (в названии или единице измерения), то меняется регистр сведений, выставляется флаг Ошибка = Истина. А потом третьи лица исправляют ошибки и проводят документ.
(50) Я говорила по управляемые блокировки. Они к RCSI не имеют отношение.
(72) теперь понятно, спасибо.
Отчасти согласен с предыдущими ораторами о том, что вместо индексов новых неплохо бы схему работы изменить и весь код переписать…
Про РЗ и постобработку уже говорил, а еще можно сделать в этой ситуации также, как 1С сделала с таблицами итогов — добавить в проблемную таблицу измерение-сплиттер, правда и тут придется периодически сворачивать записи, да и все запросы переписать.
Реалии жизни, к сожалению, как правило другие. Заказчик со слезами на глазах просит «ну хоть как-то починить за вменяемое время-деньги». А ты, глядя на все это, понимаешь, что переписав кусочек тут — придется переписать и там, а потом еще и вот там и вот еще и там ну и т.д. и в итоге надо Ctrl+A, Del, написать все заново ))) А тут худо-бедно проблема решена, и спец, который может ее решить без лишнего нытья — молодец
(74)
Я и сама с ними согласна. Только того, кто это написал уже нет в компании, а времени на погружение и переписывание мне никто не даст. И других задач полно.
(75)
проще тогда в цикле добавить каждому полю по индексу — сэкономите кучи времени себе и остальным программистам
и ваша база заиграет новыми … 🙂
(48)
Что вы понимали за что вам ставят минусы:)
Показать
(77)Я знал что будет плохо, но не знал что так скоро. ©
Вы пишете — читаете и снова пишете в периодический регистр при проведении документа.
Причем с разными отборами.
Это толково. Так конечно никаких блокировок никогда не случится. Они все от смеха поумирают.