Denis Trunin's Blogs: Blocking in D365FO(and why you shouldn't always follow MS recommendations) - DAX Blogs

Blog bot · 30.01.2019, 20:12

Источник: 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/

**fed** · 31.01.2019, 12:37

Я просто добавлю, что update_recordset (точнее говоря - update в SQL Server) вешает блокировки не только на те записи, которые он реально обновляет, но и на те записи, которые попали в выборку по индексу. Ну то есть - если у нас подходящего индекса нету, то SQL может попробовать поискать по какому-то случайному индексу по dataAreaId, а перед поиском - попробуем все это ненадолго заблокировать. Плюс - иногда SQL Server переглючивает или индексы фрагментируются или еще что-то подобное случается, и оно выбирает план исполнения по не тому индексу. В этом случае тоже случаются аналогичные блокировки.

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

trud · 31.01.2019, 13:05

Цитата:

Сообщение от fed

В то же время, если нам надо обновить не 100-200, а эдак 100K-200K записей, то особой альтернативы update_recordset просто нету.

Это понятно, но основная проблема даже не в этом. Наши контракторы используют update_recordset даже если нужно обновить 1-2 записи в середине разноски журналов ГК. Причем они ссылаются на вебкасты как в ссылке, где просто безусловно говорится - что типа если нужен быстрый код, надо писать update_recordset. Т.е. "не надо думать, просто пиши так, будет на порядки быстрее"
ЗЫ: Еще они не используют find, а всегда перечисляют список полей, типа так еще быстрее

, это наверное будет тема для следующего поста

skuull · 31.01.2019, 13:17

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

skuull · 31.01.2019, 13:28

Цитата:

Сообщение от trud

ЗЫ: Еще они не используют find, а всегда перечисляют список полей, типа так еще быстрее

, это наверное будет тема для следующего поста

Ну если эти поля совпадают с полями в индексе, то таки да, быстрее. А что, медленее ?

**fed** · 31.01.2019, 13:29

Цитата:

Сообщение от skuull

Очень странно, вы нарушили две рекомендации (не делать длинных транзакций и иметь покрывающий индекс для where) чтобы показать, что тогда третья рекомендация не будет работать.

Я просто замечу что две первых рекомендации не всегда выполнимы. Если разносится большой документ, то на короткие транзации это не порезать. Кроме того - покрывающий индекс на каждую возможную комбинацию полей в where тоже не всегда доступен. Кроме того, как я уже написал, время от времени (особенно на квазивременных таблицах типа InventSumDeltaDim), SQL Server переглючивает и он выбирает неправильный индекс, даже если правильный покрывающий индекс присутствует.

trud · 31.01.2019, 13:35

Цитата:

Сообщение от 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, чтобы это не было.

да, надо стараться писать код, который будет работать без блокировок

skuull · 31.01.2019, 13:38

Цитата:

Сообщение от fed

Я просто замечу что две первых рекомендации не всегда выполнимы. Если разносится большой документ, то на короткие транзации это не порезать. Кроме того - покрывающий индекс на каждую возможную комбинацию полей в where тоже не всегда доступен. Кроме того, как я уже написал, время от времени (особенно на квазивременных таблицах типа InventSumDeltaDim), SQL Server переглючивает и он выбирает неправильный индекс, даже если правильный покрывающий индекс присутствует.

Полностью согласен и даже не пытаюсь с этим спорить. Но ИМХО вывод должен быть: "вот сценарий, вот пример, вот такая может быть проблема. не надо бездумно использовать update_recordset, учтите вот это и это." А как я понял мотивацию автора: "while select по умолчанию, а update_recordset только если нет другого выхода "

skuull · 31.01.2019, 13:45

Цитата:

Сообщение от trud

ну в общем случае select forupdate не блокируется.Исключение составляет эскаляция блокировок, но это уже другая тема

Это та же самая тема. Вопрос эскалации встает при больших количествах данных\пользователей\потоков и говорить "тут больше 1-2х строк не будет" звучит не убидительно. Сегодня нет, а завтра поменяется бизнес процесс и их будет тысячи, что сядем все переписывать?

