AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 30.01.2019, 20:12   #1  
Blog bot is offline
Blog bot
Участник
 
21,795 / 759 (69) +++++++
Регистрация: 28.10.2006
Denis Trunin's Blogs: Blocking in D365FO(and why you shouldn't always follow MS recommendations)
Источник: https://denistrunin.com//understanding-sql-blocking/
==============

Understanding blocking is a key component of resolving performance issues. You can have fast CPU, a lot of memory, but if you face SQL blocking problem all these will not be fully utilized

Источник: https://denistrunin.com//understanding-sql-blocking/
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
Старый 31.01.2019, 12:37   #2  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,459 / 4662 (160) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Я просто добавлю, что update_recordset (точнее говоря - update в SQL Server) вешает блокировки не только на те записи, которые он реально обновляет, но и на те записи, которые попали в выборку по индексу. Ну то есть - если у нас подходящего индекса нету, то SQL может попробовать поискать по какому-то случайному индексу по dataAreaId, а перед поиском - попробуем все это ненадолго заблокировать. Плюс - иногда SQL Server переглючивает или индексы фрагментируются или еще что-то подобное случается, и оно выбирает план исполнения по не тому индексу. В этом случае тоже случаются аналогичные блокировки.

В то же время, если нам надо обновить не 100-200, а эдак 100K-200K записей, то особой альтернативы update_recordset просто нету. Да - есть вероятность блокировок. Да - надо строить правильные индексы. Да надо регулярно их перестраивать и строить статистику. Да -есть вероятность время от времени нарваться на блокировки. Но просто в каждом конкретном случае мы должны сравнивать риски больших задержек из за пошагового обновления и риски задержек из за взаимных блокировок.
Плюс - я не уверен что во всех сценариях мы можем создавать отдельную транзакцию на каждое обновление. При этом если у нас одна большая транзация и обновление идет по одной записи в while select forupdate, то порядок обновления в разных кусках кода вполне может быть разным. (К слову сказать - в исходном примере вообще в while select не стоит order by, соответственно порядок обновления записей не является гарантированым...)

Последний раз редактировалось fed; 31.01.2019 в 12:53.
За это сообщение автора поблагодарили: trud (5), mazzy (2), Logger (5).
Старый 31.01.2019, 13:05   #3  
trud is offline
trud
Участник
Лучший по профессии 2017
 
725 / 940 (33) +++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от fed Посмотреть сообщение
В то же время, если нам надо обновить не 100-200, а эдак 100K-200K записей, то особой альтернативы update_recordset просто нету.
Это понятно, но основная проблема даже не в этом. Наши контракторы используют update_recordset даже если нужно обновить 1-2 записи в середине разноски журналов ГК. Причем они ссылаются на вебкасты как в ссылке, где просто безусловно говорится - что типа если нужен быстрый код, надо писать update_recordset. Т.е. "не надо думать, просто пиши так, будет на порядки быстрее"
ЗЫ: Еще они не используют find, а всегда перечисляют список полей, типа так еще быстрее , это наверное будет тема для следующего поста
За это сообщение автора поблагодарили: EVGL (15).
Старый 31.01.2019, 13:17   #4  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
616 / 629 (22) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Очень странно, вы нарушили две рекомендации (не делать длинных транзакций и иметь покрывающий индекс для where) чтобы показать, что тогда третья рекомендация не будет работать.

А дальше сомнительные, ничем не подкрепленный вывод:
Цитата:
Try to avoid any update_recordset and delete_from usage by default(especially in document posting operations). Use it only when you are 100% sure that it will not cause blocking and you really need to reduce the operation time
А ваш способ прям дает 100% избежание блокировок?

Что вообще такое document posting ? И если вы уже говорите ut when someone tries to update the same table using a different set of fields(for example Field2 and Field4) we'll get blocking again., то используя ваш подход можно преположить, что любой кусок кода может быть использован кем-то дргуим как-то не так и надо быть к этому готовым! Т.е. все может стать document posting, чтобы это не было.
Старый 31.01.2019, 13:28   #5  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
616 / 629 (22) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от trud Посмотреть сообщение
ЗЫ: Еще они не используют find, а всегда перечисляют список полей, типа так еще быстрее , это наверное будет тема для следующего поста
Ну если эти поля совпадают с полями в индексе, то таки да, быстрее. А что, медленее ?
Старый 31.01.2019, 13:29   #6  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,459 / 4662 (160) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от skuull Посмотреть сообщение
Очень странно, вы нарушили две рекомендации (не делать длинных транзакций и иметь покрывающий индекс для where) чтобы показать, что тогда третья рекомендация не будет работать.
Я просто замечу что две первых рекомендации не всегда выполнимы. Если разносится большой документ, то на короткие транзации это не порезать. Кроме того - покрывающий индекс на каждую возможную комбинацию полей в where тоже не всегда доступен. Кроме того, как я уже написал, время от времени (особенно на квазивременных таблицах типа InventSumDeltaDim), SQL Server переглючивает и он выбирает неправильный индекс, даже если правильный покрывающий индекс присутствует.
Старый 31.01.2019, 13:35   #7  
trud is offline
trud
Участник
Лучший по профессии 2017
 
