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

[fed]

Цитата:

Сообщение от Raven Melancholic

Ну, MS SQL достаточно сообразительный товарищ и знает, что по уникальному индексу можно вернуть только 1 или 0 записей. Поэтому он и без подсказки не будет рассматривать варианты оптимальной выборки множества записей.

Насколько я понимаю, при указании firstonly еще и AOS занимается оптимизацией всяких своих внутренних буферов и сетевых обменов, поскольку он знает что второй записи не будет.

[Raven Melancholic]

Цитата:

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

Насколько я понимаю, при указании firstonly еще и AOS занимается оптимизацией всяких своих внутренних буферов и сетевых обменов, поскольку он знает что второй записи не будет.

Вполне возможно, я не в курсе что происходит внутри Аксапты, смотрел со стороны SQL.
Но в данном случае таблица с кэшированием (предположм, что записи в кэше нет), запрос по первичному индексу (ну или для DAX2012 даже если бы просто по уникальному).
Тут Аксапта явно готовилась, анализировала работу с кэшем, и озаботилась тем как его готовить. Логично предположить, что в таком случае и все свои внутренние структуры она подготовила для получения именно одной записи.
Если же, потратив столько сил на анализ кеширования, внутри аксапты для запроса в SQL про это "забыли" и все работает как в остальных случаях, то я разочарован. Так и в Деда Мороза верить перестанешь.

[Vadik]

Какие такие структуры, как их можно особенно готовить чтобы все быстрее стало, кто что готовил и что забыл ? Где это можно увидеть, померить, понюхать ? Не усложняйте, не вводите новые сущности

При FIRSTFAST ядро делает

SELECT TOP 1 (TOP 10 / TOP 100 / TOP 1000)

Дальше уже оптимизатор SQL Server-а думает что здесь можно оптимизировать и как. При singletone lookup по первичному ключу - особенно не наоптимизируешь, заранее известно что вернется либо одна запись либо ни одной, с методом доступа в общем тоже все понятно

https://tinyurl.com/yb7her2j

[EVGL]

Много слов ни о чем. Солидаризуюсь с fed, только обращу внимание не на ошибки, а на расширяемость кода. Если вы не используете Query или SysDa, то добавить новое поле в середину метода невозможно.

[trud]

Цитата:

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

Надо проверять больше чем на 1 примере!

Ну если внимательно почитать в посте 2 разных примера(обе сессии обновляют разные строки, размер таблицы большой по сравнению с кол-вом обновляемых данных)

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

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

Или 2 примера тоже мало? сколько надо?
Если смотреть на примеры из реальной жизни, то я уже приводил ссылку
https://axology.wordpress.com/2013/1...tional-tweaks/

Цитата:

Locking on the InventSumDelta table – additional tweaks - We tried changing the column sequence on the two tables to have Partition and DataAreaId in the beginning, but nothing happened until we disabled the ItemId index too. That had an instant effect and practically removed the deadlock issues immediately.

тут имеем похожую ситуацию как в примере 2. Решается удалением лишнего индекса

Цитата:

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

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

Конечно(но срок был от 2 до 6). если не может объяснить простейшую вещь как он сможет решать реальные проблемы на клиенте где нибудь в сибири?

Цитата:

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

Это не изменит мир, но точно будет быстрее. А зачем делать медленнее если можно быстрее?

Ну так рассуждая можно далеко зайти

• зачем называть переменную custTable, ведь можно назвать с - код будет быстрее компилиться
• зачем использовать стандартные методы разноски, ведь можно просто результат записать своим методом прямо в результирующие таблицы, так будет быстрее
• зачем вообще писать код в АХ, ведь можно сделать хранимую процедуру, так будет еще быстрее

...
Обычно после таких рассуждений после пары месяцев c проблемами производительности у спонсора проекта возникает мысль - "Говорили же друзья, надо было брать SAP"

[Raven Melancholic]

По поводу перечисления полей в выборке вчера/сегодня наткнулись в DAX2009 на интересную особенность.
Полтора года работал запрос, в котором джоин по трем таблицам из них у двух есть кэширование (Found и FoundAndEmpty), а у третьей нет. Во всех прямо перечислены поля, включая ту, по которой нет кэширования.
При использовании результатов выборки была ссылка на одно из полей некэшированной таблицы, которого нет в выборке, но все работало пока вчера не включили на этой таблице интекс по RecId (при этом и первичный и кластерный остались старыми).
После включения индекса Аксапта четко стала следовать указаниям по выборке полей, естественно, все сломалось. Пробовали включать/выключать индекс по RecId, действительно все повторяется - без индекса перечисление полей игнорируется, с индексом выбираются только указанные.
Так что, судя по всему, есть случаи когда независимо от кэширования список полей игнорируется.