**fed** · 31.01.2019, 13:56

Цитата:

Сообщение от skuull

Это та же самая тема. Вопрос эскалации встает при больших количествах данных\пользователей\потоков и говорить "тут больше 1-2х строк не будет" звучит не убидительно. Сегодня нет, а завтра поменяется бизнес процесс и их будет тысячи, что сядем все переписывать?

Могу подсказать простой выход - напиши в своем блоге полноценный пост на эту тему, с разбором всех ситуаций, своими экспертными рекомендациями и тд и тп.
А мы потом, по возможности, тоже поищем в нем ошибки и слегонца постебемся.

trud · 31.01.2019, 14:00

Цитата:

Сообщение от 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");

skuull · 31.01.2019, 21:17

Цитата:

Сообщение от fed

Могу подсказать простой выход - напиши в своем блоге полноценный пост на эту тему, с разбором всех ситуаций, своими экспертными рекомендациями и тд и тп.
А мы потом, по возможности, тоже поищем в нем ошибки и слегонца постебемся.

Так я экспертом в вопросе блокировок не являюсь и считаю что самовыдвигаться в эксперты как-то не очень, хотя есть любители

Logger · 01.02.2019, 00:06

Цитата:

Сообщение от trud

Подобный вопрос обычно задавали при завершении стажировки в Коламбусе - какой вариант быстрее 1 или 2

Интересно и какой же "канонический" ответ они ожидали услышать?

ax_mct · 01.02.2019, 01:04

Цитата:

Сообщение от 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; Это привычка или какой-то сакральный смысл?

ax_mct · 01.02.2019, 01:06

Цитата:

Сообщение от Logger

Интересно и какой же "канонический" ответ они ожидали услышать?

То что одинаково полагаю. Где-то на форуме было что все равно полная запись вернется если по ключевому полю. Уже не помню почему

skuull · 01.02.2019, 04:26

Цитата:

Сообщение от trud

Подобный вопрос обычно задавали при завершении стажировки в Коламбусе - какой вариант быстрее 1 или 2]

Одинаково медленно или одинаково быстро. Вы реально утверждаете, что стажер после 2 месяцев сможет внятно обьяснить почему ? Я думаю больше половины учасников этого форума не смогут сказать почему и когда будет по разному и т.д. и т.п. Тут даже есть отдельная секта верующих в вред кеша или в его неработоспособность.

trud · 01.02.2019, 06:46

Ну главная идея была дать понять, что любую вещь связанную с производительностью надо проверять. Т.е. обычно отвечали что меньше полей, значит запрос меньше. А как посмотреть посмотреть запрос - ну включить трассировку - ну давай посмотрим... смотрим - они одинаковы

Pandasama · 01.02.2019, 07:30

Цитата:

Сообщение от skuull

Одинаково медленно или одинаково быстро.

А вот тут можно подробнее, почему одинаково (пусть это уже и оффтоп)?
Вроде в случае когда у нас указан набор полей, у нас меньше количество данных передаваемых между клиентом-сервером, и поэтому работать должно быстрее?

Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля"

trud · 01.02.2019, 08:22

Цитата:

Сообщение от Pandasama

А вот тут можно подробнее, почему одинаково (пусть это уже и оффтоп)?

Так а что мешает проверить?

Цитата:

Сообщение от Pandasama

Вроде в случае когда у нас указан набор полей, у нас меньше количество данных передаваемых между клиентом-сервером,

А почему оно меньше? данные передаются пакетами, лень искать, но думаю размер пакета на порядок больше того что есть в одной записи

Цитата:

Сообщение от Pandasama

и поэтому работать должно быстрее?

А если переменную назвать не "custTable", а "с" будет быстрее? (сорри за стеб)

Цитата:

Сообщение от Pandasama

Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля"

А есть ссылка?

skuull · 01.02.2019, 08:40

Цитата:

Сообщение от Pandasama

А вот тут можно подробнее, почему одинаково (пусть это уже и оффтоп)?
Вроде в случае когда у нас указан набор полей, у нас меньше количество данных передаваемых между клиентом-сервером, и поэтому работать должно быстрее?

Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля"

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

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