725 / 940 (33) +++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от skuull Посмотреть сообщение
Что вообще такое document posting ?
ну это постинг любых документов, закупок, заказов журналов - там где это наиболее критично. т.е. кейс - нам надо обновить что-то в нашей таблице, когда происходит разноска

Цитата:
Сообщение от skuull Посмотреть сообщение
А ваш способ прям дает 100% избежание блокировок?
ну в общем случае select forupdate не блокируется.Исключение составляет эскаляция блокировок, но это уже другая тема

Цитата:
Сообщение от skuull Посмотреть сообщение
И если вы уже говорите ut when someone tries to update the same table using a different set of fields(for example Field2 and Field4) we'll get blocking again., то используя ваш подход можно преположить, что любой кусок кода может быть использован кем-то дргуим как-то не так и надо быть к этому готовым! Т.е. все может стать document posting, чтобы это не было.
да, надо стараться писать код, который будет работать без блокировок
Старый 31.01.2019, 13:38   #8  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
616 / 629 (22) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от fed Посмотреть сообщение
Я просто замечу что две первых рекомендации не всегда выполнимы. Если разносится большой документ, то на короткие транзации это не порезать. Кроме того - покрывающий индекс на каждую возможную комбинацию полей в where тоже не всегда доступен. Кроме того, как я уже написал, время от времени (особенно на квазивременных таблицах типа InventSumDeltaDim), SQL Server переглючивает и он выбирает неправильный индекс, даже если правильный покрывающий индекс присутствует.
Полностью согласен и даже не пытаюсь с этим спорить. Но ИМХО вывод должен быть: "вот сценарий, вот пример, вот такая может быть проблема. не надо бездумно использовать update_recordset, учтите вот это и это." А как я понял мотивацию автора: "while select по умолчанию, а update_recordset только если нет другого выхода "
За это сообщение автора поблагодарили: ax_mct (3).
Старый 31.01.2019, 13:45   #9  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
616 / 629 (22) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от trud Посмотреть сообщение
ну в общем случае select forupdate не блокируется.Исключение составляет эскаляция блокировок, но это уже другая тема
Это та же самая тема. Вопрос эскалации встает при больших количествах данных\пользователей\потоков и говорить "тут больше 1-2х строк не будет" звучит не убидительно. Сегодня нет, а завтра поменяется бизнес процесс и их будет тысячи, что сядем все переписывать?
Старый 31.01.2019, 13:56   #10  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,459 / 4662 (160) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от skuull Посмотреть сообщение
Это та же самая тема. Вопрос эскалации встает при больших количествах данных\пользователей\потоков и говорить "тут больше 1-2х строк не будет" звучит не убидительно. Сегодня нет, а завтра поменяется бизнес процесс и их будет тысячи, что сядем все переписывать?
Могу подсказать простой выход - напиши в своем блоге полноценный пост на эту тему, с разбором всех ситуаций, своими экспертными рекомендациями и тд и тп.
А мы потом, по возможности, тоже поищем в нем ошибки и слегонца постебемся.
Старый 31.01.2019, 14:00   #11  
trud is offline
trud
Участник
Лучший по профессии 2017
 
725 / 940 (33) +++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от skuull Посмотреть сообщение
А как я понял мотивацию автора: "while select по умолчанию, а update_recordset только если нет другого выхода "
Ага, именно это и посыл поста, используем только когда нужно
Цитата:
Сообщение от skuull Посмотреть сообщение
Ну если эти поля совпадают с полями в индексе, то таки да, быстрее. А что, медленее ?
Вы реально не знаете или это просто флуд?

Подобный вопрос обычно задавали при завершении стажировки в Коламбусе - какой вариант быстрее 1 или 2
X++:
CustTable       custTable;
        ;
        //1
        select AccountNum from custTable
            where custTable.AccountNum == "C-0000101";

        custTable = null;    
        //2
        custTable = custTable::find("C-0000101");
Старый 31.01.2019, 21:17   #12  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
616 / 629 (22) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от fed Посмотреть сообщение
Могу подсказать простой выход - напиши в своем блоге полноценный пост на эту тему, с разбором всех ситуаций, своими экспертными рекомендациями и тд и тп.
А мы потом, по возможности, тоже поищем в нем ошибки и слегонца постебемся.
Так я экспертом в вопросе блокировок не являюсь и считаю что самовыдвигаться в эксперты как-то не очень, хотя есть любители
Старый 01.02.2019, 00:06   #13  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,155 / 1899 (70) ++++++++
Регистрация: 12.10.2004
Записей в блоге: 1
Цитата:
Сообщение от trud Посмотреть сообщение
Подобный вопрос обычно задавали при завершении стажировки в Коламбусе - какой вариант быстрее 1 или 2
Интересно и какой же "канонический" ответ они ожидали услышать?
Старый 01.02.2019, 01:04   #14  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
2,330 / 884 (34) +++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от trud Посмотреть сообщение
Ага, именно это и посыл поста, используем только когда нужно

