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

[fed]

Цитата:

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

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

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

[skuull]

Цитата:

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

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

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

[trud]

Цитата:

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

А как я понял мотивацию автора: "while select по умолчанию, а update_recordset только если нет другого выхода "

Ага, именно это и посыл поста, используем только когда нужно

Цитата:

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

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

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

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

CustTable       custTable;
        ;
        //1
        select AccountNum from custTable
            where custTable.AccountNum == "C-0000101";

        custTable = null;    
        //2
        custTable = custTable::find("C-0000101");

[Logger]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

Ага, именно это и посыл поста, используем только когда нужно

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

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

CustTable       custTable;
        ;
        //1
        select AccountNum from custTable
            where custTable.AccountNum == "C-0000101";

        custTable = null;    
        //2
        custTable = custTable::find("C-0000101");

custTable = null; Это привычка или какой-то сакральный смысл?

[skuull]

Цитата:

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

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

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

[Pandasama]

Цитата:

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

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

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

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

[trud]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[Player1]

Цитата:

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

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

"Попробуйте использовать список полей для выбора inventJournalTrans. Использовано только 2% размера записи."

Метка @SYS91289 используемая в SysBPCheckMemberFunction.checkUseOfFieldLists() с коментарием в коде //Less than half the bandwidth of fields are used
Такая ссылка устроит?

[skuull]

Цитата:

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

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

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

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

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

[Vadik]

Цитата:

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

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

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

Цитата:

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

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

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

[skuull]

Цитата:

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

Я не сталкивался с ситуациями где такая оптимизация в моем коде что-то решала бы (по крайней мере там где нет массивных BLOB-ов хранящихся в базе данных).

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

[trud]

Цитата:

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

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

Пример упрощение того что было в реальной жизни. Создан по результатам анализа накладной по закупке с включенной корреспонденцией в 2012(тут была тема). Но с замечанием согласен, надо добавить именно реальный сценарий в D365. попробую поразношу накладные на досуге