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

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

**fed** · 31.01.2019, 13:29

Цитата:

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

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

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

skuull · 31.01.2019, 13:38

Цитата:

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

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

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

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");

Logger · 01.02.2019, 00:06

Цитата:

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

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

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

ax_mct · 01.02.2019, 01:06

Цитата:

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

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

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

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

skuull · 01.02.2019, 04:26

Цитата:

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

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

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

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 кеш, то вообще все становится хорошо. Видите, это мы пока на уровне АХ, никакими пакетами и страницами мы ещё не разговариваем.

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

**Vadik** · 01.02.2019, 09:05

Цитата:

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

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

Веронятно потому что в кэш (CacheLookup=Found) что-то кроме AccountNum положить надо? И потом как-то резолвить из него

Цитата:

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

Best practices это же не религиозные догмы, и мы инженеры а не последователи культа. Это рекомендации, их нужно понимать, применять осознанно и проверять. Я не сталкивался с ситуациями где такая оптимизация в моем коде что-то решала бы (по крайней мере там где нет массивных BLOB-ов хранящихся в базе данных). С Azure SQL это мне кажется еще менее актуально, тут скорее латентность и geographic redundancy кроют пропускную способность как бык овцу

trud, в Вашем примере сделано все (малый объем данных, выборка по непокрывающему индексу, диалог в транзакции) чтобы найти хоть какой-то сценарий в котором update_recordset работает хуже. Как пища для размышлений - да, годно. Насколько в реальных условиях несколько конкурентных update_recordset, на реальных объемах данных, завернутых в правильную обработку deadlock-ов, будут быстрее или медленнее (хотя бы в T2) - вот это уже было бы гораздо интереснее. Как Вы считаете?

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:45

Цитата:

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

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

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

**fed** · 31.01.2019, 13:56

Цитата:

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

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

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

skuull · 31.01.2019, 21:17

Цитата:

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

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

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

**fed** · 01.02.2019, 15:20

Цитата:

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

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

А если Вы "экспертом по теме блокировок не являетесь", то откуда этой теме 12 Ваших постов (и кажется еще в твиттере сколько-то, но там мне как-то лень считать)?
Может это троллинг был ? Не может такого быть, просто не могу поверить...

**Vadik** · 01.02.2019, 17:00

Цитата:

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

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

Денис, пятница же, добрее надо как-то

Цитата:

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

Пример 1 - индекс по полю Field2, update_recordset по поля Field2 и Field3. получаем блокировку (которой не было при select forupdate)

Пример 2 - индекс по полю Field2,Field3 update_recordset первой сессии по полям Field2 и Field3, второй сессии по Field2, Field4 получаем блокировку (которой опять же не было при select forupdate)

Ну да, блокировки ключа индекса как при update_recordset не происходит, зато блокировка на уже обновленные записи удерживается дольше. Причем если deadlock при update_recordset лечится банальным retry, то с длинной транзакцией бороться уже немного сложнее. Насколько в Вашем сценарии типично конкурентное обновление одних и тех же данных и какой подход в итоге даст лучшую производительность (throughput) - без тестирования заранее сказать нельзя

Я это к чему - нет здесь универсальных рекомендаций и "правильных" решений. Много кто делает "правильно" (по BP или на основе каких-то городских мифов), мало кто проверяет как они работают