Вы реально не знаете или это просто флуд?

Подобный вопрос обычно задавали при завершении стажировки в Коламбусе - какой вариант быстрее 1 или 2
X++:
CustTable       custTable;
        ;
        //1
        select AccountNum from custTable
            where custTable.AccountNum == "C-0000101";

        custTable = null;    
        //2
        custTable = custTable::find("C-0000101");
custTable = null; Это привычка или какой-то сакральный смысл?
Старый 01.02.2019, 01:06   #15  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
2,330 / 884 (34) +++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от Logger Посмотреть сообщение
Интересно и какой же "канонический" ответ они ожидали услышать?
То что одинаково полагаю. Где-то на форуме было что все равно полная запись вернется если по ключевому полю. Уже не помню почему
Старый 01.02.2019, 04:26   #16  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
616 / 629 (22) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от trud Посмотреть сообщение
Подобный вопрос обычно задавали при завершении стажировки в Коламбусе - какой вариант быстрее 1 или 2]
Одинаково медленно или одинаково быстро. Вы реально утверждаете, что стажер после 2 месяцев сможет внятно обьяснить почему ? Я думаю больше половины учасников этого форума не смогут сказать почему и когда будет по разному и т.д. и т.п. Тут даже есть отдельная секта верующих в вред кеша или в его неработоспособность.
За это сообщение автора поблагодарили: trud (1).
Старый 01.02.2019, 06:46   #17  
trud is offline
trud
Участник
Лучший по профессии 2017
 
725 / 940 (33) +++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Ну главная идея была дать понять, что любую вещь связанную с производительностью надо проверять. Т.е. обычно отвечали что меньше полей, значит запрос меньше. А как посмотреть посмотреть запрос - ну включить трассировку - ну давай посмотрим... смотрим - они одинаковы
Старый 01.02.2019, 07:30   #18  
Pandasama is offline
Pandasama
Участник
 
122 / 30 (2) +++
Регистрация: 11.08.2014
Адрес: Барнаул
Цитата:
Сообщение от skuull Посмотреть сообщение
Одинаково медленно или одинаково быстро.
А вот тут можно подробнее, почему одинаково (пусть это уже и оффтоп)?
Вроде в случае когда у нас указан набор полей, у нас меньше количество данных передаваемых между клиентом-сервером, и поэтому работать должно быстрее?

Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля"
Старый 01.02.2019, 08:22   #19  
trud is offline
trud
Участник
Лучший по профессии 2017
 
725 / 940 (33) +++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Pandasama Посмотреть сообщение
А вот тут можно подробнее, почему одинаково (пусть это уже и оффтоп)?
Так а что мешает проверить?
Цитата:
Сообщение от Pandasama Посмотреть сообщение
Вроде в случае когда у нас указан набор полей, у нас меньше количество данных передаваемых между клиентом-сервером,
А почему оно меньше? данные передаются пакетами, лень искать, но думаю размер пакета на порядок больше того что есть в одной записи
Цитата:
Сообщение от Pandasama Посмотреть сообщение
и поэтому работать должно быстрее?
А если переменную назвать не "custTable", а "с" будет быстрее? (сорри за стеб)

Цитата:
Сообщение от Pandasama Посмотреть сообщение
Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля"
А есть ссылка?
Старый 01.02.2019, 08:40   #20  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
616 / 629 (22) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Red face
Цитата:
Сообщение от Pandasama Посмотреть сообщение
А вот тут можно подробнее, почему одинаково (пусть это уже и оффтоп)?
Вроде в случае когда у нас указан набор полей, у нас меньше количество данных передаваемых между клиентом-сервером, и поэтому работать должно быстрее?

Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля"
Поле, по которому выборка, ключевое и на таблице включен кеш. Бедная ах кеширует всю строку целиком поэтому выбирает все поля. Если бы вы использовали другое поле в where, к примеру, ourAccountnumber по которому есть индекс, но не уникальный, то полей в выборке было бы 2. А если поставить entire table кеш, то вообще все становится хорошо. Видите, это мы пока на уровне АХ, никакими пакетами и страницами мы ещё не разговариваем.

Видимо вам надо в коламбус на месяцок, подтянуть основы на стажеровочке

Последний раз редактировалось skuull; 01.02.2019 в 08:42.
Теги
#покормитроля, как правильно, производительность

 

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 16:12.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.